What is a Helm release, and how do upgrades and rollbacks work?
Quick Answer
A release is Helm's tracked record of one specific installation of a chart into a cluster — every `helm upgrade` creates a new numbered revision of that same release (rather than a brand-new release), preserving the full history of what values/chart version were used at each point. `helm rollback <release> <revision>` reverts the release back to a previous revision's exact rendered manifests, applying whatever changes are needed to bring the cluster back to that earlier state — conceptually similar to a Kubernetes Deployment's own revision history and rollback mechanism, but operating at the level of a whole chart's set of resources rather than a single Deployment.
Detailed Answer
Installing creates a release
helm install my-app ./mychart --values production-values.yaml
my-app is now a release — a named, tracked instance of mychart installed into a specific namespace, at revision 1. Helm records this release's state (which chart version, which values were used, the fully-rendered manifests that resulted) internally, typically as a Secret in the same namespace.
Upgrading creates a new revision of the same release
helm upgrade my-app ./mychart --values production-values.yaml --set image.tag=2.0.0
This doesn't create a new release — it creates revision 2 of the existing my-app release, computing the diff between the previously-rendered manifests and the newly-rendered ones (based on the updated chart version and/or values) and applying just that diff to the cluster.
helm history my-app
# REVISION UPDATED STATUS CHART APP VERSION
# 1 Mon Jan 1 10:00:00 2024 superseded mychart-1.0.0 1.0.0
# 2 Tue Jan 2 14:30:00 2024 deployed mychart-1.1.0 2.0.0
Rolling back
helm rollback my-app 1
Reverts the release back to revision 1's exact rendered manifest state — Helm re-applies revision 1's fully-rendered YAML, effectively undoing whatever revision 2 changed. This creates yet another new revision (e.g., revision 3) whose content matches revision 1 — Helm's history is append-only; a rollback is recorded as a new event in the timeline, not a deletion of revision 2 from history.
helm history my-app
# REVISION UPDATED STATUS CHART APP VERSION
# 1 Mon Jan 1 10:00:00 2024 superseded mychart-1.0.0 1.0.0
# 2 Tue Jan 2 14:30:00 2024 superseded mychart-1.1.0 2.0.0
# 3 Wed Jan 3 09:15:00 2024 deployed mychart-1.0.0 1.0.0 <- rollback, recorded as a new revision
How this relates to (and differs from) a Deployment's own rollback
A Kubernetes Deployment itself already has revision history and kubectl rollout undo (see the workload controllers topic) — but that only covers that one Deployment's Pod template changes. A Helm release's rollback operates one level higher: it can revert an entire chart's worth of resources together — a Deployment, a ConfigMap, a Service, an Ingress, all changed consistently as part of one upgrade — as a single coordinated rollback, rather than needing to manually roll back each affected object independently.
Helm's revision history is a powerful safety net for complex, multi-resource applications, but it's not a substitute for understanding what changed and why a rollback is needed — helm diff (a popular third-party plugin) or comparing helm get manifest output between revisions helps confirm exactly what a rollback will actually change before running it, rather than rolling back blind and hoping for the best.