Camunda 8 or Flowable: which fits your process estate
Camunda 8 fits teams that want the Zeebe cluster, Operate, Tasklist and vendor support, and are prepared to hold an Enterprise license for production. Flowable fits teams that want an Apache 2.0 engine they can embed in a Java application or run as a standalone service with REST APIs. The choice turns on four questions: the production licensing budget you can commit to, whether your processes need an in-process Java engine, whether you need CMMN case management alongside BPMN and DMN, and who in your organization will operate the Kubernetes and database infrastructure for years after go-live.
Start with licensing, because it sets the cost baseline for everything else. Since Camunda 8.6, the core components (Zeebe, Operate, Tasklist, Identity and Optimize) are under the Camunda License v1, and production use of Camunda 8 Self-Managed requires the Self-Managed Enterprise Edition. The Camunda Self-Managed Non-Production license covers test and development use only. Ask Camunda in writing which edition, node sizing and support tier your production workload needs, and whether renewal terms change the price. Flowable's engines are Apache 2.0, but Flowable also sells commercial editions, so confirm which Flowable capabilities you actually need before assuming the open-source engines cover them. Where the engine is free, the cost moves to people: you pay for hardening, upgrades, monitoring and support contracts, whether internal or external.
Architecture and operations decide the rest. Camunda 8 runs the workflow engine as a remote cluster, so your team must operate Kubernetes, the Zeebe brokers and their storage. Flowable can run embedded in Spring, Tomcat or Jetty applications, so transactions can share the application's database connection, or it can run as the Flowable REST application. Check whether your team has Kubernetes and database operations skills, whether your database supports the Flowable-listed types such as PostgreSQL or Oracle, and whether your async executor and lock behavior have been tested under your node count. Map each process to its requirement before you decide, and use a small pilot to validate the choice.
Which option fits which scenario
This table maps common buyer situations to the platform that usually fits best and the condition that makes that advantage matter. Read each row against your own constraints, such as language stack, deployment model, licensing rules and who will operate the system. The main takeaway is that Camunda 8 fits Kubernetes-first teams with an Enterprise license budget, while Flowable fits embedded Java teams and teams needing CMMN in one Apache 2.0 engine.
| Buyer scenario | Better fit | Reason and the condition that matters |
|---|---|---|
| Java team embedding a process engine in its application | Flowable | Flowable runs as a JAR inside Java SE, servlet, Spring or Java EE applications, so process calls share the application's transactions. This matters only if your team wants in-process execution rather than a remote cluster. |
| Kubernetes-first platform team running shared services | Camunda 8 Self-Managed | Camunda 8 is built around a remote Zeebe cluster on Kubernetes, which fits teams already operating that platform. This holds if you accept an Enterprise license for production and the operating load of Zeebe, Operate and Tasklist. |
| Need for CMMN case management alongside BPMN | Flowable | Flowable ships BPMN, CMMN and DMN engines under one open source project. Camunda 8 is centered on BPMN and DMN, so choose Flowable if adaptive case handling is a core requirement, and confirm the CMMN features you need. |
| Strict Apache 2.0 requirement for production use | Flowable | Flowable's engines are Apache-2.0 licensed, while Camunda 8 core components are under the Camunda License v1 and production self-managed use requires the Enterprise edition. Confirm the license of every component you deploy, including any commercial add-ons. |
| Team wanting vendor SLA-backed support | Camunda 8 Self-Managed Enterprise | Camunda offers Enterprise licensing for production self-managed use. Flowable's open source users get a community forum, with professional services and partners offered separately. Ask each vendor for written support terms and response commitments before deciding. |
| Team that wants an operator-managed environment without a license decision | Camunda 8 SaaS | A managed service shifts infrastructure operations to the vendor, but data location and residency must be checked against your requirements. Confirm where data is stored and processed before selecting this option. |
| Existing Camunda 7 Community estate with embedded Java code | Flowable or Operaton | Camunda 7 CE is end of life, and an embedded model maps more directly to Flowable's in-process engine than to Zeebe. Weigh migration effort for Java delegates and the scope of rework against the cost of a Camunda 8 re-platform. |
What production use requires under each license
From Camunda 8.6, the source code of Zeebe, Operate, Tasklist, Identity and Optimize is under the Camunda License v1, and the compiled software is under proprietary licenses. Camunda's documentation states that production use of Camunda 8 Self-Managed requires buying the Self-Managed Enterprise Edition. The Camunda Self-Managed Non-Production license covers use without a commercial license, but only for non-production purposes such as evaluation and development.
- Source availability is not open source: Reading or modifying the source under the Camunda License v1 does not give the same freedoms as an OSI-approved license, so do not assume Apache 2.0 terms.
- Non-production is a separate permission: Staging environments that serve real users or real data may fall outside the non-production license. Confirm how your environment map classifies them.
- Enterprise Edition is a production requirement: Budget for the Enterprise subscription as a recurring cost, not a one-time purchase, and ask what it includes for support and upgrades.
- Compiled and source terms differ: Ask whether your modifications to source files change your obligations, and whether your use of Camunda components inside other products is permitted.
- Version boundary matters: Terms before and after 8.6 differ, so confirm which license applies to the exact version you plan to run.
Confirm all terms in writing with Camunda and have counsel review the license documents against your planned deployment.
Flowable open source is an Apache 2.0 licensed Java engine for BPMN, CMMN and DMN, with Java and REST APIs. Apache 2.0 permits production use, modification and redistribution under its terms, without a per-environment production license. Flowable also sells commercial editions, including Flowable Work, Engage, Orchestrate and Design, which are built on the same engines and add low-code modeling, visual debugging, security controls, monitoring and governance. Professional services and partner support are offered separately.
- Engine license is not product license: The Apache 2.0 license covers the open-source engines. Commercial applications and their features are licensed separately.
- Community support is a forum: Open-source users get a community forum. Any guaranteed response, patch timing or on-call coverage requires a separate contract.
- Professional services are optional: Implementation, customization and training can be bought from Flowable or partners, or delivered by your own team or an implementation partner.
- Feature gaps change the licensing question: If you need the commercial modeling or monitoring features, the commercial edition becomes a cost driver, so map requirements before choosing.
- Major versions move dependencies: Flowable 8.0.0 changed its Spring and JSON baselines, which can affect the stack your team must support.
Ask Flowable which features, support levels and indemnities each commercial product covers, and have counsel confirm how Apache 2.0 applies to your redistribution plans.
License terms are a legal question, and the summaries on a comparison page cannot replace the signed documents. Each vendor sets its own terms for production, support, modification and redistribution, and those terms can change between versions. The practical task is to turn each vendor's position into a written list of questions answered by the vendor, then review the answers with your legal and procurement teams before any commitment.
- Production definition: Ask the vendor to define production use for your environments, including staging, disaster recovery and internal tools.
- Scope of the subscription: Ask which components, versions, support levels and user or instance limits the fee covers.
- Modification and redistribution: Ask how changes to source, embedded components and bundled distributions are treated.
- Renewal and change terms: Ask how prices, terms and edition boundaries change at renewal and across major versions.
- Exit and continuity: Ask what rights you keep if you stop paying, and what support or patches remain available for the versions you run.
Keep the vendor answers in your contract file, and ask counsel to review them against the license text.
How embedded and remote engines change operations
The core operational difference is where the engine lives. Flowable can run embedded as a JAR inside a Java SE application, a servlet container such as Tomcat or Jetty, a Spring application or a Java EE server, or it can be used over HTTP through the Flowable REST application. Camunda 8 runs the Zeebe engine as a separate cluster that your applications reach through workers and APIs. In an embedded Flowable setup, process state, transactions and deployment are tied to your application's release cycle, so the team that ships the application also ships the process engine. In a remote setup, the engine has its own lifecycle, upgrade path and scaling, and the teams that deploy business logic are separate from the teams that run the cluster. Decide early which model fits your organization, because it sets the ownership boundaries for everything that follows.
Transactions and deployment units behave differently in each model. With embedded Flowable, a service task that writes to your own database can participate in the same transaction as the engine's state changes when both use the same datasource, which makes consistency easier to reason about but couples throughput to the application's connection pool. Plan for this coupling and test rollback behavior with real failure injection. The Flowable Spring Boot docs describe starters for the process, CMMN and DMN engines and for REST, so you can choose which engines a deployment unit carries. Confirm with Flowable which engine versions your Spring Boot baseline requires before you lock the dependency tree, because the Flowable 8.0.0 release notes state there is no backward compatibility for Spring Boot 3. For clustered Flowable nodes, the async executor stores lock owners and lock expiration times in the database, so a node that stops mid-job releases its lock once it expires and another node picks the job up. Test that recovery under load, and set the lock and job timing to match your longest service task.
Monitoring and operations follow from the same split. For Flowable on Spring Boot, the actuator endpoint at /actuator/flowable exposes information about running processes, and you feed that into your existing metrics and alerting stack. Teams moving from a remote Camunda 8 cluster should confirm which Flowable metrics they need to replace, such as instance counts, job backlogs and failed jobs, and map each one to a dashboard before cutover. Operating the database becomes your responsibility under Flowable, including backup, failover and schema upgrades across Flowable releases. Ask your DeployOpen or internal platform team to write a runbook covering node restarts, expired-lock recovery and database failover, and to rehearse it in a non-production environment that mirrors your production topology.
Where data lives and who controls the platform
Camunda 8 and Flowable differ less in where they can run than in who operates the platform, who holds the license, and who must produce the evidence. The cards below cover the decisions that follow from those differences, so you can check each one against your own data residency and audit requirements.
Data location and hosting model
Camunda 8 is offered as Camunda SaaS or as Self-Managed on Kubernetes, so the first question is whether process variables, history and exported data may sit in Camunda's cloud at all. Flowable runs inside your application or as a standalone service on your own servers, which keeps process data in the databases you choose. Confirm which database types your data policy allows, since Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server.
Production licensing for Camunda 8
From Camunda 8.6, the core components are under the Camunda License v1, and production use of Self-Managed requires the Self-Managed Enterprise Edition. The non-production license covers only test and development use, so a self-managed pilot cannot quietly become production. Ask Camunda in writing which components, support terms and redistribution rights apply to your deployment model.
Replaceable identity integration in Flowable
Flowable's identity management can be replaced by overriding its identity service or implementing its identity service interface, and the documentation provides an LDAP identity service as a reference. This lets you map users and groups to your directory without a separate identity product. The work sits with your team, so plan for group mapping, offboarding behavior and testing of task assignment against your real directory.
Audit trails the organization must produce
Neither platform hands you a finished audit trail. With Flowable, you decide how history is retained, where it is stored and how changes to deployed models are recorded, and you must confirm that the chosen history level captures the events your examiners ask about. With Camunda 8, history flows through exporters to a store you operate, so the retention and access controls on that store are your responsibility.
Operational controls for the platform team
Flowable's async executor coordinates nodes through lock owners and lock expiration times in the database, so the database is part of your availability and change control design. Camunda 8 adds Kubernetes, Elasticsearch or OpenSearch and the Camunda components to patch and monitor. Document who approves upgrades, how backups are tested and which team owns each component.
How DeployOpen prepares controls and evidence
DeployOpen can plan and implement the hosting, identity integration, logging and access controls for either platform, then assemble the evidence that an assessor will request. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so agree the evidence set and the scope in writing before work starts.
What moving from Camunda 8 to Flowable involves
The sequence turns a Camunda 8 estate into a tested Flowable deployment with a clear decision on every running instance, a documented database and identity setup, and a cutover that teams have rehearsed. Each step ends with an artifact that proves it is complete.
Inventory models, workers and integrations
Start by listing every BPMN and DMN model deployed to Zeebe, every job type with its worker code and every connector or exporter in use. Record which workers call internal services, which call SaaS APIs and which read or write Elasticsearch or OpenSearch through Operate and Tasklist. Engineering leads own the list, and a business analyst confirms which processes are still live. The step is done when every process and job type has an owner and a disposition: migrate, rewrite or retire.
Map Zeebe workers to Flowable
Each Zeebe job worker needs a target in Flowable. Most in-process logic becomes a Java service task or delegate inside the engine. Calls to remote systems stay outside the engine as external workers or REST calls, with retries and idempotency designed explicitly, since Zeebe's job retry behavior does not carry over automatically. Zeebe FEEL expressions and input/output mappings need rewriting to Flowable expressions and variable mappings. The output is a mapping table reviewed by the engineers who will maintain the code.
Rebuild task handling and operational reporting
Tasklist and Operate are not part of Flowable's open source engines, so user task handling and monitoring need a replacement. Teams usually build a task inbox on the REST API or adopt a commercial Flowable product, and they set up dashboards on the engine's own tables or on the actuator endpoint in the Spring Boot starter. Confirm which Operate views and incident alerts the operations team relies on, and rebuild each one. The step closes when operators can find, claim and complete a task and see failed instances without opening Camunda.
Decide the in-flight instance strategy
For each live process, choose between letting running instances finish on Camunda 8 and migrating their state into Flowable. Finishing in place keeps the Camunda cluster running until the last instance completes, which is usually the lower-risk path for long-running cases. Migrating state requires a tested mapping of Zeebe variables and element IDs. Camunda's Data Migrator targets Camunda 7 data, not Zeebe, so the sibling migration topic covers the options in detail. The output is a signed decision per process with a retirement date for the Camunda cluster.
Set up database, identity and async execution
Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server, so pick one that your database team already operates and back it up. Confirm the async executor configuration for timers and jobs, because lock owners and lock expiration in the database govern how nodes recover work. Identity is not built in for production use, so connect your directory through a custom IdmIdentityService implementation, using the LDAP reference as a starting point. The step is done when a test cluster survives a node restart with timers firing once and no job lost.
Run parallel testing and reconcile results
Run the same business scenarios against Camunda 8 and Flowable in parallel, using identical input data and comparing outcomes, variables, timers and error paths. Include DMN decisions, where hit policies and data types are a common source of drift, and include failure scenarios such as worker outages and duplicate messages. QA leads sign off on each test set, and any mismatch is logged and fixed before cutover. The output is a reconciliation report that operations and the process owners both accept.
Cut over and retire the Camunda cluster
Switch new process starts to Flowable in controlled waves, keeping Camunda 8 open for instances that finish in place. Monitor the Flowable async executor, database load and error queues during each wave, and keep a documented rollback path until the last Camunda instance completes. Once Camunda has no active instances and exports are archived under your retention policy, decommission the cluster and revoke its license and credentials. The step is done when the change record, runbooks and final archive are filed with the operations team.
Questions buyers ask before choosing
What does it cost to run Camunda 8 Self-Managed compared with Flowable?
Camunda 8 Self-Managed in production requires an Enterprise license, so the license fee is the largest recurring line item, and you also pay for Kubernetes capacity, the database and storage that the platform components use, and internal operations time. Flowable's open-source engines (Apache-2.0) carry no license fee for the engine itself, but you pay for hosting, the database, your own build and upgrade work, and optionally a commercial Flowable edition or professional services. Ask any vendor for a quote that separates one-time work from recurring subscriptions and infrastructure, and state which Kubernetes distribution, database and support hours it assumes. The cost difference depends on your process volume, team size and how much support you want in writing.
How long does a migration from Camunda 8 to Flowable take?
The duration depends on scope, and no fixed timeline applies across projects. The main variables are the number of BPMN and DMN models, how many Zeebe job workers you must replace with Flowable service tasks or external workers, whether Tasklist and Operate views must be rebuilt, and how you handle running instances. A narrow scope with few models and a clear cutover window differs greatly from a full estate with long-running processes. DeployOpen agrees timelines in a written, fixed-scope statement of work before work starts, and you should expect the same from any partner you evaluate.
What does our team need to supply for a Flowable project?
Three groups of people usually carry the work. Process owners confirm that each BPMN and DMN model still reflects the business rule, including edge cases and exception paths. Platform engineers who run Kubernetes or database operators decide where the Flowable application runs, how it connects to PostgreSQL, MySQL, Oracle, SQL Server or another supported database, and how backups and upgrades are scheduled. Testers need access to representative data and time to run regression and cutover checks. Name these owners at the start, because a delay in any one of them often becomes the critical path.
Can our own team migrate off Camunda 8 without outside help?
A capable engineering team with Java and BPMN experience can do it, but the work is more than a model export. Flowable runs embedded in a Java application or as a standalone service with REST APIs, so your team must rework job workers, deployment, persistence and monitoring, and must decide how the async executor coordinates multiple nodes. Teams without recent Java platform experience, or those with many running instances, usually benefit from an implementation partner for planning, testing and cutover. Whichever route you choose, put the scope, owners and acceptance tests in writing before you start.
Does Flowable 8.0.0 change upgrade requirements for our Java applications?
Yes, Flowable 8.0.0 changes the platform baseline, so it is not a drop-in upgrade for every application. The release notes describe an upgrade to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3. It also makes Jackson 3 the default JSON library, with a Jackson 2 compatibility layer, and removes JUnit 3 and 4 support. Flowable 7.0.0 moved to Java 17, Spring Boot 3 and Jakarta EE. Check your Java runtime, Spring Boot version, JSON mappings and test framework before choosing a Flowable version, and confirm the exact Java requirement for the release you plan to use in its documentation.
Can we confirm Camunda 8 license terms directly with Camunda?
Yes, you should confirm them directly with Camunda before you sign or renew. Camunda's licensing documentation states that from Camunda 8.6, the source code of its core components is under the Camunda License v1, that compiled software is under proprietary licenses, and that production use of Camunda 8 Self-Managed requires the Self-Managed Enterprise Edition. Non-production use falls under a separate Self-Managed Non-Production license. Ask Camunda to confirm in writing which edition, license and usage limits apply to your deployment, including any use in test, disaster recovery or staging environments. This page does not replace that conversation or your legal review.
What does Flowable's open-source license mean for production use?
The Flowable engine repository is Apache-2.0 licensed, which permits production use, modification and redistribution under the license's terms. Flowable also sells commercial editions such as Flowable Work, Engage, Orchestrate and Design, built on the same engines and adding low-code modeling, visual debugging, security controls, monitoring and governance. Open-source users receive a community forum, while professional services and partners are offered separately. Have your legal and procurement teams review the Apache-2.0 terms and any dependency licenses for your build, and confirm with Flowable which support tier you need.
How does Flowable handle clustering and timers across several nodes?
Flowable's async executor runs timers and asynchronous jobs from a thread pool and coordinates several nodes through lock owners and lock expiration times stored in the database. If a node stops, its expired locks are recovered and other nodes can pick up the jobs. Engineers should test this behavior under node failure, verify the database's time precision (MySQL versions below 5.6.4 lack millisecond precision), and size the connection pool and thread pool for peak load. Confirm the configuration against the Flowable advanced and configuration documentation for your chosen version.
How DeployOpen scopes an evaluation before a decision
The first step in any Camunda 8 versus Flowable evaluation is a fixed-scope discovery phase, and DeployOpen agrees its scope, deliverables and timelines in writing before work starts. DeployOpen plans, implements, integrates and documents self-hosted platforms inside the client's own cloud accounts, data centers or air-gapped networks. It is not a vendor partner, reseller or certified provider of Camunda or Flowable, so the discovery output is an independent view of what your processes need, not a sales path toward either product.
Discovery starts with a process inventory. List every BPMN model, DMN decision table and any CMMN case, and for each one record whether it is a long-running orchestration, a human task flow or a rules-only decision. Note which Java delegates, job workers, expressions and listeners each model calls, and whether any process depends on embedded engine behavior such as in-process transactions. Confirm which Camunda 8 components are in use (Zeebe, Operate, Tasklist, Identity, Optimize) and which are only planned, because each one maps to different replacement work in Flowable.
Next, review licensing with your legal counsel before any technical spike. Confirm which Camunda 8 Self-Managed edition your production use would require under the Camunda License v1, and whether a non-production license covers your test environments. For Flowable, confirm the Apache 2.0 terms of the engine modules you plan to use and whether you need any commercial Flowable product. Finally, scope a proof of concept against two or three of your most representative processes, with acceptance criteria written down in advance: model import, a failure and restart test, and an operations runbook your team can follow.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen plans, implements and supports self-hosted open-source process platforms inside your own cloud accounts, data centers or air-gapped networks. For a Camunda 8 vs Flowable decision, we start with a written scope that tests the BPMN, DMN and CMMN needs of your processes against each option before any build work begins.
How we scope
- Inventory the BPMN, DMN and CMMN models, job workers and custom Java delegates your processes depend on today.
- Document which running instances must finish in place and which can be restarted or migrated.
- Agree deliverables, timelines and responsibilities in writing; engagements are fixed-scope before work starts.
How we build
- Stand up a Flowable proof of concept embedded in or alongside your application, using your own models.
- Compare the embedded engine model with your current remote deployment on transactions and operations.
- Configure the chosen database, identity integration and async executor settings for your environment.
How we hand over
- Deliver architecture notes, runbooks, configuration records and the licensing position for each option in writing.
- Walk your platform, security and compliance teams through backup, upgrade and monitoring procedures.
- Document test results and open risks so your auditors or internal reviewers can trace each decision.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Plan version upgrades around release notes and your own regression tests before each change.
- Confirm support terms, response expectations and any vendor commercial support with your procurement team.
