Operaton is an Apache-2.0 BPMN 2.0 process engine that runs on the Java Virtual Machine, built for teams that need to embed or self-host mission-critical workflow automation under community governance.

What it is

Operaton is a native BPMN 2.0 process engine that runs inside the Java Virtual Machine. It was born from the Camunda 7 community edition and continues as a community-driven project under the Apache License 2.0, with no open-core model and no commercial editions. It is a full-stack platform: the Operaton Engine executes BPMN 2.0 processes, a REST API provides remote access to running processes, and three web applications cover the rest of the lifecycle — Operaton Cockpit for process operations and monitoring, Operaton Tasklist for managing and completing user tasks, and Operaton Admin for users, groups and access permissions.

The concrete problem it solves is continuity for organizations whose business processes are already modelled in BPMN and running on the Camunda 7 community edition. Operaton keeps the REST API, the database schema and deployable BPMN and DMN models compatible with Camunda 7, and ships an OpenRewrite migration recipe so existing deployments move across without re-modelling. Because the engine runs inside any Java application, with Spring, CDI and Quarkus integration, teams keep process execution in their own infrastructure rather than handing it to an external service.

Key capabilities

• Executes BPMN 2.0 processes natively on the JVM, with integration for Spring Boot, Quarkus and Jakarta EE.
• Provides the full set of web applications for the BPM lifecycle: Operaton Cockpit for process operations and monitoring, Operaton Tasklist for user tasks, and Operaton Admin for users, groups and permissions.
• Exposes a REST API for remote access to running processes.
• Supports H2, PostgreSQL, MySQL, MariaDB, Oracle, SQL Server and DB2 as backing databases.
• Stays compatible with existing Camunda 7 BPMN, DMN and Forms models, REST API and database schema.
• Includes an MCP server for integrating AI assistants and LLMs with the engine.
• Extends through plugins and connectors, with a Keycloak identity provider plugin, official Docker images and Helm charts for Kubernetes.

Who uses it and how

• Java teams embedding the engine inside Spring Boot, Quarkus or Jakarta EE services so that process execution stays in-process.
• Organizations already running Camunda 7, which migrate with the OpenRewrite recipe while preserving their models, schema and REST clients.
• Operations staff who monitor running processes in Cockpit and complete human tasks in Tasklist, with access controlled through Admin.
• Teams deploying on-premise, on cloud providers or on application servers, including Kubernetes through the Helm charts, and buying support or consulting from third-party service providers.

Getting started

The quick-start path is the official Docker image: docker run -d --name operaton -p 8080:8080 operaton/operaton:latest, after which the web interface is served on port 8080 with the demo / demo credentials. New projects can be scaffolded with the Operaton Starter at start.operaton.org, and the Getting Started Guide at docs.operaton.org covers detailed setup.

How it compares

Operaton's closest relative in the facts is Camunda 7: it continues that community edition rather than reimagining it, and matching REST API, database schema and deployable models mean an existing Camunda 7 installation can move across with an OpenRewrite recipe instead of being rebuilt. On governance and cost it is Apache-2.0 with no open-core model, no commercial editions and no single-vendor control, with support and consulting available from multiple service providers.

When to use it — and when not to

A self-hoster has to operate a JVM deployment alongside one of the seven supported relational databases, plus the web applications needed for operations and task management; the Docker command above is a quick start, not a managed service. Teams that want a vendor-run hosted platform, or that are unwilling to operate a relational database, should not select it on the basis of the material here, since only self-managed Docker, Helm and application-server deployment is described. The project is also carried by a community rather than a single vendor, and the registry snapshot records 68 open issues, so the governance and support model should be an explicit part of the decision.

docker run -d --name operaton -p 8080:8080 operaton/operaton:latest

./mvnw clean install

./mvnw clean install -DskipTests -Dskip.frontend.build=true