What is Camunda? One name, two different products

Camunda today is two different products that share one name. Camunda 7 is a Java framework: the process engine can run inside your own application, in the same process and often against the same database. Camunda 8 is a separate platform built around an engine called Zeebe, which runs as its own service next to your application and is reached over the network.

Almost every question that follows depends on this one distinction: what an upgrade involves, which licence you need, whether your code keeps running, and whether any of the maintenance dates applies to you at all. That is why it comes first.

Who is behind Camunda?

camunda.com is operated by Camunda Services GmbH, based at Zossener Straße 55-58, 10961 Berlin, and registered with the Charlottenburg local court (Amtsgericht Charlottenburg), according to its imprint (camunda.com, Imprint).

Older documents use other names for the same two products. Camunda’s own support announcements still say “Camunda Platform 7” and “Camunda Platform 8” (docs.camunda.org, Support Announcements). The older name Camunda BPM survives in the Camunda 7 Maven group org.camunda.bpm and in the name of its repository, camunda-bpm-platform.

Camunda 7: an engine that runs inside your application

Camunda describes Camunda 7 as a Java-based framework that can run in two ways: “Camunda can be used both as a standalone process engine server or embedded inside custom Java applications.” It goes on: “The embeddability requirement is at the heart of many architectural decisions within Camunda.” (docs.camunda.org, Architecture Overview)

The documentation names three deployment scenarios. The one you run decides how much work a later change of platform takes.

Only the third of these has a counterpart in Camunda 8. That is the heart of the whole subject, and it is why two companies on the same Camunda version can face entirely different migrations.

Camunda 7’s web applications include Cockpit for monitoring and operations, Tasklist for human task management and Admin for user management (docs.camunda.org, Web Applications).

Camunda 8: an engine that runs next to your application

The Camunda 8 engine is called Zeebe. Camunda introduces it like this: “Zeebe is the process automation engine powering Camunda 8. While written in Java, you do not need to be a Java developer to use Zeebe.” On architecture it adds: “Zeebe doesn’t rely on a central database, so there’s no performance bottleneck as process volumes increase.” Data is distributed across the brokers of a cluster, with storage directly on the server filesystem (docs.camunda.io, Introduction to Zeebe).

Camunda’s migration guide states the consequence plainly: “the workflow engine in Camunda 8, Zeebe, is always a remote resource for your application”. The same page says that the embedded engine mode is not supported (docs.camunda.io, Conceptual differences).

An embedded library therefore becomes a cluster that someone has to run. Camunda presents that design as the source of its scalability. Running it is also a standing operational task for your team, for as long as the platform runs.

Camunda 8 has further components around its engine. Camunda’s component overview, at version 8.10 on the day of checking, groups Zeebe, Operate, Tasklist and Identity into the Orchestration Cluster, and lists Camunda Hub, Desktop Modeler, Connectors and Optimize beside it (docs.camunda.io, Using Camunda 8). The interface names are the fastest way to answer a question that arrives as a screenshot.

Which Camunda do you run?

Four quick checks. Only the first one needs access to your code.

1. The dependency in your build. The group org.camunda.bpm, for example org.camunda.bpm:camunda-engine, means Camunda 7. The group io.camunda, for example io.camunda:camunda-client-java, means Camunda 8 (docs.camunda.io, Java client). Camunda’s own code conversion guide maps one to the other: imports from org.camunda.bpm.engine.* are replaced by io.camunda.client.* (docs.camunda.io, Code conversion).
2. The name of the interface. Cockpit means Camunda 7. Operate means Camunda 8.
3. The documentation your team reads. docs.camunda.org carries the Camunda 7 manual, for versions 7.0 to 7.24 (docs.camunda.org, Architecture Overview). docs.camunda.io titles its pages “Camunda 8 Docs” (docs.camunda.io, Java client).
4. The version number. Anything starting with 7. is Camunda 7, and 7.24 is the last minor release. Anything starting with 8. is Camunda 8.

Camunda puts the last point in its own words: “Camunda 7.24 LTS (Long Term Support) is the last minor release of Camunda 7. No new feature-adding releases of Camunda 7 will be built anymore.” (docs.camunda.org, Support Announcements)

If the answer is Camunda 7, the next questions are your minor version and your edition, because the maintenance dates depend on both. The Community Edition stops at 7.24.0: the Maven Central description of that artifact reads “7.24.0 is the last community edition release published on Maven Central.” (Maven Central, camunda-engine 7.24.0) Patch releases are only available to Enterprise Edition customers, according to Camunda’s Release Policy (docs.camunda.org, Release Policy). For the Enterprise Edition, the newest section of Camunda’s Patch Level Update guide on the day of checking was 7.24.16 (shared with 7.23.18), dated Oct/2026 (docs.camunda.org, Patch Level Update), and the Support Announcements give 8 October 2026 as the release date of that Enterprise Edition patch. The full matrix of dates per version is in Camunda 7 end of maintenance.

For the Enterprise Edition, Camunda’s migration page sums up its current position: “Camunda 7 Enterprise Edition remains supported through April 2030, but we recommend all new projects be developed on Camunda 8.” (camunda.com/platform-7/migrate)

Which licence covers Camunda, and what is free about it?

For Camunda 7, the documentation says of the Community Edition: “If you are using the community edition, the entire software is provided under various open source licenses (mainly Apache 2.0 and MIT).” (docs.camunda.org, Licenses) The repository camunda/camunda-bpm-platform carries the Apache 2.0 licence on GitHub and is archived (GitHub, camunda/camunda-bpm-platform).

Camunda 7 Community Edition reached end of life in October 2025. Camunda scheduled its final feature release, 7.24, for 14 October 2025. Camunda’s forum announcement of 28 February 2025 states the month of the end of life and adds that no further Community Edition releases follow that date (forum.camunda.io, Camunda 7 Community End of Life clarification).

Camunda 8 is licensed differently. The source code of Zeebe, Operate, Tasklist, Identity and Optimize is under the Camunda License v1, the compiled software under a proprietary licence, and the documentation is explicit: “To use the software in production, purchase the Camunda Self-Managed Enterprise Edition.” (docs.camunda.io, Licensing)

For an installation that has run Camunda 7 Community Edition without licence fees for years, this is the line in the whole comparison that matters most for the budget. A free library is replaced by a platform that needs a commercial licence for production.

Which standards does Camunda cover?

Camunda 7 implements three standards of the Object Management Group: BPMN 2.0 for processes, DMN 1.3 for decisions and CMMN 1.1 for case management (docs.camunda.org, Implemented Standards). BPMN is the one that matters most, and the only one you need to know to take part in a migration decision. How to draw and read BPMN models with Camunda’s own tool is covered in the Camunda Modeler guide.