What is the difference between helm install, upgrade, and rollback?

Think of these three commands like managing software on your phone. helm install is downloading an app for the first time. helm upgrade is accepting an update that brings new features or fixes. helm rollback is hitting the undo button when an update breaks something, restoring the previous working version. Each action is tracked as a numbered revision so you always have a clear history of what happened and when.

helm install takes a release name and a chart reference, renders the templates with the provided values, and submits the resulting Kubernetes manifests to the API server. It creates revision one of that release and stores the complete rendered manifest, the chart metadata, and the user-supplied values in a Kubernetes Secret in the target namespace. If any resource fails to create, the release is marked as failed. You can use the dash-dash-atomic flag to automatically delete the failed release and all its resources, leaving the namespace clean. The dash-dash-create-namespace flag will create the target namespace if it does not exist, which is especially useful in CI pipelines that bootstrap fresh environments. The dash-dash-wait flag tells Helm to block until all Deployments, StatefulSets, and Jobs reach ready state or until the timeout expires, giving you a synchronous deployment experience.

helm upgrade is where the three-way strategic merge becomes critical. Helm compares three states: the manifest from the previous revision, the current live state in the cluster, and the newly rendered manifest. This three-way diff ensures that out-of-band changes made by Horizontal Pod Autoscaler, Vertical Pod Autoscaler, or manual kubectl edits are not blindly overwritten. The command creates a new revision with an incremented number. If you combine dash-dash-install with upgrade, the command behaves idempotently by creating the release if it does not exist yet, which is the recommended pattern for CI pipelines. The dash-dash-atomic flag on upgrade will automatically roll back to the previous revision if the new deployment fails health checks, combining upgrade and rollback into a single safe operation.

In production, rollback is your safety net. helm rollback takes a release name and a revision number, retrieves the stored manifest for that revision from the release Secret, and applies it to the cluster. This creates yet another new revision, so the history keeps growing forward even during rollbacks. For example, if you are on revision five and roll back to revision three, Helm creates revision six whose manifest matches revision three. This forward-only revision model ensures complete auditability. You can inspect the full history with helm history, compare values between revisions with helm get values, and examine the rendered manifest of any revision with helm get manifest.

A dangerous gotcha is running helm install when a release already exists or running helm upgrade on a nonexistent release, both of which fail. The idiomatic solution is helm upgrade dash-dash-install, which handles both cases. Another trap is assuming rollback restores custom resource definitions. Helm does not manage CRD lifecycle during rollback because CRD deletion would destroy all custom resources cluster-wide. If a failed upgrade included CRD changes, you must manually reconcile them. Always pair dash-dash-atomic with dash-dash-timeout to define a clear deadline for health checks, and set dash-dash-history-max to prevent unbounded revision accumulation that bloats etcd storage over time.