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 no longer supported
Camunda 8.10 drops support for Amazon Aurora PostgreSQL 14. Supported versions are now 15, 16, and 17.
- 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.
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.
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
- The Tasklist API and Tasklist V1 mode
- Tasklist V1-dependent features such as user task access restrictions 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.
Connectors
Changes for 8.10 will be added here as the 8.10 documentation is updated.
Data
Changes for 8.10 will be added here as the 8.10 documentation is updated.
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.
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.