Helm release lifecycle management covering installs, revisions, upgrades, rollbacks, and safe handling of persistent data with backups, hooks, and chart specific upgrade requirements
In this lesson we’ll cover lifecycle management with Helm: what a release is, how Helm tracks revisions, how to perform upgrades and rollbacks, and how to handle persistent data safely during those operations. We’ll use concrete examples (Bitnami charts) and show the exact commands and outputs so you can reproduce the workflow.
Before you begin, make sure you have Helm and kubectl installed and your KUBECONFIG points to a working cluster. See the Helm installation guide and Kubernetes setup docs for more details.
What does “lifecycle management” mean in Helm terms?
A Helm release represents an installed chart and the Kubernetes objects it created.
Because Helm records which objects belong to a release, it can upgrade, downgrade (rollback), and uninstall a release without affecting other releases — even if they come from the same chart.
Helm tracks revisions for each release so you can inspect history and restore previous manifest states.
For example, you can install the same chart twice and manage each installation independently:
Next, we’ll create a release and walk through lifecycle operations.Installing a specific chart version
You can install a specific chart version with the --version flag. In this example we install an older Bitnami NGINX chart to see an upgrade in action:
This release is running NGINX 1.19.2 (an older app version). Upgrading the release will move it to a newer chart / app version.Upgrading a release
To upgrade a release, tell Helm which release to upgrade and which chart (or chart version) to use. Helm computes the delta between current and desired manifests and applies the necessary changes.
$ helm upgrade nginx-release bitnami/nginx
Helm returns details including the new revision:
Release "nginx-release" has been upgraded. Happy Helming!NAME: nginx-releaseLAST DEPLOYED: Mon Nov 15 19:25:55 2021NAMESPACE: defaultSTATUS: deployedREVISION: 2TEST SUITE: NoneNOTES:CHART NAME: nginxCHART VERSION: 9.5.13APP VERSION: 1.21.4
During the upgrade the old pod is terminated and a new pod is created. Confirm the new pod and the updated image:
$ kubectl get podsNAME READY STATUS RESTARTS AGEnginx-release-7b78f4fdcd-2zr7k 1/1 Running 0 2m50s
$ helm history nginx-releaseREVISION UPDATED STATUS CHART APP VERSION DESCRIPTION1 Mon Nov 15 19:20:51 2021 superseded nginx-7.1.0 1.19.2 Install complete2 Mon Nov 15 19:25:55 2021 deployed nginx-9.5.13 1.21.4 Upgrade complete
Rolling back a release
If the upgrade introduced an undesired change, Helm can rollback to a previous revision. Rollback re-applies the manifest state of a prior revision and Helm records the rollback as a new revision:
$ helm rollback nginx-release 1
Helm confirms success:
Rollback was a success! Happy Helming!
The history will show the rollback action as a new revision:
$ helm history nginx-releaseREVISION UPDATED STATUS CHART APP VERSION DESCRIPTION1 Mon Nov 15 19:20:51 2021 superseded nginx-7.1.0 1.19.2 Install complete2 Mon Nov 15 19:25:55 2021 superseded nginx-9.5.13 1.21.4 Upgrade complete3 Mon Nov 15 19:30:00 2021 deployed nginx-7.1.0 1.19.2 Rollback to 1
Important: rollbacks restore Kubernetes resource manifests (Deployments, StatefulSets, Services, etc.), not the runtime data stored on persistent volumes.
Helm rollbacks operate on resource manifests. For persistent data (databases, PVs), you must use backups or chart hooks that perform data snapshots and restores. See chart-specific documentation for safe upgrade/rollback procedures.
Handling chart-specific upgrade requirements and credentials
Some charts enforce supplying existing credentials or parameters during upgrades to prevent accidental data loss or misconfiguration. For example, Bitnami’s WordPress chart requires current passwords during an upgrade; otherwise Helm will fail and instruct how to retrieve and pass the existing passwords:
$ helm upgrade wordpress-release bitnami/wordpressError: UPGRADE FAILED: template: wordpress/templates/NOTES.txt:83:4: executing "wordpress/templates/NOTES.txt" at <include "common.errors.upgrade.passwords.empty" (dict "validationErrors" $passwordValidationErrors "context" $)>: error calling include: template: wordpress/charts/common/templates/_errors.tpl:21:48: executing "common.errors.upgrade.passwords.empty" at <fail>: error calling fail:PASSWORDS ERROR: You must provide your current passwords when upgrading the release. Note that even after reinstallation, old credentials may be needed as they may be kept in persistent volume claims. Further information can be obtained at https://docs.bitnami.com/general/how-to/troubleshoot-helm-chart-issues/#credential-errors-while-upgrading-chart-releases'wordpressPassword' must not be empty, please add '--set wordpressPassword=$WORDPRESS_PASSWORD' to the command. To get the current value: export WORDPRESS_PASSWORD=$(kubectl get secret --namespace "default" wordpress-release -o jsonpath="{.data.wordpress-password}" | base64 --decode)'mariadb.auth.rootPassword' must not be empty, please add '--set mariadb.auth.rootPassword=$MARIADB_ROOT_PASSWORD' to the command. To get the current value: export MARIADB_ROOT_PASSWORD=$(kubectl get secret --namespace "default" wordpress-release-mariadb -o jsonpath="{.data.mariadb-root-password}" | base64 --decode)'mariadb.auth.password' must not be empty, please add '--set mariadb.auth.password=$MARIADB_PASSWORD' to the command. To get the current value: export MARIADB_PASSWORD=$(kubectl get secret --namespace "default" wordpress-release-mariadb -o jsonpath="{.data.mariadb-password}" | base64 --decode)
This requirement exists because upgrades that touch databases or other external systems may need administrative credentials to perform schema migrations or data transformations. To handle these situations safely:
Inspect chart documentation and default values (helm show values <chart>) before upgrading.
Use --set or a values file to supply required parameters.
For databases or PV-backed workloads, take consistent backups before upgrading.
Use hooks or external backup tooling
For workloads that store critical data, use pre-upgrade hooks for snapshots or external backups. Hooks can run jobs to snapshot databases or copy data to external storage and can also be used to validate or prepare the system before applying new manifests.
Summary — best practices for Helm lifecycle management
Treat Helm releases as the source of truth for Kubernetes resource declarations.
Use helm history and helm rollback to inspect and revert manifest-level changes.
For data-bearing applications:
Read chart docs for upgrade-time requirements (passwords, migrations).
Take consistent backups (snapshots, database dumps) before upgrades.
Consider chart hooks or external operators for safe migrations and restores.
Automate testing of upgrades in staging before applying them in production.
That covers the essentials of lifecycle management with Helm: installs create releases, Helm tracks revisions, upgrades and rollbacks operate on manifests, and persistent data requires explicit backup/restore planning. Happy Helming!
