Camunda 8.8 standardizes how you deploy, operate, and use the platform to build and deliver process automation processes. The new Orchestration Cluster (previously automation cluster) provides an improved product experience around deployment, configuration, scaling, and APIs. This blog post focuses on the architectural and component changes that software developers and enterprise architects need to be aware of when using the Orchestration Cluster.
The release of Camunda 8.8 marks the reframing of Camunda’s orchestration as a platform experience using one deployable artifact. This release standardizes how the platform is operated and used across components, reducing version confusion and enhancing human and agent task execution in the same process. The payoff is faster delivery, fewer “what version is that?” surprises, and a stronger base for enterprise agentic orchestration and automation.
What is the orchestration layer?
Before we take a deeper look at what is different in Camunda’s orchestration layer with 8.8, it is important to understand what we mean when we discuss the “orchestration layer.” Think of the orchestration layers as the bundle of capabilities that coordinate the execution of your business processes, both BPMN and DMN. So, this includes the Zeebe workflow engine, task routing, state management, APIs, connectors, human tasks, and monitoring.
In prior Camunda 8 releases, we offered individual components for the engine, Zeebe, user-task frontend of Tasklist, monitoring with Operate, and Identity/Authorization services. With Camunda 8.8, we have combined all these components into the new Orchestration Cluster concept.
The Orchestration Cluster is the core component of Camunda 8, powering the automation and orchestration of business processes. As mentioned, the cluster includes:
- Zeebe as the workflow engine.
- Operate for monitoring and troubleshooting process instances running in Zeebe.
- Tasklist for interacting with user tasks (assigning, completing, etc.).
- Identity for managing integrated authentication and authorization.
- APIs for interacting with the Orchestration Cluster programmatically.
This unified approach is about your platform experience for orchestration including deployment, configuration, scaling, and APIs, and not just the modeling and execution engine. It’s not just the engine under the hood, it’s the daily touchpoint for your teams.
The key to this new Orchestration Cluster is consolidation. With a single Orchestration Cluster, version alignment between the previous independent components stops being a project of its own and becomes a property of the overall platform.
- The new Orchestration Cluster REST API is a single API for the cluster simplifying your job workers, user-task handling, and more.
- You can take advantage of one configuration file with all the properties you need so you can configure security, logging, monitoring, retention, and component behavior in a single location.
- With the new Orchestration Cluster, Zeebe uses an exporterless architecture, directly streaming data to Operate. This reduces setup complexity, improves reliability, and helps prevent common data sync issues.
The direction is consistency—one cluster, one API, one client.
Key changes in the orchestration layer
Here is a bit more detail on the major shifts you’ll want to understand as they relate to the consolidated architecture with Camunda 8.8.
Consolidation
Camunda 8.8 turns the Orchestration Cluster from a collection of individual parts into a cohesive product experience. The new Orchestration Cluster now becomes your deployment core bundling Zeebe, Operate, Tasklist, and the orchestration-facing Identity into a single artifact.
Now, instead of juggling multiple deployable components, you run as one unit. With this consolidated topology you have fewer points of failure, and upgrades will feel like a single move. Fewer moving parts also mean cleaner version alignment across components.
Unified API for orchestration interactions
We have standardized on a single orchestration cluster REST API (with gRPC where appropriate) for both SaaS and Self Managed deployments. Everything communicates using one consistent interface to your Camunda cluster, providing significant benefits to developers and architects alike:
- Minimizes code required to connect to different parts of the system.
- No need to manage different endpoints for process execution, user tasks, and monitoring.
Be sure to check out this blog post or our recent CamundaCon session discussing this unified API to get more details.
Unified configuration
With Camunda 8.8’s unified configuration model you define security, logging, monitoring, retention, and component behavior in a single central configuration rather than in multiple component-specific files.
Although several legacy configuration properties have been replaced, or flagged for depreciation, with new properties for the new unified orchestration cluster, the payoff is tighter governance and fewer different config files to manage and hunt down.
Identity and access management restructuring
The new Orchestration Cluster embeds Identity for Zeebe, Operate, Tasklist, and API authorization and authentication, while Management Identity continues to serve Web Modeler, Console, and Optimize. The new embedded Identity is now the source of truth for orchestration components, eliminating earlier dependencies on the separate Management Identity for core components.
Essentially, Identity manages the permissions for Zeebe, Operate, Tasklist and Identity and the tenants for Zeebe, Operate, Tasklist (for self-managed, this is tenants only). Also in self-managed deployments, Console runs in the Management cluster/namespace and works as an umbrella over multiple Camunda clusters.
Management Identity manages permissions and tenants for Optimize and Web Modeler for self-managed installations. In SaaS, roles provide access to Optimize and Web Modeler and are managed in the Organization in Console.
For a deeper dive on the changes to Identity with Camunda 8.8, please check out Introducing Enhanced Identity Management in Camunda 8.8 in our Camunda blog.
Deployment and packaging improvements (self-managed)
Camunda has made improvements in both packaging and deployment for self-managed installations. Now, self-managed deployments run a single distribution and the legacy Zeebe, Operate, Tasklist images are deprecated. The Helm charts have been updated for ingress, secrets, and multi‑region guidance. The net effect of these improvements is fewer discrete services to manage.
Exporter and data flow improvements
The new unified Camunda exporter improves performance with accelerated data visibility in Operate and Tasklist as well as public query APIs. With the new Orchestration Cluster, Zeebe uses an exporterless architecture, directly streaming data to Operate reducing complexity, improving reliability, and helping prevent common data synchronization issues for customers.
This means that observability and analytics are part of the Orchestration Cluster improvements providing more timely insight into your running processes. For more information about the exporter, please be sure to read our recent blog One Exporter to Rule Them All: Exploring Camunda Exporter and review our talk from CamundaCon 2025.
Architect’s viewpoint
If you had previously isolated your components on separate nodes, you can revisit your configuration for a simpler approach. For example, you may want to scale Zeebe horizontally and tune partition count to your workload volumes. You can keep brokers, gateways, and job workers isolated from analytics (Operate, Optimize) and optimize your overall performance.
The simpler packaging also simplifies your disaster recovery approach. You can design active-passive or active-active based on your compliance requirements. You can also manage all configuration as code with GitOps and the split between embedded (engine and workers) and management identity (admin and observability) ensures least privilege remains cleanly enforced and easy to maintain.
By unifying the stack, you can reduce coordination costs and speed up delivery.
Benefits of these orchestration layer changes
As discussed, the unified architecture introduces streamlined identity and access management, a consolidated configuration model, and modernized and consolidated APIs and SDKs, making development, integration, and permission handling faster and more intuitive.
Some key benefits include:
- The new simplified topology provides fewer moving parts, less deployment complexity and faster onboarding.
- With a unified API, you have less fragmented code and can offer a better developer experience.
- You now have a single configuration file, a unified deployment artifact, and a clearer identity model which enhances the manageability of your Camunda deployment.
- You gain improved observability with faster data flow, built-in exporter, and unified monitoring pipeline.
- These changes are building the foundation layer and positioning you for the future. For example, you can take advantage of agentic orchestration (AI agents, mixed human-agent processes) and cloud-scale scenarios.
Summing it up
The Orchestration Cluster in Camunda 8.8 represents a significant evolution from discrete components and fragmented APIs to a unified, streamlined platform with consolidated configuration, identity, APIs, and data flows. For organizations embracing agentic orchestration or high-scale process automation, this shift is foundational. While migration requires planning, the payoff is a simpler, stronger orchestration platform.
Learn more
Learn more about the latest Camunda 8.8 release, and check out these blog posts to dig deeper:
- Streamlined Deployment with Camunda 8.8
- One Exporter to Rule Them All: Exploring Camunda Exporter [blog] and related CamundaCon talk
- Introducing Enhanced Identity Management in Camunda 8.8
- Introducing Camunda Process Test—The Next Generation Testing Library
- Upcoming API Changes in Camunda 8: A Unified and Streamlined Experience
Start the discussion at forum.camunda.io