How do you run one Helm chart across dev, staging and production without forking it?

## One chart, many environments A Helm chart is a directory holding `Chart.yaml`, a `templates/` directory of Go templates, and a `values.yaml` of defaults those templates read through `.Values`. Nothing in that structure is environment-aware. The chart describes *a* deployment of your application, not the dev one or the prod one; the environment axis lives outside the chart, in the values handed to it at install time. That is the whole design: templates plus values, with the values being the part that varies. So the standard shape is a single chart plus one small values file per environment, passed with `-f`: ``` charts/fraud-platform/ # the chart: templates + values.yaml defaults values/dev.yaml values/staging.yaml values/prod.yaml ``` and a deploy that differs only in which file it names. ## What goes where **Chart defaults** carry everything that is true of every environment: the container port, probe paths and thresholds, label and annotation conventions, the Service type, the structure of the application config, and safe starting values for the knobs. A newcomer should be able to `helm install` the chart with no `-f` at all and get something that runs. **The environment file** carries only the difference: replica counts, CPU and memory requests, autoscaler bounds, the ingress hostname, the storage class, the addresses of external systems, and feature toggles. For an umbrella chart bundling a fraud-scoring API and a worker as subcharts, the environment file nests those keys under each subchart's name — `api:` and `worker:` blocks — because that is how a parent chart addresses a subchart's values. The environment files are **not** part of the packaged chart. A packaged chart is meant to be shared and promoted unchanged; the environment files belong to whoever operates the deployment and live in the repository that owns it. Baking `values/prod.yaml` into the tarball would mean shipping your hostnames to everyone who pulls the chart, and would mean a config change forces a new chart version. ## Why a file rather than --set Anything durable belongs in a committed file. A pile of `--set` arguments assembled by a deploy script is invisible in review, hard to reproduce by hand, and easy to forget on the next upgrade. Helm stores the values it was given alongside the release, so `helm get values fraud-platform -n fraud-prod` prints what that environment actually received — which is only useful if that content also exists in a file someone can read before the deploy. The same storage fact is a warning about secrets. A values file is committed to git, and the release record is itself a Kubernetes Secret in the namespace, readable by anyone with get access to Secrets there. Credentials therefore do not belong in `values/prod.yaml` or in `--set`; the chart should reference an existing Secret by name, and something else — an external secret operator, or the deploy job — should put the material in it. ## The two anti-patterns **A chart per environment.** Copying `charts/fraud-platform` to `charts/fraud-platform-prod` and editing it means three sets of templates to review, three places for a fix to be forgotten, and no way to say that staging tested what production will run. Every difference that was supposed to be a value becomes a code difference. **Environment names inside templates.** `{{ if eq .Values.environment "prod" }}` moves the difference from the values files, where a reviewer diffing three short documents can see it, into the template body, where nobody looks during a config review. It also makes the chart untestable for anyone whose environments are not named yours. Express the difference as an ordinary value with a default instead, and let each environment set it. ## Keeping the files comparable The practical discipline is that the three files should be diffable. Keep the same keys present in every environment's file even where the value repeats, so a missing key is visible rather than silently inherited; keep the files short by pushing anything constant back into the chart; and check all of them in CI rather than only the one being deployed — rendering each with `helm template charts/fraud-platform -f values/<env>.yaml` catches a file that has drifted into something that no longer renders long before it is anyone's deploy.