Rolling Back Releases
1. Rolling Back Release
| Command | Description | Flags |
|---|---|---|
| helm rollback | Rolls back a release to a previous revision | --debug, --dry-run, --recreate-pods |
Note: The rollback command will reinstall the previous revision of the release. If you want to recreate pods, use
--recreate-pods.
2. Rolling Back to Revision
| Option | Values | Description |
|---|---|---|
| helm rollback [RELEASE_NAME] [REVISION] | helm rollback my-release 3 |
Rolls back a release to a specific revision |
| helm rollback [RELEASE_NAME] --to-revision | helm rollback my-release --to-revision 5 |
Rolls back to a specific revision using the --to-revision flag |
Note: The rollback command will reinstall the specified revision, effectively reverting the release to that state.
3. Viewing Release History
| Command | Description | Flags |
|---|---|---|
| helm history | Lists the history of a release | --max, --output, --namespace |
Note: The history includes all releases, including those that have been deleted or superseded.
4. Understanding Rollback Behavior
| Behavior | Description | Notes |
|---|---|---|
| helm rollback | Reinstalls a previous release version | Restores the state of the release to a previous revision |
| Revision History | Tracks all release revisions | Each rollback creates a new revision in the history |
| Rollback Scope | Can target specific revision | Defaults to the previous revision if no revision specified |
| Resource Restoration | Restores resources to previous state | Does not delete newly added resources during the rollback |
| Values Override | Can override values during rollback | Uses the previous revision's values unless overridden |
Note: Rollback does not remove resources added after the target revision.
Warning: Rollback can cause data loss if resources are not properly backed up.
5. Using Atomic Rollback
Atomic rollback ensures that if a rollback operation fails, the release remains in its original state. Helm supports atomic rollbacks through the --atomic flag.
| Flag | Description | Default |
|---|---|---|
| --atomic | Rollback to the previous release if the new release fails | false |
Note: If the rollback fails, Helm will attempt to restore the previous release state.
Warning: Atomic rollbacks are not supported in all Helm versions. Ensure compatibility with your Helm version.
6. Forcing Rollback
| Option | Values | Description |
|---|---|---|
| --force | --force |
Force rollback even if the release is in a failed state |
| --recreate-pods | --recreate-pods |
Recreate pods for resources that support pod recreation |
| --timeout | --timeout <duration> |
Timeout for rollback operation (e.g., --timeout 5m) |
Note: The
--force flag is particularly useful when rolling back a release that has failed during deployment, allowing you to restore a previous working version.
7. Setting Rollback Timeout
| Option | Values | Description |
|---|---|---|
| --timeout | 300s |
Timeout for rollback operations in seconds |
| --timeout <duration> | 5m |
Alternative format using minutes or hours (e.g., 5m, 1h) |
Note: If rollback exceeds the specified timeout, Helm will abort and report an error.
8. Waiting for Rollback Completion
| Option | Values | Description |
|---|---|---|
| --timeout | 5m0s |
Timeout for waiting for rollback completion |
| --wait | false |
Wait for resources to be updated and ready |
| --waitForJobs | false |
Wait for any Jobs to complete before marking rollback as ready |
Note: The
--wait flag ensures that the rollback operation waits until all resources are updated and ready before marking the rollback as complete.
9. Cleaning Up on Failed Rollback
| Option | Values | Description |
|---|---|---|
| --cleanup-on-fail | true |
Deletes the release on rollback failure |
Note: When
--cleanup-on-fail is used, Helm will delete the release if rollback fails. This prevents leaving partially deployed releases in the cluster.
Warning: Using
--cleanup-on-fail permanently deletes the release and its resources. Ensure backups or version control are in place before using this option.
10. Troubleshooting Failed Rollbacks
Example: Debugging rollback issues
helm rollback my-release 1 --debug
helm get manifest my-release --revision 2
| Issue | Possible Cause | Solution |
|---|---|---|
| Rollback fails with "no revision" | Revision does not exist or was deleted | Use helm history my-release to check available revisions |
| Rollback hangs or times out | Resource limits or long-running operations in templates | Check helm status my-release, increase timeout with --timeout |
| Rollback applies incorrect values | Values file mismatch or override conflict | Verify helm get values my-release --revision 1 matches desired state |
| Rollback fails due to resource conflicts | Resource name or namespace conflict in rollback | Use --force to override existing resources, or clean up manually |
Note: Always backup your release before attempting a rollback using
helm get all <release-name>.
Warning: Using
--force may cause data loss if resources are not compatible.