What's new in Camunda 8.9
Important changes in Camunda 8.9 you should consider when upgrading from Camunda 8.8.
Summary of important changes
Important changes introduced in Camunda 8.9 are summarized as follows:
| What's new/changed | Summary |
| Helm chart deployment |
|
| Web Modeler |
|
- See release announcements and release notes for more detail on what's included in Camunda 8.9.
- Ready to upgrade? See the upgrade guides to learn more about upgrading from Camunda 8.8 to 8.9.
Helm chart deployment
Secondary storage must be explicitly configured
The Helm chart no longer defaults to Elasticsearch as the secondary storage type. You must now explicitly set orchestration.data.secondaryStorage.type in your values.yaml to one of elasticsearch, opensearch, or rdbms. Without this configuration, helm install or helm upgrade will fail with a validation error.
For engine-only deployments that do not require secondary storage, the new global.noSecondaryStorage mode is available.
Are you affected?
You are affected if you are upgrading a Self-Managed Helm deployment from 8.8 to 8.9 and have not previously set a secondary storage type explicitly.
Secret configuration migration
Secret configuration keys that were deprecated in Camunda 8.8 have been removed. Using any of the removed keys will cause a hard failure during Helm operations. Additionally, the global.secrets.autoGenerated, global.secrets.name, and global.secrets.annotations keys have been removed, meaning secrets are no longer automatically generated by the chart.
All secret configuration must now use the new standardized pattern:
*.secret.existingSecret— reference an existing Kubernetes Secret*.secret.existingSecretKey— specify the key within the Secret*.secret.inlineSecret— provide a plain-text value (non-production only)
Are you affected?
You are affected if your values.yaml uses any of the legacy secret keys (such as global.elasticsearch.auth.existingSecret, identity.firstUser.password, connectors.security.authentication.oidc.existingSecret, or similar). See the release announcements for the full list.
RDBMS as secondary storage
The Helm chart now supports relational databases as a first-class secondary storage option alongside Elasticsearch and OpenSearch. Configure database connections directly under orchestration.data.secondaryStorage.rdbms in your values.yaml.
Default REST port changed
The Orchestration component's default HTTP port has changed from 8090 to 8080. Update any hardcoded port references in network policies, Ingress rules, or service configuration.
Web Modeler
Logging framework changes from Logback to Log4j2
Web Modeler's restapi component uses Apache Log4j 2 for logging instead of Logback.
You can now also change the log levels at runtime.
Are you affected by 8.9 Web Modeler changes?
The 8.9 changes to the Web Modeler restapi component could affect your organization if you are in a Self-Managed environment and:
- You are using a custom Logback configuration.
- You are using any tools that consume the log files.
Embedded web server changes from Undertow to Tomcat
Web Modeler's restapi component uses Apache Tomcat instead of Undertow.
Are you affected by 8.9 Web Modeler changes?
The 8.9 changes to the Web Modeler restapi component could affect your organization if you are in a Self-Managed environment and:
- You are using a custom Undertow configuration.
- You are using any tools that consume the log files.
Upgrade guides
Camunda 8.9 lays the foundation for future releases. Upgrading ensures compatibility and provides access to enhanced features.
The following guides offer detailed information on how you can upgrade to Camunda 8.9.
| Guide | Description | Who is this guide for? |
| Self-Managed upgrade guide | Evaluate your infrastructure, understand operational changes, and choose the best update strategy for your environment. | Operations and platform administrators of Self-Managed installations. |
| APIs & tools upgrade guide | Plan and execute an upgrade from Camunda 8.8 to 8.9, focusing on API and tools transitions. |
|