8.10 Release announcements
Supported environment changes, breaking changes, and deprecations in Camunda 8.10.
| Minor release date | Scheduled end of 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.
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.
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.
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.
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.
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.
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.
Elasticsearch 9.2 no longer supported
Camunda 8.10 raises the minimum supported Elasticsearch 9.x version to 9.3. Supported Elasticsearch versions are now 8.19+ and 9.3+.
- Upgrade Elasticsearch 9.2 clusters to 9.3 or later before moving to Camunda 8.10.
OpenSearch 3.4 no longer supported
Camunda 8.10 raises the minimum supported OpenSearch 3.x version to 3.5. Supported OpenSearch versions are now 2.19+ and 3.5+.
- Upgrade OpenSearch 3.4 clusters to 3.5 or later before moving to Camunda 8.10.
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.
APIs & tools
Changes for 8.10 will be added here as the 8.10 documentation is updated.
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
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.
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
Changes for 8.10 will be added here as the 8.10 documentation is updated.
Data
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.
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.
Deployment
Helm v4 required for Camunda 8.10
Camunda 8.10 (chart 15.x) supports the Helm CLI v4 only. Camunda 8.9 (chart 14.x) is the last minor that supports the Helm v3 CLI. The Helm chart adds a CLI version check and fails fast if Helm v3 is used to install or upgrade chart 15.x.
Action: Install the Helm v4 CLI before you upgrade to 8.10. No release-state migration is required; Helm is client-side only and both CLIs read and write the same release-storage format. See Move from the Helm v3 CLI to v4 and Helm 4.
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 updating to Camunda 8.9.12 or later, switch to the unified camunda/camunda Docker image.
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.
Identity
Changes for 8.10 will be added here as the 8.10 documentation is updated.
Modeler
Changes for 8.10 will be added here as the 8.10 documentation is updated.