In a helm install, what wins when values.yaml, two -f files and --set all set the same key?

Every Helm render is driven by a single map of values, and every argument about "which setting actually won" is really an argument about how Helm built that map. It is built in three layers, always in the same order. ## The three layers, lowest precedence first 1. **The chart's `values.yaml`.** Each chart ships a `values.yaml` at its root holding the author's defaults. This is the base layer and the lowest precedence: it supplies a value for every key the templates expect, so that `helm install ./monitoring-stack` with no flags at all still renders. It is not a schema and not a whitelist; it is just data. 2. **The `-f` / `--values` files, in the order given.** `-f` is repeatable, and Helm merges the files onto the base one at a time, left to right, so the last file mentioned has the highest precedence among the files. This is what lets a team keep `values/base.yaml` with everything common and `values/prod-eu.yaml` with the handful of keys that region changes. The argument can be a local path or a URL. The ordering rule is easy to state and easy to get wrong in practice, because the order is usually decided by a wrapper script rather than by the person reading the diff. 3. **The `--set` family, last.** `--set` and its siblings are merged after every file, so an inline flag always wins. This is deliberate: the flags are the most specific, most situational input, typically a single key someone is changing for one run. It is also the reason a persistent "my values file is being ignored" report so often turns out to be a `--set` left in a CI job's arguments. ## Precedence is by layer, not by command-line position `helm install app ./chart --set replicaCount=3 -f prod.yaml` still lets `--set` win, even though the file was typed afterwards, because Helm merges all the value files first and then applies the set flags. Only the relative order of the `-f` files themselves matters. Likewise, the different `--set` variants are applied as a group rather than interleaved by position, so setting the same key twice with two different set flags is not something to reason about - set each key exactly once. ## How the layers combine What a later layer does to an earlier one depends on the kind of value it carries: | Override value | Merge behaviour | Effect on the earlier layer | | --- | --- | --- | | Map | Deep-merged key by key | Keys the override does not mention survive | | List | Replaced whole | Every element of the earlier list is gone | | `null` | Key deleted | The key is absent from the merged values | Deep merge by key is what makes small override files possible - a file containing only `resources: {limits: {cpu: 750m}}` does not wipe the memory limit the chart defaulted. Lists are replaced whole, never appended to or merged element by element, because list elements have no key to match on. And a key whose override value is `null` is deleted from the merged values rather than set to an empty value. ## Verify, do not reason The cheap habit is to render the chart locally with exactly the flags the real command will use and read the YAML that comes out, before touching a cluster. For a release that already exists, `helm get values` prints what was supplied for the current revision and `helm get manifest` prints the YAML those values produced. Together they turn "which layer won" from an argument into an observation. ## Where this goes wrong in real pipelines A CI wrapper that appends `-f` files in a loop puts the region file before the environment file for one job and after it for another, and two clusters diverge for reasons nobody can see in the repository. A key is misspelled at the top level of an override file - Helm accepts unknown keys silently unless the chart ships a `values.schema.json`, so the override does nothing at all and the chart default sails through. Someone adds a `--set` to debug an incident and never removes it, and from then on the values file for that key is decorative. In each case the fix is the same: make the full command visible, keep the number of layers small, and render before you apply.