Camunda 8 vs Operaton

Camunda 8 is a remote process orchestration platform, not an embedded library. Its engine is Zeebe, which runs as a cluster that your applications reach through clients and job workers, with Operate for monitoring instances and Tasklist for human tasks alongside it. Camunda offers it as SaaS or as Self-Managed on Kubernetes. The licensing changed at version 8.6: from that release, the source code of Zeebe, Operate, Tasklist, Identity and Optimize is under the Camunda License v1, and compiled software is under proprietary terms. Production use of Camunda 8 Self-Managed requires buying the Self-Managed Enterprise Edition, while the Camunda Self-Managed Non-Production license covers development and testing only. Confirm the exact terms in the licensing documentation with Camunda before you commit, because the answer decides whether the cost of a Camunda 8 move is a subscription or a free download.

Operaton is an Apache-2.0 BPMN 2.0 engine that starts from the Camunda 7 codebase. It was created as a fork of Camunda 7 Community Edition after that edition reached end of life in October 2025, and its package namespace changed from org.camunda to org.operaton. The project keeps a fully compatible REST API, database schema and deployable BPMN and DMN models. Operaton 2.1 is feature complete and API-compatible with Camunda 7 CE 7.24, keeps database schema version 7.24 and requires Java 17. For a Camunda 7 team, this means the engine still runs embedded in your Java application, so the main change to plan is the namespace and dependency update rather than a new runtime. Check your custom code and database drivers against the 2.1 release notes before you assume a drop-in upgrade.

Operaton ships on a predictable calendar, but it does not give you a long-term support line. According to the Operaton FAQ, feature releases arrive twice a year, in April and October, with monthly patch releases in between. Each major or minor version is supported for six months, until the next one ships, and there is no traditional LTS line. The 2.1 line was published on April 24, 2026, and its latest stable patch, v2.1.5, on September 18, 2026. For a Camunda 7 team that today runs on a fixed patch level for years, this is the largest operational change. Your staff must plan a regular upgrade cycle, budget test time for each feature release, and be ready to move to a newer minor version within six months of its release.

Governance is the second gap. The Operaton FAQ says the project is maintained by an open-source community with no single company in control, that governance is still forming, and that a non-profit organization is planned to manage key decisions. Operaton's repository states it has no open-core model and no commercial editions, and that professional support comes from multiple independent service providers. Ask any provider you consider which Operaton versions they will patch, how long they commit to back-port fixes, and whether their contract survives a change in the project's governance. Those answers replace the vendor commitments you would get from Camunda.

Camunda 8 follows a different model. Its releases are versioned as lines with dated patches, such as 8.10.4 on October 13, 2026, with 8.9 and 8.8 patches on October 14, 2026, and commercial Enterprise subscriptions include Camunda's support. Those are the commitments you pay for, and they are the reason a Camunda 8 decision carries a license cost that Operaton does not. The trade-off is operational: with Operaton, your own engineers or a contracted provider hold the patch and upgrade obligations that Camunda would otherwise carry. Confirm the exact support terms in your Camunda contract and in any Operaton provider agreement before you compare the two.

Camunda 8 Self-Managed in production requires buying the Self-Managed Enterprise Edition, so the license is the first recurring line item and is set by a Camunda quote; this page does not state a price. Under the Camunda License v1, the non-production license is the only no-fee path, so a team that moves production workloads to Camunda 8 should budget the subscription from day one. Alongside it sits the Kubernetes footprint: Zeebe brokers, Elasticsearch or OpenSearch for Operate and Tasklist, and the Identity and Optimize components where they are used. Ask the vendor which of these components your architecture needs, how many brokers and partitions are assumed, and whether the quote covers support tiers, upgrades and the Data Migrator work.

Operaton removes the license fee entirely, since it is Apache-2.0 with no commercial editions, but the cost moves to the components you run yourself. The main recurring items are the relational database (PostgreSQL 14 or newer, MariaDB 10.11 or MySQL 8.4 as minimums in the 2.1 release notes), the application servers or Kubernetes cluster that host your embedded engine, and the engineering time for patching, monthly and half-yearly upgrades, and backups. Support is optional. If you want it, independent service providers offer it, and that contract is a recurring cost you negotiate separately. Each cost rises with the number of process applications, the volume of instances and the number of environments you must keep current.

Both paths share a one-time migration project, and its size depends mostly on how much Camunda 7 code you have. For Operaton, the OpenRewrite recipe handles imports and artifacts, but stored scripts, expressions and custom listeners still need manual review and testing. For Camunda 8, the Diagram Converter and code conversion utilities help, yet a remodel around remote workers, the loss of embedded transactions and the in-flight instance strategy usually cost more. Before you accept any quote, ask for: the license term and renewal price cap, the included support hours and response targets, the named upgrade path from your current version, a list of components priced separately, and the migration scope in writing. Compare these on a five-year total so the recurring lines are visible.