Helm chart parameters
Helm chart parameters let you configure the components and behavior of your Camunda Self-Managed installation. The main way to customize these parameters is by using a values.yaml file.
In Helm charts, the values.yaml file defines configuration for your deployment. To tailor your installation to your needs, you can override parameters in this file or provide your own values file. It's best practice to keep the original values.yaml unchanged and maintain a separate file with your custom settings.
Some values in values.yaml support Go template expressions (for example, {{ .Release.Name }}). Values that support templating are marked with "Supports templating" in their description in values.yaml. This includes podLabels, podAnnotations, and global.ingress.host, among others.
The following tables show the top-level configuration sections in values.yaml. Each section controls a specific area of the chart.
Global and orchestration cluster configuration
| Section | Purpose |
|---|---|
global | Configures shared settings that apply across components |
orchestration | Configures orchestration cluster settings |
For pod-level networking options such as dnsPolicy, dnsConfig, and orchestration.hostNetwork, see configure pod networking.
Other Camunda applications
| Section | Purpose |
|---|---|
console | Configures the Camunda Self-Managed Console service |
connectors | Configures the Connector runtime |
identity | Configures the Management Identity service |
optimize | Configures the Optimize web application |
webModeler | Configures the Web Modeler service |
Bitnami subcharts
Bitnami subcharts are intended for development, testing, and transitional use only. They are deprecated in this release and will be removed in Camunda 8.10. Migrate all production deployments to externally managed services or Kubernetes operators before upgrading.
See Deploy required dependencies with Kubernetes operators for the recommended approach, or Migrate from Bitnami subcharts for step-by-step migration instructions.
elasticsearch: Provides an embedded Elasticsearch backend (Bitnami subchart) — deprecated in this release, removed in 8.10. This can be used as a secondary storage backend for evaluations. See secondary storageSecondary storageSecondary storage is used for indexing, search, analytics, and long-term retention. Data in secondary storage is typically exported from primary storage and consumed by tools for observability and analytics. and document-store backends (Elasticsearch/OpenSearch)Elasticsearch/OpenSearchElasticsearch and OpenSearch are search and analytics engines commonly used as document-store secondary storage backends for indexing and querying exported runtime data. They are populated with process orchestration data and consumed by components such as Operate, Tasklist, and Optimize..identityKeycloak: Provides an embedded Keycloak service for Management Identity (Bitnami subchart) — deprecated in this release, removed in 8.10.identityPostgresql: Provides an embedded PostgreSQL database for Management Identity (Bitnami subchart) — deprecated in this release, removed in 8.10.webModelerPostgresql: Provides an embedded PostgreSQL database for Web Modeler (Bitnami subchart) — deprecated in this release, removed in 8.10.
The Helm chart supports embedded Elasticsearch for evaluations. For production, configure the secondary storage backend that fits your requirements. Depending on the component, topology, and version, you can use a document-store backend (Elasticsearch/OpenSearch) or an RDBMS-based secondary store.
See RDBMS configuration and the glossary entry RDBMSRDBMSRDBMS (Relational Database Management System) refers to a user-managed relational database used as a secondary storage backend in Camunda 8 Self-Managed deployments, depending on the component and configuration. An external RDBMS is used for query and retention use cases, not for core workflow execution state..
If you have an existing Camunda deployment using Bitnami subcharts, see the migration guide for step-by-step instructions and automated tooling to migrate your data to Kubernetes operators or managed services with minimal downtime.
Observability
| Section | Purpose |
|---|---|
prometheusServiceMonitor | Creates a Prometheus ServiceMonitor resource for metrics |
Where to find all chart parameters
For a full list of supported Helm chart parameters, including default values and descriptions, see Helm chart parameters on Artifact Hub.
Check this page when installing or upgrading to ensure you use the latest options for your chart version.
Provided values files
In addition to the default values.yaml, the Helm chart repository includes several additional values files for special use cases.
You can use these files individually or combine them with your own overrides.
| File | Purpose |
|---|---|
values.yaml | The default configuration. Includes all chart parameters with baseline values. |
values-local.yaml | Optimized for local development (for example, kind or Minikube). Adjusts resource requests and limits for smaller environments. |
values-enterprise.yaml | Switches Bitnami subcharts to Camunda Enterprise images. For Camunda Enterprise customers only. |
values-bitnami-legacy.yaml | Uses the archived Bitnami open-source images for subcharts instead of the default ones. Deprecated; see bitnami/containers#83267. Provided only as a temporary transition option. |
values-latest.yaml | Tracks the latest versions of applications and subcharts. This may include breaking changes and is intended for early testing. |
values-digest.yaml | Uses the latest snapshot images referenced by digest (for internal development only). |
Creating your own values files
To customize parameters, create an override file (for example, my-overrides.yaml) with custom settings.
This approach is recommended over editing values.yaml directly.
Combining multiple values files
Helm lets you specify multiple values files. You can layer them to build the configuration you need:
helm install camunda camunda/camunda-platform \
-f values.yaml \
-f values-enterprise.yaml \
-f my-overrides.yaml
If the same parameter is defined in more than one file, the value in the last file listed takes precedence. In the example above, settings from my-overrides.yaml override values from both values-enterprise.yaml and values.yaml.