Where does Helm store the record of a release, and what is inside it?

### One object per revision A Helm release is not a Kubernetes object. Nothing in the cluster natively knows that a Deployment, a Service and a ServiceAccount were installed together by one `helm install`. Helm invents that grouping and persists it itself, and the place it persists it is an ordinary Secret in the release's namespace. The naming is fixed and mechanical: `sh.helm.release.v1.<release-name>.v<revision>`. A release called `gateway` that has been upgraded three times has four objects — `...gateway.v1` through `...gateway.v4` — sitting side by side. They are never rewritten in place; an upgrade creates the next one. The Secret carries the type `helm.sh/release.v1`, which is how you can enumerate every Helm-managed release in a cluster without guessing at names. The namespace is part of the release's identity, not decoration. `gateway` in `telemetry` and `gateway` in `telemetry-staging` are two releases with two independent revision chains, because their record Secrets live in different namespaces. That is also why `helm list` shows one namespace at a time unless you ask for all of them, and why the namespace a command runs against is as load-bearing as the release name. ### What the record actually contains The Secret has one data key, `release`. Decoding it yields a JSON document with roughly these parts: - **`chart`** — the chart itself, file by file: `Chart.yaml`, `values.yaml`, everything under `templates/`, the metadata, and any subcharts that were resolved at install time. The record embeds the chart; it does not point at a repository. - **`config`** — the values the caller supplied on top of the chart's defaults (`-f` files and `--set` flags, merged). - **`manifest`** — the YAML Helm actually rendered and sent to the API server for this revision. - **`hooks`** — the hook manifests, kept apart from the ordinary manifest because they are applied on their own schedule. - **`info`** — status (`deployed`, `superseded`, `failed`, `pending-upgrade` and so on), first-deployed and last-deployed timestamps, the human description, and the notes rendered from `NOTES.txt`. That list explains a lot of Helm's behaviour. `helm rollback 3` works offline, with the chart repository unreachable and the chart directory deleted, because revision 3's record still holds the chart, the values and the rendered manifest. `helm get values` can tell you exactly what someone passed six months ago. And a chart that vendors large files makes every single revision record large, because the chart is copied into each one. One consequence deserves naming: whatever values were supplied are stored in that record. If someone passed a database password through `--set`, it is sitting in the release Secret, readable by anyone who can read Secrets in that namespace, regardless of whether the chart ever rendered it into a Kubernetes Secret of its own. ### The encoding, and why it looks doubly encoded The release object is marshalled to JSON, gzipped, and base64-encoded. That base64 string is then stored as a Secret value — and Kubernetes base64-encodes `data` values itself when it serialises the object. So reading it by hand means decoding twice and then decompressing: The gzip step matters more than it looks. Rendered Kubernetes YAML is extremely repetitive and compresses hard, which is the only reason a chart producing several megabytes of manifest fits in a Secret at all. It also means the practical size budget is a compressed budget, and you cannot predict it by measuring the rendered output. ### Labels, and how Helm finds anything Helm does not scan every Secret. The record carries labels — `owner=helm`, `name=<release>`, `status=<status>`, `version=<revision>` — and Helm queries by label selector. That is what makes `helm list` fast and what makes the status filters work. It is also why a cleanup tool that strips labels from Secrets can make a release vanish from `helm list` while the record object is still sitting there. ### What this model buys and costs The upside is that release state travels with the cluster and with the namespace. Clone the namespace's Secrets and you have carried the release history; back up the cluster and the history is in the backup; grant someone namespace access and Helm works for them with no extra bootstrap. There is no server-side Helm component and no shared state store to operate. The cost is that the state is only as durable, only as private, and only as size-limited as a Secret in that namespace. Delete the records and Helm forgets the release entirely — the workloads keep running, untouched and now unmanaged, because nothing about the record is what keeps them alive. That asymmetry is worth internalising: the record is Helm's bookkeeping, not the deployment.