Release announcements
Supported environment changes and breaking changes or deprecations for the Camunda 8.8 release are summarized below.
Release notes now contain all updates for new features and enhancements.
| Scheduled release date | Scheduled end of maintenance | Release notes | Blog |
|---|---|---|---|
| 14 October 2025 | 13 April 2027 | - | - |
Changes in supported environments
Zeebe, Operate, Tasklist, and Identity must run on exact same minor and patch levels
From version 8.8.0 forward, the following core Orchestration cluster components must run on the exact same minorand patch level to ensure compatibility: Zeebe, Operate, Tasklist, and Identity. See the component version matrix or the Self-Managed reference architecture for an overview of components.
Installation and deployment updates Self-Managed
Camunda 8.8 introduces a streamlined architecture, consolidating core components such as Zeebe, Operate, Tasklist, Optimize, and Connectors into a single deployable unit. Enhanced deployment options are also included, such as new Kubernetes Helm guides, deployment reference architectures, and improved support for local development with Camunda 8 Run.
You can download the alpha release of the unified package from the Camunda GitHub repository, either as an executable Java application (Camunda Orchestration Core) or a Docker image.
Identity and authentication limitations in 8.8.0-alpha2
The 13.0.0-alpha2 Helm chart released with Camunda 8.8.0-alpha2 establishes a new default setup to support 8.8 Identity management updates. Currently, this setup is limited to the following components:
- The Orchestration core (Zeebe, Operate, Tasklist, and Orchestration cluster Identity)
- Connectors
This temporary limitation will be resolved in subsequent alpha releases.
Helm charts
If you are using the recommended Camunda 8 deployment option (Helm charts), the upgrade path from version 8.7 to 8.8 will be straightforward by changing the values file to the new syntax.
New migration guides will also be provided to support you when migrating from a previous Camunda version.
Additional upgrade considerations are necessary for deployments that use custom scripts, such as Docker containers, manual installations, or custom-developed Kubernetes deployments. For these deployments, customers can either continue to deploy with their original 8.7 topology and upgrade each component independently, or adopt our Helm chart approach for the upgrade, which allows for unifying the deployment into a single JAR or container executable.
Versioning changes in Elasticsearch
As of the 8.8 release, Camunda is compatible with Elasticsearch 8.16+ and no longer supports older Elasticsearch versions. See supported environments.
Key changes
API updates SaaSSelf-Managed
The 8.8 release includes API updates to support the move to a Camunda 8 REST API unified experience. See more details in the release notes.
Deprecated: Operate and Tasklist v1 REST APIs
The deprecation process for the Operate and Tasklist REST APIs starts with the 8.8 release. You can begin migrating to the Camunda 8 REST API for querying to prepare for this change.
- Version 8.9: These APIs are still available but deprecated, and so not recommended for new implementations.
- Version 8.10: These APIs will be removed.
Deprecated: Job-based user tasks querying
With the 8.8 release, the deprecation process for job-based user tasks starts. As job-based user tasks will not be supported for querying and task management with Camunda 8.10, Camunda recommends using Camunda user task type (formerly known as Zeebe user task) in your process definitions. Note that you may still see references to Zeebe user task in your XML, but this is the same thing as Camunda user task.
- Version 8.9: Job-based user tasks are available for querying, but Camunda Modeler automatically applies the Camunda user task and shows a warning message for each job-based user task.
- Version 8.10: With the removal of the Tasklist REST API, job-based user tasks will no longer be supported for querying and task management. With Camunda 8.9+, customers can still use the job-based user tasks as standard jobs with headers to enable open architecture and composable solutions. For customers who require task lifecycle support and task querying, we recommend using the Camunda User Task type.
Deprecated: Zeebe gRPC API endpoints
With the 8.8 release, Camunda announces the deprecation of several Zeebe gRPC endpoints for removal in 8.9.
- Key gRPC endpoints necessary for high-throughput and low-latency applications will remain available in the product to ensure peak performance for specific use cases
- The final list of retained gRPC endpoints will be confirmed with the 8.8 release.
- Selected endpoints will remain active, with others scheduled for removal in the 8.10 release.
Removed: Tasklist GraphQL API
With the 8.8 release, the deprecated Tasklist GraphQL API will be removed from the product.
Removed: Deprecated OpenAPI objects
With the Camunda 8.8 release, deprecated API objects containing number keys have been removed, including the
corresponding application/vnd.camunda.api.keys.number+json content type header.
In previous releases, entity keys were transitioned from integer (int64) to string types, and deprecated
integer (int64) keys were still supported. As of the 8.8 release, support for integer (int64) keys has been removed.
To update to Camunda 8.8, API objects using integer (int64) keys must be updated to use string keys and the
application/json header.
For more information about the key attribute type change, see the 8.7 API key attributes overview.
Camunda Exporter Self-Managed
Camunda web applications used importers and archivers to consume, aggregate, and archive historical data provided by the Elasticsearch (ES) or OpenSearch (OS) exporters.
With the Camunda 8.8 release, a new Camunda Exporter is introduced. That brings the importing and archiving logic of web components (Tasklist and Operate) closer to the distributed platform (Zeebe). This simplifies the installation, enables scalability for the web applications, reduces latency when showing runtime and historical data, and reduces data duplication (resource consumption).
The new Camunda Exporter helps us achieve a more streamlined architecture, better performance, and improved stability (especially concerning ES/OS). For more details about this project, see the related blog post.
Harmonized index schema
The existing data schema in the secondary storage has been harmonized, to be used by all Camunda components.
- This removes unnecessary duplications over multiple indices due to the previous architecture.
- With this change, several Operate indices can and will be used by Tasklist.
- New indices have been created to integrate Identity into the system.
Camunda Java client and Camunda Spring SDK
With the Camunda 8.8 release, Camunda Java Client and Camunda Spring SDK replace the Zeebe Java client and Spring Zeebe SDK. This allows you to use a single consolidated client to interact with Camunda orchestration clusters.
The CamundaClient replaces the ZeebeClient, offering the same functionality and adding new capabilities.
- If you need to continue using the old
ZeebeClient, you can use the new version 8.8CamundaClientartifact without issues as it still contains the relatedZeebeClientclasses. Those classes are marked as deprecated, so you can easily spot code you need to adjust to theCamundaClient. - The old
zeebe-client-javaartifact is now relocation-only, so your build system is redirected to the newcamunda-client-javaartifact. We will discontinue the old artifact with a future release and recommend using the new one. - The Zeebe Java client will not be developed further and only receives bug fixes while version 8.7 is officially supported.
Adjustments
| Change | Description |
|---|---|
| New package structure | Package io.camunda.client: Contains the new CamundaClient and all 8.7 features. |
| Refactored properties and environment variables |
|
| Artifact ID change | The artifactId changes from zeebe-client-java to camunda-client-java. |