For the complete documentation index, see llms.txt.
Skip to main content
Version: 8.9

Upgrade Helm chart

Upgrade a Camunda 8 Self-Managed deployment installation using the official Camunda Helm charts.

earlier versions

If you are upgrading from a version earlier than 8.8, see upgrading from an earlier version.

Plan your move to the Helm v4 CLI

Camunda 8.9 (chart 14.x) is the last minor that supports the Helm v3 CLI. Camunda 8.10 (chart 15.x) requires the Helm v4 CLI. Chart 14.x also supports Helm v4, so switch your tooling to the Helm v4 CLI while running 8.9 to be ready before you upgrade to 8.10. No release-state migration is required when switching CLIs. See Move from the Helm v3 CLI to v4.

Upgrade guides​

Use the following guides to upgrade a Camunda 8 Self-Managed deployment installation using the official Camunda Helm charts.

Upgrade Camunda 8.8 to 8.9 using Helm icon

Upgrade Camunda 8.8 to 8.9 using Helm

Follow the main Helm upgrade guide to perform the required configuration changes and run the Helm upgrade.

Patch upgrades within the same minor version

For patch upgrades within the same minor version, such as 8.8.9 to 8.8.23, there is no separate upgrade guide unless a specific patch's release notes specify additional required actions. Use the Helm chart version matrix to identify the chart version for your target Camunda patch version, and review the relevant patch release notes before upgrading.

Helm chart version​

The Camunda Helm chart version is independent from the Camunda application version. Use the Helm chart version matrix to identify the Helm chart version that deploys Camunda 8.9.

You can also list available chart versions using the Helm CLI:

helm repo update
helm search repo camunda/camunda-platform --versions

Upgrade notes​

Bitnami Docker repository migration​

On August 28, 2025, Bitnami migrated its container images from bitnami to bitnamilegacy. The Camunda Helm charts have been updated to use the new repository.

If you are still using a Camunda Helm chart that references the old repository, use the Helm chart Bitnami legacy values file to override the image repositories.

See the Bitnami GitHub announcement for details.

Web Modeler restapi ephemeral volume​

Patched 8.9 charts replace the chart-managed shared persistent volume claim (PVC) for the Web Modeler restapi component with a per-pod ephemeral volume. The shared PVC (<release>-webmodeler-data) is removed from the chart. Kubernetes creates a dedicated PVC for each restapi pod when it starts and removes it when the pod terminates.

The /tmp directory backed by this ephemeral volume holds only scratch and cache data — Web Modeler content is stored in PostgreSQL, the document store, and Elasticsearch. This is a safe change with no data loss risk.

For most deployments, no action is required on upgrade. The following table shows what to expect based on your webModeler.persistence configuration:

SettingUpgrade behavior
enabled: false (default)No change. Your pod continues using emptyDir. No action required.
enabled: true, no existingClaimhelm upgrade succeeds. Each pod now uses a per-pod ephemeral PVC. The old <release>-webmodeler-data PVC is no longer managed by Helm and becomes orphaned. Clean it up after upgrading if it exists.
enabled: true, existingClaim setNo change. Your pod continues mounting your existing PVC. No action required.

Clean up the orphaned PVC​

If you previously set webModeler.persistence.enabled: true without existingClaim, an orphaned <release>-webmodeler-data PVC may exist in your namespace after upgrading. This PVC is no longer referenced by the chart and will not be deleted automatically.

On cloud providers (GKE, EKS, AKS): The old PVC was most likely in Pending state because the default WaitForFirstConsumer storage class defers disk provisioning until a pod is scheduled. If the restapi pod never reached a Running state, no disk was ever provisioned. The PVC can be safely deleted with no data loss.

On on-premises clusters with Immediate binding: A physical disk may have been provisioned when the PVC was created. Deleting the PVC releases the underlying disk. Since the volume only backed /tmp scratch content, no data is lost.

  1. Confirm the restapi pod is running and ready before proceeding:

    kubectl get pods -n <namespace> | grep restapi

  2. Check whether the orphaned PVC exists:

    kubectl get pvc -n <namespace> | grep webmodeler-data

  3. If the PVC exists, delete it:

    kubectl delete pvc <release>-webmodeler-data -n <namespace>