helm rollback: Command Reference for CI/CD

By Kaveh Alemi·Latchkey

Revert a release to a known-good revision.

helm rollback reverts a release to an earlier revision recorded in its history. With --atomic on upgrade it usually happens automatically, but explicit rollback is the manual escape hatch. This reference covers it and helm history.

Common flags and usage

rollback <release>: revert to the immediately previous revision
rollback <release> <revision>: revert to a specific revision number
helm history <release>: list revisions to pick a target
--wait: block until the rolled-back release is Ready
--timeout 5m: bound the wait

Example

shell

helm history web --namespace prod
helm rollback web 4 --namespace prod --wait --timeout 5m

In CI

When you cannot use --atomic (for example a multi-step deploy), wire helm rollback into the failure branch. Read helm history to choose the target revision; a rollback itself creates a new revision, so the history grows forward rather than rewinding.

Using this in CI

A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.

Terminal

# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods

# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info

# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes

Key takeaways

rollback reverts to the previous revision, or a specific one you name.
helm history shows the revisions to roll back to.
A rollback creates a new revision; history moves forward, not back.

Frequently asked questions

helm rollback: Command Reference for CI/CD?

In CI?