Does `helm rollback` re-render the chart, and can it work if that chart version is gone?

## What a revision record contains A Helm revision is not a pointer to a chart; it is a self-contained snapshot. Each record carries the chart itself (its templates, its default values, its metadata), the values the caller supplied for that operation, the merged values that resulted, and — crucially — the **rendered manifest**: the exact YAML that rendering produced. `helm rollback` loads the target revision's record and applies that stored manifest. There is no template execution, no values merge, and no network fetch in the path. You can see everything it will use: ```bash helm get manifest indexer-platform -n search --revision 44 # the YAML that will be re-applied helm get values indexer-platform -n search --revision 44 # the values that produced it helm get all indexer-platform -n search --revision 44 ``` ## The consequences that get asked about **A deleted or unreachable chart does not block rollback.** The chart repository being down, the chart version having been yanked, credentials to the registry having expired — none of it matters, because the artefact you need is already in the release record inside the cluster. This is one of the genuinely strong properties of the Helm release model, and it is the reason a rollback is often the fastest recovery available during an incident where the rest of your delivery chain is also unhappy. **Chart source edits since then are irrelevant.** If someone fixed a template bug in the chart repository after revision 44 shipped, rolling back to 44 does not pick that fix up; you get 44's YAML, bug and all. Symmetrically, a rollback cannot be poisoned by a bad chart change made in the meantime. If you want the new templates with the old configuration, that is an upgrade to the new chart version with the old values — not a rollback. **Values files on disk are irrelevant.** People often expect `helm rollback` to re-merge whatever `-f prod-values.yaml` currently says. It does not read files at all. The stored merged values of the target revision are what shipped and what comes back, which is why the values you see with `helm get values --revision N` are the honest record of that deployment rather than whatever your repository now contains. **The next upgrade builds on the restored values.** Because the new revision's stored values are the target revision's values, a subsequent upgrade that reuses the release's existing values starts from the old set. A change someone made two revisions ago through a values override is silently back in force. Worth stating explicitly when handing the release back to a pipeline. ## The one thing a stored manifest cannot pin A manifest describes *desired object state*, not *bits*. If a Deployment's image reference is `registry.example.net/indexer:stable` or any other mutable tag, replaying the manifest byte-for-byte gives the cluster the same string — and the kubelet resolves that string against the registry now, not then. The tag may point at a different digest than it did at revision 44, so the "rolled back" pods can be running newer code than the manifest suggests. Nothing in Helm detects this; the release looks perfectly restored. The fix lives in the chart's values, not in the rollback command: reference images by digest, or treat tags as immutable and never re-push one. A pipeline that stamps a digest into values on every deploy gets a rollback that genuinely restores the software; one that deploys `:stable` gets a rollback that restores only the YAML. The same reasoning covers anything else the manifest names but does not contain — a ConfigMap the chart does not manage, an external configuration service, a sidecar injected by a webhook at admission time — all of which are resolved fresh when the object is applied. ## Reach Finally, a stored manifest has to still be stored. Revision records are pruned to a bounded history depth, so a rollback target that has aged out is simply unavailable, and the recovery becomes a forward upgrade pinned to that old chart version — which *does* need the chart to be fetchable, and *does* re-render it, with all the exposure to since-changed templates that implies. That asymmetry is exactly why teams that care about recoverability keep both a usable history depth and an immutable copy of every chart version they have shipped.