What is the difference between `helm get values` and `helm get values --all` for a release?

### Two different value sets, one command Helm keeps two views of a release's configuration, and `helm get values` can print either one. **User-supplied values** are exactly what a caller passed on the command line for the last install or upgrade: every `-f`/`--values` file, plus `--set`, `--set-string` and `--set-file`, merged in the order Helm applies them into a single tree. Helm saves that tree alongside the revision, so it survives long after the values file on someone's laptop has been edited or lost. `helm get values <release>` prints it, headed `USER-SUPPLIED VALUES`. If nobody overrode anything, you get a null set - which is information, not a bug. **Computed values** are what the templates actually saw: the chart's own `values.yaml` defaults, each subchart's defaults nested under the subchart's name or alias, the `global` block, and the user-supplied overrides merged on top. `helm get values <release> --all` prints that tree. It is often an order of magnitude larger than the user-supplied one. ### Why the distinction matters Consider a geospatial tile server installed as the release `tileserv` from an 18-chart umbrella named `tile-platform`, which bundles an API subchart and a worker subchart. The team overrode nine keys. `helm get values tileserv -n geo` prints those nine and nothing else - a compact, honest statement of the decisions a human made. `helm get values tileserv -n geo --all` prints well over a thousand lines: every default of the umbrella and of all eighteen subcharts, with those nine keys overwritten in place. Each answers a different question: - *"What did we choose?"* - the user-supplied set. This is the input to reproducing a deployment, to a code review of what an operator actually did, and to spotting an override that was set once during an incident and never removed. - *"What did the templates render against?"* - `--all`. When a rendered manifest carries a replica count or an image tag nobody recognises, `--all` shows the value that produced it and, by its absence from the user-supplied set, proves it came from a chart default rather than from your team. ### The trap: feeding `--all` back into `-f` The most common real mistake with this command is to capture `--all` output into a file and pass it to the next `helm upgrade -f`. It appears to work and it silently freezes the release. Every chart default becomes an explicit override, so when a later chart version changes a default - a new probe path, a changed security context, a different resource request - your file overrides the new default with the old one, and the upgrade quietly does not take. The whole point of chart defaults is that you inherit improvements to them. Round-trip the *user-supplied* output instead; that is the set you meant to own. ### Revisions Both forms read the *current* revision unless you say otherwise. `--revision 26` reads the values stored with revision 26, which is how you answer "what changed in the configuration between 26 and 27" without touching the cluster: pull both and diff them locally. Because the values were stored at the time, the comparison is trustworthy even if the chart repository has moved on several versions since. ### Output formats `-o json` and `-o yaml` produce machine-readable output. This matters more than it sounds: the default output is YAML-ish but headed by a human label, so a script that pipes it straight into a YAML parser gets a surprise. Ask for the format you want. ### What it does not tell you `helm get values` reports configuration, not context. The built-in objects a template also had - `.Release`, `.Chart`, `.Capabilities`, `.Files` - are not values and do not appear under `--all`, so a manifest field derived from `.Release.Name` or from a cluster capability will not be explained by anything in this output. Nor does it say whether the live objects still match: it is a statement about what Helm was told and what Helm computed, at the moment of the revision you asked for. ### A note on flag names `--all` here is unrelated to the `-a`/`--all` that `helm list` used to accept. That one widened a status filter and was removed in Helm 4; `helm get values --all` is a different command's flag, means "computed rather than user-supplied", and is very much still there. Conflating them is a small but telling error.