Install Camunda with Helm
Install Camunda 8 Self-Managed on Kubernetes using Helm charts. Two decisions shape the installation: the topology you deploy, and the secondary storage backend you use.
Choose your topology
A Camunda 8.10 deployment is one or more Helm releases, and each release declares its role with global.topology.mode. For the architecture, see deployment topology. For the release roles, see release roles.
| Use case | Topology | Installation guide |
|---|---|---|
| Testing, evaluation, local development | One combined release | Quick install |
| New production deployment, one cluster | One hub release, one orchestration release | Install the deployment topology |
| New production deployment, tenants or analytics | The same, plus one optimize release per Physical Tenant | Configure Physical Tenants across releases |
| Several Orchestration Clusters, one Hub | One hub release, one orchestration release per cluster | Install an Orchestration Cluster release |
| Analytics for a tenant of the split topology | One optimize release per Physical Tenant | Install an Optimize release |
| Existing single-release production deployment | One combined release | Install for production |
For a new production deployment, the split topology is the baseline. A combined release remains supported, remains the chart default, and is the right choice for evaluation, proofs of concept, and 8.9 compatibility.
Choose your secondary storage
This decision is independent of your topology. Both apply to every release that runs an Orchestration Cluster.
| Backend | Guide | Best for |
|---|---|---|
| Elasticsearch or OpenSearch | Using external Elasticsearch | High throughput, and any deployment that uses Optimize |
| Relational database | Install with RDBMS | Organizations that standardize on relational databases |
| Embedded H2 | Quick install | Evaluation only. Single broker, not for production |
Optimize requires Elasticsearch or OpenSearch and can't read from a relational database. An Orchestration Cluster on RDBMS secondary storage can be analyzed with Optimize only if it also exports its records to a separate Elasticsearch or OpenSearch instance, and Optimize is deployed against that instance.
For the trade-offs between backends, see secondary storage architecture.
Before you install
Camunda 8.10 bundles no Elasticsearch, PostgreSQL, or Keycloak subcharts. Camunda recommends the Helm CLI v4, and supports Helm CLI v3 (3.10 or later) until February 10, 2027.
- Provision your databases, secondary storage, and identity provider first. See deploy required dependencies.
- Use the Helm CLI v4 for new installations. See Helm CLI support and chart compatibility.
- Decide which settings belong in
values.yamland which belong in a component'sextraConfiguration. See Helm and application configuration responsibilities.
Upgrading instead of installing
To move an existing deployment to 8.10, see upgrade Camunda 8.9 to 8.10 using Helm. Upgrade in place first; adopting the split topology is a separate step, covered in move from a combined release to the split topology.