Helm upgrade and rollback workflow
Helm release lifecycle.
helm upgrade creates a new revision; helm history lists revisions; helm rollback reverts to a prior one; --atomic auto-rolls-back on failure.
reinstalling or deleting the release instead.
What's really being asked
Whether you treat a Helm release as a versioned, revisioned object with first-class upgrade and rollback semantics rather than something you tear down and recreate.
The full answer
To upgrade, run helm upgrade myapp ./chart with any new --set or -f overrides, optionally pinning a new chart version with --version. Each successful upgrade produces a new revision recorded in release history. Add --wait to block until resources are ready and --atomic so that if the upgrade fails or times out, Helm automatically rolls back to the last working revision; --timeout bounds how long it waits. To inspect history, run helm history myapp, which lists revision numbers, status, and the chart and app versions. To roll back manually, run helm rollback myapp 3 to return to revision 3, or omit the number to go to the immediately previous one; this itself creates a new revision rather than deleting history. You can preview changes with helm diff if the plugin is installed.
The mistakes people make
Uninstalling and reinstalling the release, hand-editing the live Deployment with kubectl, forgetting --atomic or --wait so failures leave a broken state, or assuming rollback erases revisions.
What usually comes next
What does --atomic do exactly? How is a revision stored? What happens to data and PVCs on rollback? How do hooks interact with upgrades?
A concrete example
You deploy v2 with helm upgrade api ./chart --set image.tag=2.0 --atomic --wait. The new pods crash-loop and fail readiness within the timeout, so --atomic triggers an automatic rollback to revision 4 running v1.9. You confirm with helm history api, see revision 5 marked failed and a new revision 6 marked deployed, and the app stays healthy.
Interview question
Which flag makes a failed or timed-out helm upgrade automatically revert to the last working revision?
- a.--dry-run
- b.--reuse-values
- c.--force
- d.--atomicCorrect
Why? this is the answer
--atomic rolls the release back automatically if the upgrade fails or does not become ready in time. --dry-run only renders without applying, and --force replaces resources rather than guaranteeing rollback.
Just read this? Test yourself on what you have been reading.
Read the original → helm.sh
- #helm
- #kubernetes
- #rollback
- #upgrade
- #release-management
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles