TopolearnChanging running software safely, and undoing it fast, is Helm's main value after install.
Every helm upgrade creates a new revision of the release: the rendered manifests and values are stored, and Helm applies the differences to the cluster. Resources that disappeared from the chart are deleted; new ones are created.
helm history shop -n shoplists revisions with status (deployed,superseded,failed) and description.helm rollback shop 4 -n shopre-applies revision 4's manifests as a new revision (say 7), so history is never rewritten.helm upgrade ... --waitwaits for readiness; with--rollback-on-failure(named--atomicin Helm 3) a failed or timed-out upgrade rolls back automatically.--dry-run=serverrenders and validates against the cluster without changing anything; the helm-diff plugin (helm diff upgrade ...) shows a kubectl-style diff and is popular in CI.
Limits to remember:
- Rollback restores Kubernetes objects, not data. A database migration run by the new version isn't undone.
helm rollbackchanges the cluster but not your values in git; fix git too, or the next pipeline run upgrades again.- If a release is stuck in
pending-upgradeafter an interrupted run, roll back to the last good revision before upgrading again. --history-max(default 10) limits how many revisions are kept.
Example
helm upgrade shop ./shop -n shop -f prod.yaml --wait --timeout 5m
helm history shop -n shop
# REVISION STATUS CHART APP VERSION DESCRIPTION
# 5 superseded shop-1.3.0 1.4.2 Upgrade complete
# 6 deployed shop-1.4.0 1.5.0 Upgrade complete
helm rollback shop 5 -n shop --wait
helm history shop -n shop --max 1
# 7 deployed shop-1.3.0 1.4.2 Rollback to 5
# one-step safety net in CI (Helm 4 flag name)
helm upgrade --install shop ./shop -n shop -f prod.yaml --rollback-on-failure --timeout 5mRemember
- Each upgrade or rollback is a new revision
- Rollback restores objects, not data or your git
- --wait plus automatic rollback-on-failure is a cheap CI safety net
Watch out for
- Treating rollback as undoing a schema migration.