Camunda Helm deployments have traditionally bundled optional infrastructure dependencies like PostgreSQL, Elasticsearch, and Keycloak by including them as Bitnami sub-charts. With recent changes to Bitnami’s container image distribution, there is a required update to this model.
Bitnami (now part of Broadcom) has moved many of its public container images to a legacy repository that no longer receives updates or security patches. Updated images are now available only through paid subscriptions.
For Camunda users relying on the default Bitnami images, this creates several operational risks:
- Security exposure. Legacy images will not receive vulnerability patches.
- Deployment instability. Image references may eventually break if registries change.
- Unsupported infrastructure components. Running unmaintained services is not appropriate for production environments.
Camunda’s approach
To address this change, Camunda is gradually moving toward a deployment model in which infrastructure services are deployed and managed independently of the orchestration platform.
The transition will happen across several upcoming releases to ensure stability while encouraging more maintainable architectures.
Camunda 8.8: Maintain deployment continuity
Camunda 8.8 ensures existing Helm deployments continue to work. Helm charts now reference Bitnami’s legacy image repository, preventing immediate deployment failures. Learn more in the documentation.
For production environments, Camunda also provides enterprise container images for PostgreSQL, Elasticsearch, and Keycloak through the Camunda private registry. These images are patched and maintained.
These images are available to our Enterprise customers and require only:
- Camunda Enterprise registry credentials
- a Helm values override (
values-enterprise.yaml)
This allows organizations to secure their existing deployments while planning their long-term architecture.
Camunda 8.9: Infrastructure services disabled by default
Starting with Camunda 8.9, Helm charts will no longer deploy infrastructure services by default.
The following components will require external configuration:
- PostgreSQL
- Elasticsearch
- Keycloak
Users can still explicitly reenable the Bitnami sub-charts, if required, but the default deployment model will assume the external infrastructure is deployed and available before the Camunda Helm Chart deployment.
This change reflects how most production environments operate. Infrastructure services are typically managed through dedicated tooling, such as managed Cloud services (e.g., Amazon RDS or Elastic Cloud) or Kubernetes operators (e.g., CloudNativePG).
Camunda will provide migration guides and deployment examples with the 8.9 release to support this transition.
Camunda 8.10: Full decoupling from Bitnami infrastructure
With Camunda 8.10, infrastructure sub-charts will be removed from Camunda Helm charts to support the long-term deployment model.
In production, Camunda will be deployed with infrastructure services that are operated and managed independently.
This separation improves:
- Security management
- Operational ownership
- Upgrade reliability
What this means for existing deployments
If you deploy Camunda 8 using the integrated Bitnami sub-charts for PostgreSQL, Elasticsearch, or Keycloak and are running a version earlier than Camunda 8.9, your deployment will be affected. We recommend taking the steps detailed in this section.
Use supported images
If you continue running the embedded services in the short term, we recommend you switch to Camunda’s enterprise container images. These images are patched and maintained, reducing security risk.
Plan infrastructure separation
For new deployments, you will need to run infrastructure services outside the Camunda Helm chart.
Common options include:
- Managed PostgreSQL services such as Amazon RDS
- The CloudNativePG Kubernetes operator
- Elastic Cloud on Kubernetes (ECK)
- The Keycloak Operator
These tools are maintained by their respective vendors and provide better operational control for your production environments. Camunda will provide examples and guides to deploy the most popular options, as well as migration guidance with Camunda 8.9 release.
Use transitional configurations only when necessary
Camunda 8.9 provides configuration switches that let you temporarily continue using the legacy Bitnami images. You can find an example configuration in our GitHub repository.
These options exist to support migration timelines but should not be considered long-term solutions.
Test the external infrastructure early
Before upgrading production environments, we recommend you test deployments early, where:
- Helm sub-charts are disabled.
- Camunda connects to external infrastructure services.
This allows you to validate networking, authentication, and data migration procedures in advance.
Transition timeline
The timeline below maps the key milestones, from Bitnami’s August 2025 change through the Camunda 8.8 compatibility update and into the planned 8.9 and 8.10 steps that make externally managed infrastructure the recommended, then standard, deployment model.
August 2025
Bitnami moved many public images to a legacy repository without future updates.
Camunda 8.8
Helm charts updated to maintain compatibility with the legacy repository. Enterprise images made available.
Camunda 8.9 (planned April 2026)
Infrastructure sub-charts are disabled by default. External infrastructure is recommended as the deployment model.
Camunda 8.10 (planned October 2026)
External infrastructure becomes the standard deployment architecture for new installations.
Looking ahead
These changes ensure Camunda deployments remain secure and operational despite changes in third-party container image distribution. It also enables you to adopt best practices by separating orchestration from infrastructure providing clearer operational boundaries and reducing long-term operational and maintenance risk.
Camunda will continue publishing migration guides and deployment examples to support this transition.
If you need assistance planning your migration, contact your Camunda customer success representative.
