Why teams need an alternative to Camunda 8 with an embedded Java engine
If your application runs an in-process BPMN engine and calls Java delegates inside the same transaction, Camunda 8 does not give you that model. In Camunda 8 the Zeebe engine is a remote resource, embedded engine mode is not supported, and the Java delegates that held your glue code become job workers that communicate with the engine over the network. Flowable, Operaton and CIB seven keep the embedded Java engine model, so the application can keep its process logic close to its data and transactions.
The changes are concrete. Camunda's migration guidance states that glue code implemented as Java delegates in Camunda 7 becomes job workers in Camunda 8, which means your service calls, retries and error handling must be redesigned around an external worker lifecycle. Expressions also change: Camunda 7 uses the Java Unified Expression Language (JUEL), while Camunda 8 uses FEEL, where expressions can only access process instance data and variables. Any JUEL expression that reaches into application beans or static methods will need rewriting before it runs. Inventory these expressions and delegates early, because they determine how much of the application changes.
The licensing question is separate and sits on top of the architecture question. From Camunda 8.6, the source of Zeebe, Operate, Tasklist, Identity and Optimize is under the Camunda License v1, and production use of Camunda 8 Self-Managed requires the Self-Managed Enterprise Edition. Confirm with Camunda which edition and terms apply to your deployment, and ask for the terms in writing before you plan a production cutover. Your decision should weigh the architecture change and the license change together, since an alternative that keeps the embedded model may also remove the remote-cluster operating dependency.
What an embedded engine requires from the platform
An embedded engine ties process state, Java code and scheduling to the application itself. Each card below names one requirement of that model, how Camunda 8 changes it, and what to confirm in a candidate engine before you commit.
In-process engine in the application JVM
The engine runs as a library inside your application's Java virtual machine, so deployment, classpath and upgrades move with the application. Camunda 8 treats the Zeebe engine as a remote resource and does not support embedded engine mode, so this is the first requirement that Camunda 8 cannot meet. Check whether the candidate ships as a JAR for Java SE, servlet containers and Spring, and whether your application server versions are in its supported list.
Java delegates in the same transaction
Java delegates called from service tasks can join the same database transaction as your business code, so a process step and a domain update commit or roll back together. In Camunda 8, the equivalent glue code becomes job workers, which run outside the engine's transaction and need idempotent handling. Confirm how each candidate handles transaction boundaries for asynchronous continuations and whether your delegates depend on the shared transaction.
JUEL expressions in process models
Camunda 7 models use the Java Unified Expression Language, which can reach Spring beans and Java objects inside the application. Camunda 8 uses FEEL, where expressions can only access process instance data and variables, so JUEL expressions and bean references must be rewritten or moved into delegates. Inventory every expression in your BPMN and DMN files and confirm which expression languages the candidate engine evaluates before you plan rework.
Relational database as the state store
An embedded engine keeps process instances, variables, jobs and history in tables your team already operates, so backup, restore and access control follow your database policy. Camunda 8 stores engine state in Zeebe partitions on Kubernetes instead. Confirm which databases the candidate supports, the minimum versions you must run, and how history tables grow and get purged in your environment.
Clock-based async executor across nodes
Timers and asynchronous jobs run from a thread pool, and nodes coordinate through lock owners and lock expiration times stored in the database. When a node fails, expired locks are recovered and another node picks up the job. Camunda 8 moves this scheduling to the Zeebe cluster, so you must instead test job locking, clock skew and retry behavior under your own load and failover scenarios.
Identity and user task integration
Embedded engines expect a user and group source for task assignment, and many teams connect it to LDAP or an existing directory. Flowable allows the identity service to be replaced with a custom implementation, with an LDAP reference provided, while Camunda 8 depends on its own identity and task components. Confirm how group membership and candidate users map to your directory before choosing a platform.
Which embedded engine fits which application
This table compares Flowable, Operaton and CIB seven on license, Camunda 7 lineage, databases, Java and Spring baselines, support model and release cadence. Read each row as a question to put to the vendor or community before you commit, since the answers decide how much upgrade and support work your team takes on.
| Criterion | Flowable | Operaton | CIB seven |
|---|---|---|---|
| License | Apache 2.0 open source engines, with commercial editions sold separately | Apache 2.0, no open-core model and no commercial editions | Apache 2.0 source, with free Community edition and paid Community+, LTS and Enterprise editions |
| Camunda 7 lineage | Independent engine; Camunda 7 data needs a migration path (see sibling topic) | Forked from the Camunda 7 CE codebase; schema kept at 7.24 | Open-source fork of Camunda 7 CE; 2.1 backend based on Camunda 7.24.0 |
| Supported databases | H2, MySQL, Oracle, PostgreSQL, DB2 and SQL Server | H2, PostgreSQL, MySQL, MariaDB, Oracle, SQL Server and DB2 | H2, PostgreSQL, MySQL, MariaDB, Oracle, SQL Server and DB2 per the 2.2 supported environments page |
| Java and Spring baseline | Flowable 8.0.0 requires Spring Boot 4 and Spring Framework 7; version 7 used Java 17 and Spring Boot 3 | Requires Java 17, tested on 17, 21 and 25; built on Spring Boot 4.0.6 | Java 17 and 21 supported on Tomcat 11.0, JBoss EAP 8.1 or WildFly 40.0 |
| Embedded or remote use | Embeds as a JAR or runs as a REST service | Embeds in Spring, Quarkus or Jakarta EE; also ships Docker and Helm | Embeds in the JVM; ships its own task list and monitoring UI from 2.0 |
| Support model | Community forum; professional services and partners sold separately | Community governance still forming; independent service providers offer support | Vendor-backed support from CIB software; paid editions add security patches |
| Release cadence | Major releases such as 7.x and 8.0.0 on a multi-year pattern | Half-yearly feature releases in April and October, monthly patches, 6 months support per version | Security patches and hotfixes every 4 to 8 weeks in paid editions, per the CIB seven FAQ |
| Trade-off to weigh | Version 7 removed the UI applications, form engine and content engine, so Camunda 7 Tasklist or Cockpit users need replacements | No LTS line, so each version must be upgraded within about six months of support; confirm the upgrade plan with your team | LTS and Enterprise editions carry a subscription cost; confirm the support duration per edition with CIB |
What changes for transactions and operations
In an embedded engine, a Java delegate runs in the same JVM and, when the engine shares the application's transaction manager and data source, its database writes can commit or roll back together with the application's own changes. That is the main reason teams choose this model. In Camunda 8, the Zeebe engine is a remote resource, and the Camunda 7 to 8 migration guide states that glue code written as Java delegates becomes job workers. Each worker is a separate deployable component that polls or streams jobs from the cluster, so the transactional boundary moves from your application's database to a message exchange with the cluster. Before you commit to either model, confirm in each engine's documentation exactly where the transaction starts and ends, whether delegate code can join the caller's transaction, and how retries behave when a commit fails after the external side effect has already happened.
For multi-node deployments, the Flowable advanced documentation describes an async executor that runs timers and asynchronous jobs from a thread pool. Nodes coordinate through lock owners and lock expiration times stored in the database, so when a node stops, its expired locks are recovered and another node picks up the jobs. Plan your database and clock configuration around that behavior, and test node failure during timer firing in a staging environment. For monitoring, the Flowable Spring Boot docs describe an actuator endpoint at /actuator/flowable for inspecting running processes, which lets operations teams check engine state with the same tooling used for the rest of the application. CIB seven takes a different operational route: from version 2.0 it ships its own user interface for task lists, process monitoring and user and rights management, independent of the Camunda Tasklist, Cockpit and Admin modules, so you must decide whether its built-in tools replace your existing dashboards or sit beside them.
Operaton keeps the Camunda 7 operating model, so its job executor and monitoring approach should be verified against its own documentation rather than assumed from the Flowable or CIB seven material. Whichever engine you choose, check the transaction boundaries, lock-expiry settings, monitoring endpoints and retry policy with a failure test that kills a node mid-job, then record the results as part of your operations runbook.
How to deploy an embedded engine under your constraint
This sequence takes a Camunda 7 style application with Java delegates and moves it onto an in-process engine you run, with the baseline, database, clustering, identity and operations decisions made and checked before go-live.
Choose the engine and fix the baseline version
Your application team and architects pick Flowable, Operaton or CIB seven based on how closely the code must match Camunda 7 and which support model you need. Record the exact engine version and, for CIB seven, the Camunda 7 baseline it is built on. CIB seven's migration guide says projects on older Camunda versions must first update to the matching baseline (CIB seven 2.1 is based on Camunda 7.24.0), so schedule that update before any namespace change. Done when the chosen version is written into the architecture decision record and every module compiles against it in a test build.
Select and verify a supported database version
The DBA and platform team confirm the database engine and version against the engine's published support matrix before anything is provisioned. Operaton 2.1 lists minimum versions of PostgreSQL 14, MariaDB 10.11 and MySQL 8.4, and CIB seven 2.2 lists PostgreSQL 15 to 18 and MySQL 8.0, so the two matrices differ and must be checked against your own platform. For Flowable, confirm that the MySQL version has millisecond precision, since the configuration docs flag versions below 5.6.4. Done when a schema creation run completes on the target database in a non-production environment.
Migrate namespaces and run the conversion tooling
Engineers apply the engine's migration tooling to source code and build files. For Operaton, the OpenRewrite recipe for migrating from Camunda 7 covers the move. For CIB seven, the OpenRewrite script updates Maven versions, artifact names and imports from org.camunda to org.cibseven, and the Liquibase changelog path changes from org/camunda to org/cibseven. Flowable is a different namespace, so expect manual rework of delegates and listeners. Done when the code compiles, unit tests pass and a diff review confirms no remaining org.camunda imports in application code.
Fix stored artifacts that still reference Camunda classes
Developers search the database and deployed models for objects the migration tooling does not rewrite. CIB seven's guide warns that script tasks and variables already stored in the database that reference org.camunda classes are not renamed automatically, and it provides namespace compatibility properties for scripting and reflection that are disabled by default. Decide whether to enable them temporarily and document why. Done when a query of stored definitions and variable types returns no unexpected Camunda class references.
Embed the engine or run the REST service
Architects choose the deployment shape. Flowable can be embedded as a JAR in Java SE applications, servlet containers such as Tomcat or Jetty, Spring applications or Java EE servers, or run as a standalone service through its REST application. Operaton ships Spring Boot, Quarkus, Tomcat and WildFly distributions, and CIB seven ships its own task list and monitoring UI with Spring Boot, Quarkus, Docker and Kubernetes setups. Done when a deployed process runs end to end from a delegate or service task, and a rollback of the application deployment is tested.
Configure the async executor across nodes
Platform engineers configure job execution for every node that shares the database. In Flowable, the async executor runs timers and asynchronous jobs from a thread pool and coordinates nodes through lock owners and lock expiration times stored in the database, so an expired lock is picked up by another node. Set pool sizes and lock settings per node, then test a node failure during a running timer. Done when a job held by a killed node is executed once by a surviving node and no duplicate side effects appear in logs.
Replace identity with your directory
Security and application engineers connect the engine to the corporate directory instead of the built-in user store. Flowable's docs say identity management can be replaced by overriding IdmIdentityServiceImpl or implementing the IdmIdentityService interface, with an LDAP identity service provided as a reference. Operaton and CIB seven have their own identity mechanisms, so confirm their directory integration options with the vendor or project docs. Done when a user from the directory can log in, see only assigned tasks, and group-based candidate assignments resolve correctly.
Containerize and set backup and upgrade windows
The platform team packages the application with Docker and deploys it through Helm charts where the engine provides them (Operaton publishes official Docker images and Helm charts; CIB seven lists Helm charts as in preparation). Define backup of the engine database as a joint job with application data, test restores, and agree a patch cadence with the business. Operaton's FAQ describes monthly patch releases and six months of support per version, and CIB seven's paid editions ship security patches every 4 to 8 weeks, so set upgrade windows around those dates. Done when a restore test returns the database to a consistent state and an upgrade has been rehearsed in staging.
Which engine fits which starting point
Teams running Camunda 7 Community Edition are on an end-of-life path. The Camunda 7 CE repository is archived, and its final feature release, 7.24, was scheduled for October 14, 2025, with no further releases or security patches for the community version. Two open-source forks continue the same embedded model. Operaton is an Apache-2.0 fork with a compatible REST API, database schema and deployable BPMN and DMN models, and it publishes an OpenRewrite recipe for migrating from Camunda 7. CIB seven is an Apache-2.0 fork of Camunda 7 CE, and its migration guide requires matching the Camunda baseline version (2.1 is based on Camunda 7.24.0) before migrating, then running an OpenRewrite script for imports and artifacts.
- Operaton release cadence: half-yearly feature releases in April and October, monthly patches, and six months of support per version with no traditional LTS line.
- CIB seven editions: a free Community edition plus paid Community+, LTS and Enterprise editions, with security patches every 4 to 8 weeks for paid distributions.
- Stored artifacts: CIB seven notes that script tasks and variables referencing org.camunda classes are not renamed automatically.
- Database versions: Operaton 2.1 sets minimum PostgreSQL 14, MariaDB 10.11 and MySQL 8.4; confirm your current database against each fork's supported list.
- Governance: Operaton is community-maintained with governance still forming, while CIB seven is maintained by CIB software GmbH.
Confirm the support window and patch policy you need in writing before choosing a fork, because the two forks promise different things.
Teams on Camunda 7 Enterprise Edition have a longer runway. Camunda extended the Camunda 7 Enterprise end of life from April 2027 to April 9, 2030, with fee-based extended support available from April 2030 through April 2032, according to Camunda's announcement. This tab is about the decision timing and what changes if you stay on the commercial line. Staying on Enterprise keeps the same engine and code, but the engine's lifecycle is set by Camunda and the extended support is paid. Camunda also offers a Data Migrator that copies running Camunda 7 instances to Camunda 8 with state preserved, with runtime migration documented as production ready from Camunda 8.8 and history migration as experimental.
- Enterprise support window: the end of life is April 9, 2030, with extended support available for a fee through April 2032.
- Data Migrator scope: runtime migration is production ready from 8.8, history migration is experimental, and a Diagram Converter handles BPMN models.
- Forks as an exit: CIB seven states that from version 2.0 it ships its own task list, process monitoring and user management, and that CIB seven Enterprise offers all Camunda 7 Enterprise features starting with version 2.1.2.
- Remote engine change: Camunda 8 replaces embedded Java delegates with job workers, so any move off Camunda 7 means reworking glue code.
- Decision timing: plan the exit or renewal against the April 2030 date, and ask for the specific features your application depends on before comparing.
Ask CIB seven and Camunda for written confirmation of feature parity for the Enterprise modules your application uses, since the engine code is the same but the surrounding tooling differs.
Teams starting a new project that needs an in-process engine can evaluate Flowable, which is Apache-2.0 licensed and covers BPMN, CMMN and DMN. Flowable can be embedded as a JAR in Java SE applications, servlet containers such as Tomcat or Jetty, Spring applications and Java EE servers, or run as a service through its REST application. Its Spring Boot starters cover all engines and the REST layer, and an actuator endpoint at /actuator/flowable supports monitoring. Flowable 8.0.0 was released on February 27, 2026, and it requires Spring Boot 4 with no backward compatibility for Spring Boot 3. Flowable's commercial products, such as Flowable Work and Orchestrate, are built on the same engines, and open source users get a community forum with professional services offered separately.
- Spring Boot version: Flowable 8.0.0 requires Spring Framework 7 and Spring Boot 4, so teams on Spring Boot 3 need a separate upgrade plan.
- Async executor: timers and jobs use lock owners and expiry times in the database, so confirm the behavior in your cluster topology.
- Identity: the identity service can be replaced by implementing IdmIdentityService, with an LDAP reference implementation.
- Databases: H2, MySQL, Oracle, PostgreSQL, DB2 and SQL Server are listed, and MySQL below 5.6.4 lacks millisecond precision.
- Version 7 history: Flowable 7.0.0 removed the UI applications and the form and content engines, so check that your required modules still exist.
Run a proof of concept against your own database and identity source before committing, and confirm which support tier you need.
Evidence auditors and regulators ask for
An embedded engine moves process logic into your own applications, so the evidence trail moves with it: which engine version runs where, who can change it, and whether the process database can be restored. DeployOpen prepares this evidence inside your environment, and independent auditors and regulators decide whether it is sufficient.
License inventory per engine
List every engine, edition and library in each application, with its license and the source of the artifact. For Flowable, Operaton and CIB seven, the core engines are Apache-2.0, but paid editions, support contracts and bundled components may carry other terms. Record which edition each team uses in production and confirm the terms for each with the vendor or project, since licenses change between releases.
Database and Java version matrix
Keep a matrix that ties each application to its Java runtime, engine version, and database type and version. Operaton 2.1 requires Java 17 and sets minimum database versions, and CIB seven 2.2 lists its own supported Java, database and application server combinations. Auditors use this matrix to confirm that production runs on versions the project still supports.
Change and upgrade records
Record each change to engine versions, BPMN and DMN models, Java delegates and database schema, with the approver, test evidence and rollback plan. Flowable, Operaton and CIB seven ship on their own release schedules, so keep the release notes you tested against. Regulators often ask how a change reached production and whether it was reviewed before it did.
Process database backup and restore tests
The engine state, including running instances, timers and jobs, lives in your relational database, so backups must cover that database as a unit. Run timed restore tests into a separate environment and record the recovery point and the time taken. Confirm with your DBA that the test restores running instances, not just the schema, and that the async executor resumes cleanly afterward.
Access controls on admin and task interfaces
Engine admin consoles, REST APIs and task lists expose instance data and let operators retry or cancel work. Document who holds each role, how those roles map to your identity provider, and how access is reviewed. Flowable documents replacing its identity service with an LDAP reference implementation, and CIB seven ships its own task list and user management, so confirm where authorization is enforced for each.
Support and patch records
Keep a dated record of the security patches, hotfixes and support status for each engine and edition in use. CIB seven states that paid distributions receive security patches every 4 to 8 weeks, and Operaton supports each version until the next ships. Auditors will look for evidence that the organization applied these updates within its own policy window, not only that updates exist.
Questions buyers ask before choosing an embedded engine
What drives the cost of moving from Camunda 8 to an embedded Java engine?
The cost depends mostly on how much Camunda-specific code you have, not on the engine license, because Flowable, Operaton and CIB seven are all Apache 2.0 licensed for their core. Cost components are the engineering time to replace Java delegates with service tasks, the work to rework expressions from JUEL to FEEL where they are used, the database and infrastructure you run yourself, and any paid support contract. The one-time work is the migration and testing; the recurring part is operations, upgrades and support. Ask any partner for a written scope that lists each component separately so you can compare them against your current Camunda 8 subscription.
How long does it take to migrate an application to an embedded engine?
No supplied figure gives a duration, so treat any timeline as something to scope rather than assume. The variables that set the timeline are the number of BPMN and DMN models, how many Java delegates and job workers you must convert, how many expressions depend on JUEL or FEEL behavior, the number of running instances you must keep, and how much of your UI depends on Camunda Tasklist or Cockpit. Ask for a written plan with milestones and a test scope before work starts.
What does our team need to provide for the migration?
You need people who know the business processes, the Java application, the database and the identity source. Flowable documents embedding in Java SE, servlet containers, Spring and Java EE, and it lets you replace identity management through its IdmIdentityService interface. Your team should provide access to the source code, the deployed BPMN and DMN models, the database environment, test data and an owner for each business process. Confirm which Java version and database your environment already runs, because the supported versions differ between the engines.
Can our own engineers run an embedded Java engine without an outside partner?
Yes, if your team already operates Java services and a relational database. An embedded engine runs inside your application, so you own its deployment, its database schema, its upgrades and its async executor configuration. Flowable's async executor coordinates nodes through lock owners and lock expiration stored in the database, which your operations team must monitor. Teams without that experience often bring in an implementation partner for the first release and then keep the operations in-house.
What support models exist for Flowable, Operaton and CIB seven?
Each project has a different model. Flowable is open source under Apache 2.0 and sells commercial editions built on the same engines, with a community forum for open source users and professional services offered separately. Operaton has no commercial editions and no single company in control; professional support comes from multiple independent service providers. CIB seven offers a free Community edition plus paid Community+, LTS and Enterprise editions, and it says security patches and hotfixes ship every 4 to 8 weeks for paid distributions, with urgent fixes as needed. Ask each vendor for its written support window, because the CIB seven FAQ gives no fixed support duration per edition.
Can in-flight Camunda 7 process instances move to an embedded engine?
For Camunda 7 data, the answer depends on the target. Operaton keeps a database schema compatible with Camunda 7.24, and CIB seven 2.1 is based on Camunda 7.24.0, so running instances can usually stay in the same database after you update the artifacts and imports, with the caveats below. CIB seven warns that stored objects, such as script tasks or variables that reference org.camunda classes, are not renamed automatically. Projects on older Camunda versions must first update to the matching Camunda baseline. Flowable's own migration path for Camunda 7 data should be checked against its LEAP assessment before you commit. Ask for a test migration on a copy of production data.
Does an embedded engine change how transactions and operations work?
Yes. In an embedded engine, process steps and your application code can share one database transaction, so a delegate that writes business data can commit or roll back together with the process state. In Camunda 8, the Zeebe engine is a remote resource, and Java delegates become job workers that communicate over the network, so the two systems must be designed for eventual consistency. Operationally, the embedded model puts timers, jobs and locks inside your database and your application nodes. Test failure handling, retries and lock recovery under load before you go live.
How DeployOpen deploys embedded engines in your environment
DeployOpen plans, implements, integrates, hardens and documents self-hosted open-source process engines inside your own cloud accounts, data centers or air-gapped networks. For teams that need an embedded Java engine with Java delegates, we scope the engine choice, the transaction model and the operating setup in writing before any build work starts.
How we scope
- We confirm which applications embed the engine and which Java delegates, listeners and scripts must keep working.
- We map JUEL expressions and Camunda 7 APIs to the chosen engine so rework is visible before work starts.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any build begins.
How we build
- We deploy the chosen engine on your database platform, with transaction boundaries and async executor settings reviewed.
- We integrate identity, job execution and monitoring with your existing services, then test in-flight process behavior.
- We harden the deployment and set up backups and upgrade procedures for the engine and its schema.
How we hand over
- You receive architecture notes, configuration documentation, runbooks and the test evidence gathered during the build.
- We document which Camunda 7 contracts were kept, changed or replaced, so your reviewers can trace each decision.
- Handover includes a walkthrough with your engineering and operations teams before the engagement closes.
How we support
- Ongoing support, version upgrades and continuous security testing are available as retainers after handover.
- We track each engine's release and support cadence so your upgrade plan keeps pace with vendor and community releases.
- We prepare systems, controls and evidence for compliance assessments, while independent auditors issue any formal opinion.
