At CamundaCon Amsterdam 2025, Christopher Kujawa and Nicolas Perreault from Camunda talked about the challenges of running Camunda’s distributed setup. They explained how data constantly moved between Zeebe, Operate, and Tasklist, which created complexity and load at scale. Anyone who has managed Camunda in production could relate. They also hinted at a new approach to solve these problems, and hinted at Camunda’s plans to re-architecture the whole core of the platform.1
That session introduced what would later become part of the foundation for Camunda 8.8 and its unified architecture. This release is more than a technical improvement. It changes how the platform is designed and operated, bringing consistency and simplicity to daily process operations.
How the Old Setup Worked
Before version 8.8, Camunda used a distributed architecture. Each main service, including Zeebe, Operate, Tasklist, and Identity, ran independently.
In local setups, you could start everything with Docker Compose, each service provided as its own image. It was fine for quick testing but already showed how many moving parts were involved. In production, teams often used Kubernetes with Helm charts, deploying, configuring, and scaling each component separately.
Zeebe acted as the process engine and event source. It stored workflow execution data in log files that recorded every step of a process. But Operate and Tasklist did not read those logs directly. Instead, Zeebe sent data outward through exporters, mainly to Elasticsearch. Operate, Optimize, and Tasklist then pulled and indexed that data again to build their own views and search features.
Each component kept its own copy of workflow data. Operate indexed workflow instances and incidents, Tasklist focused on tasks and assignments, and Optimize handled analytics. This constant exporting and re-indexing created a lot of data movement between independent services. When something broke in that chain, it could take time to trace the issue since several exporters and indices were involved.
The system was modular and flexible, but also complex. Every component had its own configuration, scaling strategy, and API. In total, more than ten services had to run and interact for the full platform to work. Under heavy load or during upgrades, this distributed setup often introduced latency and bottlenecks.
These challenges, especially the redundant data pipelines, were a major reason for the redesign in Camunda 8.8. The new Orchestration Cluster replaced all external exporting and indexing with an internal data flow. The unified exporter now keeps data consistent across Zeebe, Operate, and Tasklist, while still sending it to Elasticsearch in a single, cleaner path for search and analytics.
What Changed in Camunda 8.8
Camunda 8.8 brings a much simpler and more unified architecture. Zeebe, Operate, Tasklist, and Identity now run together as a single runtime called the Orchestration Cluster. It has one configuration, one lifecycle, and one shared data model, so there’s no need for multiple exporters or duplicate indexing.
Inside the cluster, a new internal exporter handles data flow between components. Operate and Tasklist both read from the same internal source, which makes the system faster, more consistent, and easier to scale under load.
From Camunda’s own update on the new “unified exporter,” Elasticsearch is still part of the picture, but the integration is cleaner and more focused. Instead of each component pushing data out through separate exporters, one streamlined exporter handles all data movement to Elasticsearch (or OpenSearch). This reduces complexity, avoids race conditions, and improves consistency between the internal state and what’s indexed for search and analytics.
Identity has been completely rebuilt too. The old dependency on Keycloak is gone, replaced by a native identity servicethat manages users, groups, and permissions directly inside the cluster. Access is scoped per cluster, which improves security and cuts down on configuration effort.
There’s also a Management Identity service outside the cluster. It controls access for external tools such as Optimize and the Web Modeler. This keeps runtime security local to the cluster while centralizing admin control elsewhere.
Another big improvement is the unified REST API. Earlier versions had separate APIs for each component, forcing developers to juggle multiple endpoints. Now, a single orchestration API covers everything: workflow management, task completion, and more. The new Java Client and Spring Boot Starter are built on top of it.
Overall, Camunda 8.8 turns what used to be a collection of standalone services into one cohesive orchestration platform. With fewer moving parts, no Keycloak dependency, and internal data flow replacing external exports, the system is faster, simpler, and more reliable while still keeping Elasticsearch as a lean, well-integrated part of the stack.
What It Means for Operations
For operators, the impact is clear. Running Camunda no longer means managing several independent systems. There is one cluster to deploy, one configuration to maintain, and one runtime to monitor. Upgrades are simpler, scaling is predictable, and data stays consistent.
Operate and Tasklist now show the same view of the engine state. Because they rely on the same internal data, monitoring is more accurate. Logs, metrics, and alerts align across components, which gives a complete picture of the platform at any moment.
The unified API also makes automation easier. All operational actions such as starting workflows, managing tasks, or resolving incidents can be done through one interface. This allows better integration with CI pipelines and operational tools.
In daily use, the new setup removes a lot of complexity. There are fewer configurations to maintain and fewer points of failure to track. The unified cluster behaves as one consistent system that supports stable and transparent process operations.
Final Thoughts
This release is an important step for Camunda. The platform has evolved from a group of services into a unified orchestration engine that is easier to run and maintain. The goal is not to add more features but to make the core platform stronger and simpler.
The unified cluster and API make both development and operations easier to understand and manage. They bring clarity, stability, and a solid foundation for the future. The new identity design also fits well into enterprise environments where local runtime access and centralized control must stay separate.
Camunda continues to grow into a complete orchestration platform. It explores AI and automation, but it also focuses on a reliable foundation. For anyone who values stability and observability, Camunda 8.8 is a significant step forward.
Camunda 8.8 is not about doing more. It is about doing things better. That is what makes it such an important release.
https://camunda.com/blog/2025/02/one-exporter-to-rule-them-all-exploring-camunda-exporter