8.10 Release announcements
Supported environment changes, breaking changes, and deprecations in Camunda 8.10.
| Minor release date | End of standard maintenance | Release notes | Upgrade guides |
|---|---|---|---|
| 13 October 2026 | 11 April 2028 | 8.10 release notes | 8.10 upgrade guides |
- See release notes to learn more about new features and enhancements.
- Refer to the quality board for an overview of known bugs by component and severity.
Supported environments
Amazon Aurora PostgreSQL 14 removed, 18 added
Camunda 8.10 drops support for Amazon Aurora PostgreSQL 14 and adds support for version 18. Supported versions are now 15, 16, 17, and 18.
- Aurora PostgreSQL 14 has reached the end of standard support on AWS.
- Migrate your Aurora cluster to a supported version before moving to Camunda 8.10.
Elasticsearch 9.2 and 9.3 no longer supported
Camunda 8.10 raises the minimum supported Elasticsearch 9.x version to 9.4. Supported Elasticsearch versions are now 8.19+ and 9.4+.
- Upgrade Elasticsearch 9.2 or 9.3 clusters to 9.4 or later before moving to Camunda 8.10.
H2 2.3 no longer supported
Camunda 8.10 drops support for H2 2.3. Only H2 2.4 is now supported.
- The bundled H2 driver in Camunda images is on the 2.4 line.
- H2 remains supported for development, testing, and evaluation only. Production use is not recommended.
Microsoft SQL Server 2019 no longer supported
Camunda 8.10 drops support for Microsoft SQL Server 2019. Supported versions are now 2022 and 2025.
- SQL Server 2019 has reached the end of mainstream support from Microsoft.
- Upgrade your SQL Server instance to a supported version before moving to Camunda 8.10.
OpenSearch 3.4 and 3.5 no longer supported
Camunda 8.10 raises the minimum supported OpenSearch 3.x version to 3.6. Supported OpenSearch versions are now 2.19+ and 3.6+.
- Upgrade OpenSearch 3.4 or 3.5 clusters to 3.6 or later before moving to Camunda 8.10.
Oracle 23ai rebranded as Oracle 26ai
Oracle has rebranded Oracle Database 23ai as Oracle AI Database 26ai, effective with the October 2025 Release Update (RU 23.26). The internal version continues to use the 23.x code line; the transition requires no database upgrade or application recertification. Camunda 8.10's supported Oracle versions are 19c and 26ai.
PostgreSQL 14 no longer supported
Camunda 8.10 drops support for PostgreSQL 14. Supported versions are now 15, 16, 17, and 18.
- PostgreSQL 14 reached the end of its standard support window.
- Upgrade your PostgreSQL instance to a supported version before moving to Camunda 8.10.
New GCP region
Camunda 8.10 adds support for the Montréal, North America (northamerica-northeast1) region in Camunda 8 SaaS.
MariaDB 12.3 now supported
Camunda 8.10 adds support for MariaDB 12.3 LTS. Supported versions are now 10.11, 11.4, 11.8, and 12.3.
MySQL 9.7 now supported
Camunda 8.10 adds support for MySQL 9.7 LTS. Supported versions are now 8.4 and 9.7.
Agentic orchestration
AI Agent connector: Conversation storage SPI redesign
Camunda 8.10.0-alpha1 redesigns the conversation storage SPI used by custom AI Agent storage backends. Built-in stores (in-process, Camunda Document, AWS AgentCore) are migrated transparently; only custom ConversationStore implementations are affected.
Action: If you maintain a custom ConversationStore, migrate to the new SPI. See the updated AI Agent connector customization guide for the new shape, and the migration guide on GitHub for a step-by-step walkthrough.
AI Agent connectors: redesigned templates, legacy templates deprecated
Camunda 8.10 introduces redesigned element templates for the AI Agent Task and AI Agent Sub-process connectors. The new templates broaden support for AI providers and backends, helping you use LLM routes that meet your organization's requirements. Provider-specific capabilities, such as thinking and prompt caching, can support cheaper, faster, and more transparent agent behavior. The legacy element templates are deprecated as of Camunda 8.10, but keep working; existing implementations aren't required to migrate immediately.
Action: Use the new element templates for new AI Agent implementations. See the new model providers page for the redesigned provider configuration, and the upgrade guide for moving an existing legacy implementation to the new templates.
AI Agent connector: new native (v2) element templates, v1 deprecated
Camunda 8.10 introduces new v2 element templates for the AI Agent Task and AI Agent Sub-process connectors, running on new job types and giving native access to each LLM provider's own SDK and wire format (including reasoning/extended thinking and prompt caching configuration).
The original (v1) element templates are deprecated as of Camunda 8.10.
Action: Use the v2 element templates for new AI Agent implementations.
AI Agent Sub-process and AI Agent Task element templates updated
The AI Agent Sub-process and AI Agent Task element templates are updated in Camunda 8.10 to support the new agent visibility and monitoring and agent tool configuration features.
Action: If you modeled the agent element before Camunda 8.10, update to the latest AI Agent Sub-process or AI Agent Task element template. Open the process in Modeler, select the agent element, click Update element template in the properties panel to apply the latest template version, and redeploy the process.
APIs & tools
Migrate your API integrations, SDKs, and generated clients to Camunda 8.10 using the 8.10 APIs & Tools migration guide.
Camunda clients (Java client, Spring SDK, Node.js SDK) and Camunda Process Test are forward-compatible with the Orchestration Cluster, meaning you can upgrade the cluster and clients independently. For example, you can run a client on 8.8 against a cluster on 8.10, see Client and API compatibility.
POST /v2/message-subscriptions/search now returns start event subscriptions
Starting with 8.10, the POST /v2/message-subscriptions/search endpoint returns both start event and intermediate event message subscriptions. Previously, only intermediate event subscriptions were returned.
A new messageSubscriptionType enum field is included in each result. Existing (legacy) data has NULL for this field.
Action: If your integration expects the endpoint to return only intermediate event subscriptions, add the following filter to restore the previous behavior:
{
"filter": {
"messageSubscriptionType": { "$neq": "START_EVENT" }
}
}
GET /decision-instances/{decisionEvaluationInstanceKey} now validates the key format
The Get decision instance endpoint previously returned 404 Not Found when the decisionEvaluationInstanceKey path parameter contained invalid characters that did not match the required pattern ^[0-9]+-[0-9]+$. The endpoint now correctly returns 400 Bad Request in this case, while 404 Not Found is reserved for well-formed keys that do not exist.
Action: Update any client code or error handling that relied on receiving 404 Not Found for malformed keys to also handle 400 Bad Request.
JobIntent.COMPLETED follow-up event no longer carries variables by default
Starting with 8.10, the JobIntent.COMPLETED follow-up event is emitted without variables by default. This prevents ExceededBatchRecordSizeException when a job completes with very large variables. Without this setting, the JobIntent.COMPLETE command could be rejected and the job could time out.
Action: If your exporter or integration reads completion variables from the JobIntent.COMPLETED event, read them instead from the JobIntent.COMPLETE command record or the follow-up ProcessEvent.TRIGGERING event, both of which always carry the variables. To restore the pre-8.10 behavior where JobIntent.COMPLETED events carry variables, set camunda.processing.engine.job.include-variables-in-job-completed-event to true.
Optimize GET /api/readyz no longer rejects requests that carry an Authorization header
Starting with Camunda 8.10.0-alpha5, the Optimize health readiness endpoint (GET /api/readyz) ignores an Authorization header instead of rejecting the request. Previously, a request that included the header was rejected with a client error status code. It now returns the readiness status (200 or 503), as it does for a request without the header.
This aligns the endpoint with the other public endpoints of the Orchestration Cluster, which also accept and ignore a superfluous Authorization header.
Action: No action is required for Kubernetes readiness and liveness probes, as these do not send an Authorization header. If you have a client or monitoring check that relies on the endpoint rejecting requests that carry an Authorization header, update it to expect the readiness status instead.
Removal of legacy APIs, Tasklist V1-dependent features, and Zeebe Process Test
Starting with Camunda 8.10.0-alpha2, Camunda removes the legacy component APIs and related features that were deprecated in 8.8.
The following items are removed:
- The Operate API (8.9 documentation)
- The Tasklist API (8.9 documentation) and Tasklist V1 mode
- Tasklist V1-dependent features such as user task access restrictions (8.9 documentation) and public start forms
- Zeebe Process Test
Action: Migrate integrations and testing workflows to the current replacements:
- Use the Orchestration Cluster REST API instead of the removed Operate API and Tasklist API.
- Use user task authorization and authorization-based access control instead of user task access restrictions.
- Use authenticated Tasklist starts or build your own application with Camunda Forms and the Orchestration Cluster REST API instead of public start forms.
- Use Camunda Process Test instead of Zeebe Process Test.
Migrate to the Orchestration Cluster REST API
Console SM and Web Modeler APIs deprecated
With Camunda 8.10, the Console Self-Managed API and the Web Modeler API are deprecated in favor of the new public Camunda Hub API. The legacy endpoints remain available for at least two minor versions and are scheduled for removal in 8.12.
Action: Plan to migrate integrations from the Console Self-Managed and Web Modeler APIs to the public Camunda Hub API before 8.12.
key sort field on the Tenant search endpoint deprecated
The key sort field on the Search tenants endpoint (POST /v2/tenants/search) is now deprecated. Sorting by this internal numeric identifier is inconsistent with other Identity entities (User, Group, and Mapping Rule), which do not expose key-based sorting, and tenants can no longer be filtered by key either.
Action: Sort by name or tenantId instead.
Deleting a process definition with running instances defers history deletion
The delete resource endpoint now accepts process definition deletion when the definition still has running instances. Instead of rejecting the request or waiting for physical removal, the definition drains: new instances are blocked immediately, running instances continue to completion, and the definition is removed automatically afterwards.
As a result, when deleteHistory is true, the batchOperation field in the response is null for such a definition. Its history is removed as part of the draining lifecycle rather than through an immediately-returned batch operation. The field is still populated for decision requirements definitions and for process definitions that are already fully deleted.
Action: If you read batchOperation from the delete response to track history deletion, handle a null value: the definition is draining. Track progress through the process definition state (DRAINING) or the zeebe_process_definitions_draining_count metric instead.
Camunda Spring Boot Starter now bundles Spring Boot 4.1.x
Starting with Camunda 8.10, the default Camunda Spring Boot Starter (camunda-spring-boot-starter & camunda-spring-boot-4-starter) is bundled with Spring Boot 4.1.x (up from 4.0.x in 8.9).
Action: Migrate your application to Spring Boot 4.1.x. See the version compatibility table for details.
Connectors
Connector secret filter now defaults to STRICT
Starting with 8.10.0, the connector secret filter defaults to STRICT instead of DISABLED. In practice, this means a secret in a connector field only resolves at runtime if that same secret was already referenced in that same field at modeling time, in the deployed BPMN.
Action: Before upgrading, confirm that every connector field which resolves a secret already references that secret in the deployed BPMN. If a field relies on resolving a secret it doesn't reference, add the reference. To temporarily unblock connector jobs while you update the model, you can set camunda.connector.secret-resolver.secret-filter.mode to DISABLED, but this restores the affected behavior described in Notice 61. Return to STRICT after updating the model. LAX doesn't help here — it only changes behavior when the process definition can't be retrieved, not when a field simply doesn't declare the secret.
JWT-authorized inbound webhooks require issuer, audience, and expiration claims
Starting with Camunda 8.10, inbound webhooks configured with JWT authorization validate the token's iss and aud claims and reject tokens without an exp claim. The Issuer and Audience fields are now required in the element templates for the Webhook connector, Amazon EventBridge inbound connector, and A2A Client webhook.
Existing JWT-authorized inbound webhooks modeled with earlier template versions don't contain these fields and can't activate after the upgrade. The connector runtime reports the affected connector as DOWN.
Action: Update each affected element to the latest template version, set Issuer and Audience to the expected claim values, and redeploy the process. Ensure callers provide JWTs with matching iss and aud claims and a valid exp claim.
Webhook responseBodyExpression rejected at deployment
Starting with 8.10, deploying a webhook connector that uses the deprecated responseBodyExpression property fails with a validation error. This property was superseded by responseExpression in 8.6 and removed from element templates at that time.
The connector runtime reports the connector as DOWN, and the validation error is included in the connector's status message.
Action: Replace responseBodyExpression with responseExpression in your BPMN diagrams before deploying to 8.10. Unlike responseBodyExpression, which set only the response body, responseExpression returns a full HTTP response:
={
"body": {"myCustomKey": request.body.myDataKey1},
"statusCode": 201,
"headers": {"Content-Type": "application/json"}
}
Connectors with a single operation are renamed after the operation
Connectors that provide a single operation are renamed in Modeler so their name describes the action they perform instead of the product they connect to. For example, the REST Outbound Connector is now named Send REST Request. Connectors with several operations keep their names and expose their operations as searchable entries instead.
Only the name shown in Modeler changed. Template IDs, versions, connector types, and runtime behavior are unchanged, so existing process models continue to run and do not need to be remodeled or redeployed.
Action: Search for the new name when you add one of these connectors to a process, and update your own documentation, templates, and training material that refer to the previous names.
Renamed connectors:
| Previous name | New name |
|---|---|
| Amazon EventBridge Outbound Connector | Send Event to AWS EventBridge |
| Amazon SNS Outbound connector | Publish Message to AWS SNS |
| Amazon SQS Outbound Connector | Send Message to AWS SQS |
| AWS Bedrock AgentCore Runtime | Invoke Agent in AWS Bedrock AgentCore Runtime |
| AWS Bedrock Code Interpreter Outbound Connector | Run Code with AWS Bedrock Code Interpreter |
| AWS Bedrock Knowledge Base Outbound Connector | Retrieve Documents from AWS Bedrock Knowledge Base |
| AWS Lambda Outbound Connector | Invoke AWS Lambda Function |
| AWS SageMaker Outbound Connector | Run Inference with AWS SageMaker |
| AWS Textract Outbound Connector | Extract Text from Document with AWS Textract |
| Google Gemini Outbound Connector | Generate Content with Google Gemini |
| GraphQL Outbound Connector | Send GraphQL Request |
| Hugging Face Outbound Connector | Run Inference on Hugging Face |
| Kafka Outbound Connector | Publish Message to Kafka |
| RabbitMQ Outbound Connector | Publish Message to RabbitMQ |
| REST Outbound Connector | Send REST Request |
| RPA Connector | Run RPA Script |
| SendGrid Outbound Connector | Send Email with SendGrid |
| SOAP Connector | Send SOAP Request |
| SQL Database Connector | Execute SQL Statement on Database |
Inbound connectors are not renamed. For Kafka and RabbitMQ, only the outbound connector is renamed.
Data
Default RocksDB memory allocation strategy changed to FRACTION
Starting with Camunda 8.10, the default RocksDB memory allocation strategy changes from PARTITION to FRACTION. With FRACTION, RocksDB memory is allocated as a fraction of total available memory (default 0.1, or 10%) instead of scaling with the number of partitions per broker. This may result in a different amount of memory being allocated to RocksDB after upgrading.
Action: Review your broker memory sizing before upgrading. To keep the previous behavior, explicitly set camunda.data.primary-storage.rocksdb.memory-allocation-strategy to PARTITION (environment variable CAMUNDA_DATA_PRIMARYSTORAGE_ROCKSDB_MEMORYALLOCATIONSTRATEGY=PARTITION). To adopt the new default, test the FRACTION strategy first to find the right memory-fraction value for your deployment.
Elasticsearch and OpenSearch exporter defaults changed for Optimize mode and job records
Starting with Camunda 8.10, the Elasticsearch and OpenSearch exporters ship with two updated defaults:
index.optimizeModeEnabledis nowtrue(previouslyfalse). The exporter restricts exported record value types to those consumed by Optimize and drops other record value types.index.jobis nowfalse(previouslytrue). Whenindex.optimizeModeEnabledistrue, Optimize mode controls which record value types are exported, so the individualjobflag has no effect.
Action: Review your exporter configuration before upgrading. If your deployment relies on record value types that Optimize mode does not cover, set index.optimizeModeEnabled: false and explicitly configure the record value types you need.
Optimize Self-Managed no longer flattens object variables by default
Starting with Camunda 8.10, Self-Managed Optimize no longer imports object variable values by default. Object variables are no longer flattened into per-property fields, and their raw values are no longer stored. This significantly reduces Optimize storage and CPU usage, and aligns Self-Managed with the default Camunda 8 SaaS has used for years.
This change is Self-Managed only; SaaS is unaffected, as it already runs with this behavior disabled.
- Object-heavy processes previously measured 5.9-48.8x more Optimize variable storage on Self-Managed than SaaS for identical workloads.
- If you rely on object variable properties in reports, filters, or Raw Data Reports, opt in by setting
zeebe.includeObjectVariableValue: true(environment variableCAMUNDA_OPTIMIZE_ZEEBE_INCLUDE_OBJECT_VARIABLE=true). - Optimize logs a
WARNon startup whenever object variable values are not being imported. The message includes the opt-in setting.
Action: Decide whether your Self-Managed deployment needs flattened object variables. If it does, set zeebe.includeObjectVariableValue: true before upgrading to 8.10.
New SaaS clusters default to business_ variable include filter for Optimize
Starting with Camunda 8.10, new SaaS clusters include a default business_ variable include filter in Optimize data filter settings. Only variables whose names start with business_ are exported to Optimize. Variables not matching this prefix are permanently excluded from Optimize.
This default does not apply to existing clusters. Existing clusters show data filters disabled with a one-click opt-in — no automatic migration occurs.
Action: If your Optimize reports or dashboards on new SaaS clusters rely on variables not prefixed with business_, update the variable include filter in Camunda Hub cluster settings before creating the cluster or immediately after.
Deployment
Bitnami subcharts removed from the Helm chart
Camunda 8.10 (chart 15.x) no longer bundles the Bitnami subcharts for PostgreSQL, Elasticsearch, and Keycloak. Camunda 8.9 is the last minor that ships them. Helm installations must connect to external infrastructure instead, such as managed databases and search services, Kubernetes operators, or customer-owned images.
Action: If you still use Bitnami subcharts on 8.8 or 8.9, migrate to external or vendor-supported infrastructure on 8.9 before upgrading to 8.10; the 8.10 Helm chart has no Bitnami-based fallback. See Migrate from Bitnami subcharts.
Individual component Docker images no longer produced
Camunda no longer produces the following individual component Docker images in Camunda 8.10 and later, or in Camunda 8.9 from patch release 8.9.12:
Action: Before upgrading to Camunda 8.10, or to Camunda 8.9.12 or later, switch to the unified camunda/camunda Docker image.
Operate and Tasklist health indicators replaced by a unified schema readiness check
Camunda 8.10 removes the Operate- and Tasklist-specific Elasticsearch/OpenSearch health indicators (indicesCheck and searchEngineCheck). A single schemaReadinessCheck now backs the gateways readiness probe; it is set once at startup, after the schema is initialized and the cluster reports green or yellow. searchEngineStatus reflects the current health status of Elasticsearch/OpenSearch and can be fetched via /actuator/health (it is not part of the readiness probe group).
Unused PVC in Optimize is unmounted
An unused volume mounted at /camunda in Optimize has been removed from the Helm chart. Optimize did not use this volume.
By default, this mount used an emptyDir, so no PVC cleanup is required. However, if you set optimize.persistence.enabled=true in values.yaml, the PVC may still exist in your Kubernetes cluster even though Optimize no longer mounts it.
Action: If you previously enabled optimize.persistence.enabled=true, delete the leftover PVC to reclaim storage quota. The claim name is <releaseName>-camunda-platform-optimize-data.
Ingress-nginx annotation defaults deprecated in the Helm chart
The Helm chart used to ship Ingress-nginx-specific defaults in global.ingress.annotations and orchestration.ingress.grpc.annotations. Helm deep-merges maps, so setting a single annotation of your own still inherited all of them, and they were written onto the Ingress whatever ingressClassName you configured. On Contour, Traefik, or any other controller they are dead configuration, and removing them meant setting each key to null.
Starting with Camunda 8.10 (chart 15.x), those annotations come from a compatibility shim controlled by global.compatibility.nginx.renderAnnotations, which defaults to true. Nothing changes on upgrade: the same annotations render, so Ingress-nginx deployments are unaffected. The shim is removed in the next major, after which the annotations are opt-in.
Action: If you run an Ingress controller other than Ingress-nginx, set global.compatibility.nginx.renderAnnotations: false and configure whatever your controller needs through global.ingress.annotations and orchestration.ingress.grpc.annotations. Keys you set there always win over the shim.
That removes the shim's annotations only. The chart still adds nginx.ingress.kubernetes.io/backend-protocol to the dedicated Ingress objects it renders when an upstream TLS mode is enabled through global.tls.orchestration, global.tls.connectors, or global.tls.optimize, and only Ingress-nginx reads that annotation.
global:
compatibility:
nginx:
renderAnnotations: false
ingress:
annotations:
# for example, with Contour
kubernetes.io/tls-acme: "true"
If you stay on Ingress-nginx, no action is required before the next major. When the shim is removed you will need to set the annotations yourself:
global:
ingress:
annotations:
nginx.ingress.kubernetes.io/ssl-redirect: "false"
nginx.ingress.kubernetes.io/proxy-buffering: "on"
nginx.ingress.kubernetes.io/proxy-buffer-size: "128k"
# keep in sync with global.config.requestBodySize
nginx.ingress.kubernetes.io/proxy-body-size: "10m"
orchestration:
ingress:
grpc:
annotations:
nginx.ingress.kubernetes.io/ssl-redirect: "false"
nginx.ingress.kubernetes.io/backend-protocol: "GRPC"
nginx.ingress.kubernetes.io/proxy-buffer-size: "128k"
The gRPC Ingress reads orchestration.ingress.grpc.annotations only; it inherits nothing from global.ingress.annotations, so set all three keys there.
Two of those carry behavior rather than cosmetics: nginx.ingress.kubernetes.io/backend-protocol: "GRPC" is what makes Ingress-nginx proxy Zeebe gRPC at all, and nginx.ingress.kubernetes.io/proxy-buffer-size is the documented fix for gateway timeouts caused by large JWT Set-Cookie headers.
With Contour, the gRPC upstream is declared on the Orchestration Cluster Service, not on the Ingress, so set it through orchestration.service.annotations and not orchestration.ingress.grpc.annotations. The annotation value lists the gRPC port, and the key depends on whether that upstream uses TLS:
| gRPC upstream | Contour annotation | Envoy behavior |
|---|---|---|
| Plaintext, the chart default | projectcontour.io/upstream-protocol.h2c | Cleartext HTTP/2 |
TLS, with global.tls.orchestration.grpc.enabled: true | projectcontour.io/upstream-protocol.h2 | HTTP/2 over TLS |
orchestration:
service:
annotations:
# plaintext upstream; use upstream-protocol.h2 if the gRPC upstream has TLS
projectcontour.io/upstream-protocol.h2c: "26500"
Contour reads h2c as cleartext HTTP/2, so leaving it on a TLS-enabled upstream breaks gRPC routing. The chart draws the same distinction on Ingress-nginx, where it swaps nginx.ingress.kubernetes.io/backend-protocol from GRPC to GRPCS for a TLS-enabled gRPC upstream.
The chart emits a deprecation warning naming the flag and the removal only when the shim actually injects an annotation: the flag is on, the Ingress it applies to renders, and you have not set that key yourself. Setting every shim key silences the warning even with the flag still on.
Classic Grafana dashboard format deprecated
The Grafana dashboards published in monitor/grafana of the camunda/camunda repository use the classic Grafana dashboard JSON model. Starting with Camunda 8.11, Camunda will update the dashboards to the new v2 dashboard schema.
Camunda 8.10 is the last release that provides the dashboards in the classic format. The classic dashboards of 8.10 and earlier releases continue to work with your Grafana instance.
Action: To keep using the dashboards in the classic format, import them from the stable/8.10 branch or from the branch of the release you run. Before you move to the dashboards of 8.11, check that your Grafana version supports the v2 dashboard schema.
Application configuration Helm keys deprecated
Starting with Camunda 8.10, Helm chart values that only proxy a single application property are deprecated in favor of the component's extraConfiguration. The chart keeps the Kubernetes settings it is responsible for, such as resources, scheduling, endpoints, and secrets, and stops mirroring the application's own configuration.
The deprecated keys continue to work in 8.10. When you set one to a non-default value, helm install and helm upgrade log a [camunda][warning] DEPRECATION message that names the key and where to configure it instead.
Action: Move the deprecated keys in your values.yaml to the component's extraConfiguration. If you set both, the extraConfiguration value takes precedence. Use the deprecation messages from your own upgrade as the up-to-date list of keys for your chart version.
Helm CLI v3 and v4 supported for Camunda 8.10
Camunda 8.10 (chart 15.x) supports Helm CLI v3 (3.10 or later) and v4.
Camunda recommends Helm CLI v4 and supports it for the full release cycles of Camunda 8.9 and 8.10. Camunda supports Helm CLI v3 (3.10 or later) until February 10, 2027, when upstream support ends. After February 10, 2027, Camunda no longer supports Helm CLI v3. Customers who continue to use Helm CLI v3 after that date do so at their own risk.
With Helm v3, the chart shows a warning in the notes that helm install and helm upgrade print, and in a ConfigMap whose name ends in -warnings. The warning does not block the install or upgrade.
Action: Use Helm CLI v4 for new installations. Switch existing deployments before Helm CLI v3 support ends. Switching CLIs does not require a release-state migration. Helm runs on the client, and both CLIs read and write the same release-storage format. See Move from the Helm v3 CLI to v4 and Helm CLI v4.
Camunda Hub database migration phases
The 8.9 to 8.10 Camunda Hub database migration is controlled by camundaHub.upgrade.phase. Use quiesce to stop all Hub workloads so you can take a verified database backup, migrate to run the startup schema migration on a single pod without serving traffic, and normal to restore serving capacity. Fresh installs stay on normal.
Action: Run the phases in order as part of your 8.9 to 8.10 upgrade, and plan a maintenance window: Hub serves no traffic in quiesce or migrate. The migration isn't backward compatible, so take a verified database backup first. See migrate Camunda Hub.
Deployment topology release roles
Camunda 8.10 adds global.topology.mode to the Helm chart, so a release declares its role in the wider deployment: combined, hub, orchestration, or optimize. One hub release running Camunda Hub and Management Identity can serve many independently deployed orchestration releases, and an optimize release deploys Optimize alone, so each Physical Tenant gets its own Optimize instance.
combined remains the default and preserves existing single-release behavior, so no existing deployment changes on upgrade. For a new production deployment, the split topology is the baseline.
hub and optimize are 8.10-only roles, because Camunda Hub and its cluster inventory don't exist in the earlier charts. The orchestration role is also available in the 8.9, 8.8, and 8.7 charts from versions 14.11.0, 13.14.0, and 12.14.0, so one 8.10 Hub can manage clusters on older chart versions. Earlier versions of those charts ignore global.topology.mode and deploy a combined release. The 8.10 roles require chart 15.0.0 or later.
Action: None required for an existing deployment. For a new production deployment, see deployment topology and install the deployment topology. To move an existing combined release, see move from a combined release to the split topology.
Identity
Legacy Optimize authentication properties deprecated
The authentication properties Optimize used through 8.9 are deprecated in favor of camunda.security.*. Optimize still accepts them in 8.10 and translates the recognized properties to their new equivalents at startup, but they will be removed in a future release.
Action: Migrate Optimize to the camunda.security.* settings ahead of that removal.
Console and Web Modeler Admin roles gain new Hub cluster access on Self-Managed
Starting with Camunda 8.10, Camunda Hub replaces Console and Web Modeler. Management Identity only adds roles, applications, and permissions on startup and never removes them, so two existing Self-Managed roles automatically gain access they didn't have in 8.9 — with no role reassignment or opt-in required:
- Existing
Consolerole holders gain management access to Hub's cluster pages through a newadmin:clusterspermission.DevOpsis the new name for the same access. - Existing
Web Modeler Adminrole holders gain full access to Hub's cluster pages too, through their existingadmin:*permission, which now additionally reaches Hub's cluster pages — a broader grant than the Console role's management-only access.Hub Adminis the new name for the same access.
A new Analyst role is also introduced: Hub modeling access, management access to the catalog's usage and adoption data, and full access to Optimize, without modeler-admin or people/org management access — the Self-Managed equivalent of the SaaS Analyst role.
Action: If you rely on least-privilege access to cluster management, review who holds the Console and Web Modeler Admin / Hub Admin roles before upgrading.
Management Identity roles and permissions in the 8.9 to 8.10 upgrade guide
SaaS organization roles renamed and Catalog access levels introduced
Starting with Camunda 8.10, SaaS organization roles are renamed to align with Camunda Hub, and Catalog access is split into two levels. These are display renames and a new access split; existing role holders keep the same effective access, with no reassignment required:
Owner→Organization OwnerAdmin→Organization AdminModeler→Member(Member additionally gains organization and cluster read access)AnalyststaysAnalyst.Operations Engineer→DevOps, with no permission change.- Catalog access is now split into Read (Member, DevOps) and Manage (Analyst, Organization Admin, Organization Owner, who additionally see usage statistics and adoption data).
Developer, Support agent, Task user, and Visitor are unaffected by this rename; see manage users and roles for their status.
Unified authentication for the Orchestration Cluster and Optimize
Optimize can now be configured with the same camunda.security.authentication.* settings already used by the Orchestration Cluster. Nothing changes for the Orchestration Cluster, which already used these settings in 8.9.
Optimize accepts its 8.9 authentication settings in 8.10 and translates the recognized properties to their new equivalents at startup, but those 8.9 properties are deprecated and will be removed in a future release. User, group, role, tenant, and permission management for Optimize is unchanged and is still handled by Management Identity.
Action: Migrate Optimize to the camunda.security.* settings ahead of that removal.
Optimize component-specific configuration keys
Orchestration Cluster warns about an incorrect OIDC configuration at startup
The Orchestration Cluster checks its OIDC configuration at startup and writes a warning for each problem it finds. The cluster still starts.
- The checks cover the client ID, the set of endpoints, the scope, and the shape of the redirect URI.
- A redirect URI with no callback path, or with a path that has no leading slash, falls back to
{baseUrl}/sso-callback. - Any other unusable value stays as configured, and the login fails later.
Action: Review your startup logs after the upgrade. The warnings come from the loggers io.camunda.security.spring.oidc.ScopedClientRegistrationFactory and io.camunda.security.spring.oidc.OidcRedirectionEndpoint.
Orchestration Cluster starts when an identity provider is unreachable
The Orchestration Cluster contacts an OIDC provider at the first request that needs it, and not at startup. A provider that is down no longer stops the cluster from starting.
- Only the requests that need that provider fail, such as browser login requests and token-validation requests. All other requests succeed, and a failed request recovers when the provider answers, without a restart.
- A failed request writes a warning, at most once each minute for each combination of failed step and provider.
Action: If you used a failed startup to detect an unreachable identity provider, alert on the DeferredOidcResolution warning instead. This covers a provider that the cluster resolves through its issuer URI. A provider with a static jwk-set-uri or user-info-uri gives a different signal, or none, so read the debugging guide before you rely on this alert.
Integrations
SAP BTP Plugin retired
The SAP BTP Plugin is retired as of Camunda 8.10. There are no changes to the other modules of the SAP integration.
Modeler
Changes for 8.10 will be added here as the 8.10 documentation is updated.
Deployments target environments instead of clusters
Starting with Camunda 8.10, teams deploy to environments instead of the clusters connected to a project. An environment is a named deployment target where a team runs its processes, and it's hosted on a cluster. Clusters remain the infrastructure your administrators manage.
- Projects no longer have their own deployment stages or connected clusters. A project can deploy to every environment assigned to its workspace.
- Organization admins assign environments to workspaces.
- In Self-Managed, Camunda Hub creates environments from the clusters in your
camunda.hub.clustersconfiguration, and from any Physical Tenants you declare.
Action: After you upgrade, assign environments to the workspaces you create. Optionally, tag a cluster with prod if you want Camunda Hub to treat its environments as production environments for the project deployment policy.
Environments in the 8.9 to 8.10 upgrade guide
Optimize
Client bearer tokens are now classified for permission checks
Optimize classifies each bearer token as belonging to a user or a machine-to-machine (M2M) client, using camunda.security.authentication.oidc.username-claim and client-id-claim, and enforces your configured Optimize permission only on tokens it classifies as a user's. A token Optimize can't classify is treated as belonging to a user, and checked against your configured Optimize permission.
Action: Set username-claim and client-id-claim to match your identity provider's token shape before upgrading. If you've already configured these claims for the Orchestration Cluster, use the same values for Optimize. Otherwise, M2M clients without an Optimize permission may see new permission errors after upgrading.
Optimize static API access token is no longer supported
In Camunda 8.10, Self-Managed Optimize accepts only OIDC bearer tokens on its API. A request that carries the static token from api.accessToken (environment variable OPTIMIZE_API_ACCESS_TOKEN) gets a 401 response. This applies to the Optimize API and to the external variable ingestion endpoint. The Camunda Helm chart and SaaS do not set this token. They configure OIDC for the Optimize API. You are affected only if you set the property or the environment variable yourself, for example as a property override or an extra environment variable in your Helm values.
Action: Change the API clients that send the static token to OIDC bearer tokens before you upgrade to 8.10. Then remove api.accessToken from your configuration. If you need more time, set optimize.security.csl.enabled=false. This opts into the 8.9 component-specific configuration fallback, and the static token works again. Camunda plans to remove this fallback and the component-specific configuration keys in a future release.
Component-specific Optimize security configuration keys deprecated
The Optimize login and API security keys used through 8.9 are deprecated in favor of camunda.security.*. Optimize maps recognized component-specific keys automatically and logs a deprecation warning naming the replacement. Camunda plans to remove these keys in a future release.
Keep CAMUNDA_OPTIMIZE_IDENTITY_BASE_URL set. It is not deprecated, and Optimize still uses it to look up users, for example when adding users to a collection.
Action: Migrate to the camunda.security.* keys as soon as you can. See component-specific configuration keys for the full mapping and the precedence rules.
optimize.security.csl.enabled=false fallback is temporary
optimize.security.csl.enabled=false temporarily restores the 8.9 component-specific configuration. Use it only if your integrations depend on the static API access token that the 8.9 configuration accepted, or if your migration to the camunda.security.* keys was misconfigured and you need a working deployment while you fix it. Camunda plans to remove this fallback, the 8.9 behavior it restores, and the component-specific configuration keys in a future release.
Action: Treat this as a temporary escape hatch, not a supported long-term mode. Falling back doesn't pause the migration, it only delays it, so the same camunda.security.* migration is still required.
Tasklist
Tasklist custom styling uses Camunda design system tokens
Starting with Camunda 8.10, the Tasklist UI uses the Camunda design system instead of the Carbon Design System. Custom styles in custom.css that override Carbon --cds-* tokens or use :root[data-carbon-theme='g10'] and :root[data-carbon-theme='g100'] selectors no longer have any effect. Tasklist falls back to its default styling without showing an error.
The custom.css file location has also changed. In the Docker image, place the file at /usr/local/camunda/config/custom.css instead of /usr/local/tasklist/config/custom.css. In the distribution archive, place it in the config directory. Camunda now serves the file at <context-path>/custom.css instead of /tasklist/custom.css.
Action: When you upgrade to 8.10, rewrite your custom styles to override the Camunda design system tokens using the html .c4-ui (light theme) and html .c4-ui.dark (dark theme) selectors, and move custom.css to the new location.