Is Camunda 8 Cost Higher Than Self-Hosting Flowable for Our Workload?
If you are facing a Camunda 8 renewal or a license review, the license line disappears when you move to Flowable or Operaton, but infrastructure, migration, support and engineering effort remain, and those costs do not disappear with the license. Whether Camunda 8 costs more than self-hosting Flowable depends on your own numbers: how many production process instances and job workers you run, how many environments you maintain, which database you already operate, and how much in-house Java and Kubernetes skill you have. Start by separating the costs that recur from the costs that are one-time, and price each component on its own before you compare totals.
On the Camunda side, production use of Camunda 8 Self-Managed requires the Self-Managed Enterprise Edition, because from Camunda 8.6 the core components, including Zeebe, Operate, Tasklist, Identity and Optimize, are source-available under the Camunda License v1. Confirm with Camunda which subscription tier, deployment model and support terms apply to your volumes, and ask for the Self-Managed Enterprise terms in writing. On the open-source side, Flowable and Operaton are both licensed under Apache-2.0, so the engine itself carries no license fee. Flowable also sells commercial editions and professional services, and Operaton has no commercial editions, with professional support available from several independent providers. Neither is mandatory. Your decision is whether to buy support at all, and at what level, which is a separate line in your comparison.
For each option, build a table with rows for infrastructure, migration, support contracts, upgrades and internal engineering time, then ask each vendor or provider for a quote tied to the same written scope. Include the cost of running a database such as PostgreSQL or MySQL with the backup and recovery you require, the cost of upgrading Spring, Java or the engine on your own schedule, and the cost of testing against your own process models. The result is usually a range rather than a single figure, and the widest uncertainty tends to sit in engineering time, so state your assumptions clearly so that finance and architecture can challenge them.
Which cost components change when you move from Camunda 8 to Flowable
This table sets the Camunda 8 subscription and Self-Managed Enterprise costs beside the components you would carry running Flowable yourself, row by row. Read each row for who gets paid, whether the cost is one-time or recurring, and what drives it up or down. Flowable's commercial editions are a separate choice and are not assumed in any row.
| Cost component | Camunda 8 (SaaS or Self-Managed Enterprise) | Self-hosted Flowable (open source) |
|---|---|---|
| Subscription or license | Recurring Camunda subscription. Self-Managed production use requires the Enterprise Edition under the Camunda License v1 (Camunda licensing docs). Confirm terms in the quote. | No license fee for the Apache 2.0 engines. Recurring cost only if you buy Flowable commercial editions, which is a separate decision. |
| Infrastructure | SaaS: included in the subscription. Self-Managed: you run Kubernetes, Zeebe, Elasticsearch or OpenSearch for Operate and Tasklist, and storage. | One-time setup, then recurring compute and database hosting. Engines run embedded in Spring or Java apps, or as a REST service. Fewer moving parts than a Zeebe cluster. |
| Implementation and migration | One-time: BPMN model review, job worker rewrite to Zeebe clients, and integration work. Confirm the scope before starting. | One-time: engine embedding or REST setup, identity service wiring, and model and delegate porting. Migration cost depends on your current source system. |
| Production support | Recurring support tier included with the Enterprise subscription. Confirm response times and channels in writing. | Community forum for open source. Professional services and partners are separate, recurring or per-engagement contracts that you select and price. |
| Upgrades | Handled through Camunda release cycles. You plan and test each upgrade of the self-managed stack. | Recurring internal effort for Flowable version moves. Note the 8.0.0 change to Spring Boot 4 and Spring Framework 7, which has no backward compatibility for Spring Boot 3. |
| Internal skills | Teams need Zeebe, Kubernetes and Camunda operations knowledge. Training is typically a one-time cost. | Teams need Java, Spring and database operations skills, plus Flowable engine knowledge. Hiring or training is a one-time and recurring cost depending on turnover. |
| Testing and operations | Recurring: staging environments, load tests and monitoring of the self-managed cluster. | Recurring: test automation on the embedded engine, async executor monitoring and database backups. Plan these during the engagement. |
What the Camunda Enterprise license replaces and what it does not
From Camunda 8.6, the core components of Camunda 8 Self-Managed, including Zeebe, Operate, Tasklist, Identity and Optimize, are source-available under the Camunda License v1, and production use requires buying the Self-Managed Enterprise Edition. Camunda's licensing documentation places non-production use under the Camunda Self-Managed Non-Production license, so a development or test cluster does not need the production subscription. Before comparing quotes, confirm with Camunda which entitlement covers each environment, how many clusters your architecture needs, and whether support is bundled with the subscription or sold separately. The subscription line is the one cost a Camunda 8 quote makes explicit; it is not the whole annual figure.
Flowable's open-source engines for BPMN, CMMN and DMN are licensed under Apache 2.0, so the license line in a Flowable comparison is zero. That does not make the engines free to run. Your team pays for the people who install, configure, patch and monitor the engine, for the database (PostgreSQL, MySQL, Oracle, SQL Server, DB2 or others from the supported list), for the Java application servers or Kubernetes capacity that host it, and for the time spent on upgrades such as the move to Flowable 8.0.0, which required Spring Boot 4 and dropped Spring Boot 3. Those costs recur every year and tend to grow with the number of processes, environments and integrations.
Flowable also sells commercial editions, including Flowable Work, Engage, Orchestrate and Design, built on the same engines and adding low-code modeling, visual debugging, security controls, monitoring and governance. If your organization later needs those capabilities, a license cost can return even though the engine remains Apache 2.0. Ask Flowable which features are in the open-source distribution and which require a commercial edition, and put that boundary into the cost model from the start. Also check whether professional support would come from Flowable or from a partner, since the open-source page describes professional services and partners as separate offerings.
What moves the cost comparison most
Camunda 8 pricing and self-hosted Flowable costs both scale with load, data and team shape, but in different places. The six drivers below show where the comparison tips, and what to measure in your own environment before you ask for a quote.
Process instances and job throughput
Camunda 8 Self-Managed sizing depends on how many process instances run at once and how many jobs workers complete per second. Flowable embedded in your application spends that capacity on your own nodes and database, so the cost moves with application servers and database load. Measure peak instance starts, timer volume and job rates over a typical month, then ask Camunda and your integrator to size against those numbers.
Data volume and history retention
Retention of process history often drives storage and search costs more than runtime. In Camunda 8, history flows through exporters to a secondary store, while Flowable keeps history in the same relational database unless you configure otherwise. Write down how many years of audit history you must keep, which regulator or policy sets that period, and who owns the archive.
Environments and availability targets
Each extra environment, such as test, staging, performance and disaster recovery, adds infrastructure and licensing questions. Camunda Self-Managed production use requires an Enterprise subscription, and non-production use falls under a separate license. With Flowable, every environment is your own deployment, so cost depends on how many clusters you run and how the async executor is shared across nodes.
Existing Kubernetes and relational database skills
Camunda 8 Self-Managed runs on Kubernetes, so a team without a cluster platform pays for that platform before the workflow engine itself. Flowable runs as a JAR or service on hosts you already operate, with supported databases including PostgreSQL, MySQL, Oracle and SQL Server. Confirm which of these platforms and database licenses your organization already pays for, because those costs stay in both scenarios.
In-house Java and Spring capacity
Flowable's embedded model and Java delegates need engineers who maintain Java and Spring applications and upgrade them when framework versions change. Flowable 8.0.0 moved to Spring Framework 7 and Spring Boot 4 without backward compatibility for Spring Boot 3, so upgrades carry real engineering effort. Estimate the hours your team can give to upgrades each year, and compare that with the upgrade work included in an Enterprise subscription.
Commercial Flowable editions or independent support
Flowable's open-source engines are Apache 2.0 licensed, while its commercial products add low-code modeling, visual debugging, security controls and monitoring. Open-source users get a community forum, and professional services come separately. Decide whether you need a vendor contract, an independent integrator or your own team to cover production incidents, then ask each supplier for response terms in writing.
How to build the comparison with your own numbers
This sequence turns a vague sense that Camunda 8 costs too much into a side-by-side model built from your invoices, your usage and your own infrastructure rates, so both options are priced over the same horizon and scope.
Inventory every Camunda 8 invoice line and contract term
Collect the current Camunda 8 order form or subscription agreement, every invoice from the last twelve months, and any amendments. List each line item separately: platform or SaaS subscription, Self-Managed Enterprise license, support tier, add-ons, overage charges, and any committed-spend or renewal terms. Note the billing unit for each line, the renewal date and the notice period. Ask your Camunda account contact to confirm in writing which items are recurring and which are one-time. The step is done when every line has an owner, a billing unit and a renewal date in one table.
Map current usage across instances, workers and environments
Gather the figures that drive your Camunda 8 bill and that will drive your self-hosted sizing: process instances started per period, peak concurrent running instances, job workers and their deployment footprint, number of environments (development, test, staging, production), and how long history is retained in Operate and Optimize. Pull these from your Camunda console or monitoring where available, and from your own application teams where they are not. The step is done when you have a usage sheet that a platform engineer and a finance owner both accept as accurate.
Price the self-hosted stack from your own rates
Build a cost model for Flowable or Operaton using the cloud account or data center rates your organization already pays. Cover compute for the engine nodes and workers, the relational database that Flowable and Operaton support (such as PostgreSQL, MySQL, MariaDB, Oracle, SQL Server or DB2), storage and backups, load balancing, monitoring, and a separate pool for non-production environments. Keep the software line at zero for the Apache-2.0 engines, and add any commercial support contract you choose to buy as its own line. The step is done when each infrastructure component has a unit rate, a quantity and a monthly or annual total traceable to a source invoice or rate card.
Estimate migration and testing effort from a written scope
Define the migration scope in writing before estimating effort: which BPMN and DMN models move, which job workers or Zeebe clients are replaced with Flowable service tasks or external workers, which user tasks need a replacement task list, and how running instances are handled. Ask each candidate partner, including DeployOpen where relevant, to estimate effort against that same written scope. Include regression testing, performance testing, security review and cutover rehearsal. Record these as one-time costs with named owners. The step is done when the migration estimate lists each work package with an effort figure and an assumption behind it.
Add recurring support, upgrade and engineering effort
Model the costs that repeat for each option. For Camunda 8, this is the subscription and any support tier. For a self-hosted engine, include the engineers who patch and upgrade the engine, operate the database and cluster, respond to incidents and maintain custom code, as well as any paid support contract. Note that Flowable publishes major releases with framework changes (its 8.0.0 release moved to Spring Boot 4 without Spring Boot 3 compatibility), and that Operaton ships half-yearly feature releases with monthly patches and six-month support per version, so upgrade effort should be scheduled, not assumed. Ask your support providers to state the recurring scope and the response commitments they will sign. The step is done when recurring costs are listed per year with the people or contracts behind them.
Compare both options over one fixed horizon
Choose a fixed comparison horizon, such as three or five years, and apply it to both options. Separate one-time costs (migration, testing, cutover, training) from recurring costs (subscription or infrastructure, support, upgrades, engineering time). Show the totals per year and cumulative, and mark the assumptions that move the result most, such as instance volume, retention period or support tier. Run a sensitivity check with higher and lower usage. The step is done when both options show the same horizon, the same usage baseline and a list of open assumptions for the decision owner.
Request written quotes on the same scope
Send the same written scope document to Camunda and to every support or implementation provider you are considering, and ask each to quote against it. Ask Camunda to confirm in writing the Self-Managed Enterprise pricing basis, the SaaS pricing basis, what support is included, renewal and price-change terms, and how license terms apply to your production and non-production environments. Ask Flowable or Operaton support providers to state scope, deliverables, response commitments and exclusions. Compare the returned quotes against your model and update it. The step is done when every quote is in writing, against one scope, and the model has been reconciled with each.
Where one-time migration costs land and how long they run
The one-time cost of moving from Camunda 8 to Flowable sits in four places: converting BPMN and DMN models, replacing Zeebe job workers, replacing the Operate and Tasklist views, and rewriting Camunda-specific API calls. Model conversion is usually the smallest item, because BPMN 2.0 files are standard XML, but each diagram still needs a check against Flowable's supported elements, expressions and DMN behavior. Zeebe job workers are the larger item. Each worker that polls for jobs needs a decision: rebuild it as a Flowable service task inside an embedded application, or keep it as an external worker that calls the Flowable REST API. That choice changes the architecture, the transaction boundaries and the test effort, so it should be settled before any estimate is accepted.
Visibility is the item most often underestimated. Operate and Tasklist are part of the Camunda 8 Self-Managed stack, so when they go, the replacement must cover monitoring of running instances, incident handling, user task inboxes and reporting. Flowable's commercial products add visual tooling, while the open-source path usually means building or configuring these views on top of the engine's APIs and the actuator endpoint at /actuator/flowable. The API rewrite covers the client code that calls Zeebe gRPC or REST, plus identity, authorization and secret handling that Camunda 8 provides through Identity. Each of these needs an owner in the client's team.
Two questions shape the schedule more than anything else: how many models and workers are in scope, and what to do with instances that are already running. Finishing in-flight instances on Camunda 8 and starting new ones on Flowable keeps the migration simpler but requires two platforms to run in parallel for as long as the longest instance lasts. Moving running instances requires a state mapping that the team must design and test. Durations depend on scope, so ask any partner for a fixed-scope plan that lists every model, worker, view and API client, with deliverables and acceptance tests written out, rather than accepting a generic estimate. Ask the partner to state its assumptions about in-flight instances explicitly.
Support windows and upgrade effort in the long run
The recurring cost of a self-hosted engine is not the license but the upgrade calendar, so plan for it before you choose. Flowable 8.0.0 was released on February 27, 2026, following 7.2.0 on August 21, 2025, and 7.1.0 on October 7, 2024, according to the Flowable engine releases page. Its release notes show that a major version can change the framework baseline: 8.0.0 moves to Spring Framework 7 and Spring Boot 4, drops support for Spring Boot 3, makes Jackson 3 the default JSON library, and removes JUnit 3 and 4 support. Your team should estimate the work for each major line in its own codebase, including custom Java delegates, test suites and any Spring Boot starters you depend on, and confirm with Flowable which support window applies to the version you pick.
Operaton works on a different rhythm. According to its FAQ, it ships feature releases in April and October with monthly patch releases, and each major or minor version is supported for 6 months until the next one ships. There is no traditional LTS line, so a team that stays current will upgrade roughly twice a year, and a team that falls behind loses vendor-free security patches. Operaton v2.1.0 was published on April 24, 2026, and the latest stable patch, v2.1.5, on September 18, 2026. Ask whether your target database versions and Java runtime, currently Java 17 in the 2.1 release notes, match your platform roadmap, and budget engineering time as a recurring line rather than a one-off project.
A commercial subscription typically bundles vendor support, security fixes and version maintenance into one fee, and that bundle is part of what you pay for. With a self-hosted engine, those duties move to your team or to a support contractor you hire, and a quote for managed upgrades should state what is covered: patch cadence, major-version migrations, testing against your database and JVM, and response times for production incidents. Ask any provider, including DeployOpen, to put those obligations in the written scope so that the recurring cost is visible next to the subscription figure in your comparison.
Questions buyers ask before comparing Camunda 8 and Flowable costs
Does self-hosting Flowable always cost less than Camunda 8?
No. Self-hosting removes the subscription line, but it moves the cost to infrastructure, your engineers and support contracts. Flowable's open-source engines are Apache-2.0 licensed, so there is no license fee for the engine itself. Camunda 8 Self-Managed in production requires the Self-Managed Enterprise Edition, and Camunda 8 SaaS is a subscription that bundles hosting and operation. The cheaper option depends on how many engineers you can dedicate to running the platform, how many processes and instances you run, and how much uptime and vendor response you need. Build a three-year total cost of ownership for each option, with each component listed separately, before deciding.
How much engineering effort does an in-house Flowable team need?
The effort depends on the drivers, not on a fixed number. The main ones are the number of process models and integrations, the database you choose (Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server), how many nodes you run, and whether you embed the engine in applications or run it as a service through its REST APIs. Ongoing work includes upgrades, such as the move to Spring Boot 4 and Spring Framework 7 in Flowable 8.0.0, monitoring, backups, identity integration and tuning the async executor. Ask your team to size each of these against your own environment and to name who owns each one on call.
Can a Camunda 7 team use Operaton instead of Flowable to control cost?
Often yes, and it can reduce migration work. Operaton is an Apache-2.0 BPMN 2.0 engine born from the Camunda 7 codebase. Its repository describes a fully compatible REST API, database schema and deployable BPMN and DMN models, and it offers an OpenRewrite recipe for migrating from Camunda 7. Operaton 2.1 is feature complete and API-compatible with Camunda 7 CE 7.24 and requires Java 17. Flowable is a different engine with its own APIs, so moving to it usually needs more rework of Camunda APIs and plugins. Confirm compatibility for your own delegates, listeners and custom code with a proof of concept before comparing costs.
What support options exist for Flowable and Operaton?
Both are open source, so support is bought separately from the software. For Flowable, the open-source page describes a community forum for open source users, with professional services and partners offered separately, and commercial editions such as Flowable Work, Engage, Orchestrate and Design built on the same engines. For Operaton, its repository states it has no open-core model and no commercial editions, and professional support is available from several independent service providers. Operaton's FAQ notes that it ships feature releases in April and October with monthly patches, each supported for 6 months until the next version ships, with no traditional LTS line. Ask any provider for its response commitments in writing.
What does the migration work need from our team?
It needs a named owner for the process models, a team that understands your integrations, and a plan for running instances. Start by inventorying BPMN and DMN models, Java delegates, job workers, custom scripts, database access and identity sources. Then decide how in-flight instances finish, move or migrate, since running instances rarely move without a dedicated migration. Your team must also own the target platform after go-live, including upgrades, backups and security patching. Camunda's Data Migrator, which is documented for moving running Camunda 7 instances to Camunda 8, is a different path, so confirm which tooling applies to your starting version before scoping.
Can our own team do the Flowable or Operaton migration without outside help?
Some teams can, particularly where the process estate is small, the engineers already know Java and Spring, and the team has run production databases before. Others need outside help for model conversion, performance testing, hardening or upgrade planning. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure, typically under a fixed-scope agreement with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, and a quote follows from the written scope. Use a short assessment to decide which parts your team can own.
How DeployOpen scopes a fixed-price Flowable or Operaton implementation
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Camunda 8 cost comparison, we start from a written scope that separates licence spend from infrastructure, migration, support and engineering effort, so you compare like with like before you commit.
How we scope
- Inventory the live Camunda 8 footprint: process models, job workers, connectors, Tasklist and Operate usage, and integrations
- Agree which engine (Flowable or Operaton), database and deployment model the written scope covers
- Record the in-flight instance strategy and which running processes must finish before cutover
- Confirm the support, upgrade and retainer terms you want included, since engagements are fixed-scope and quoted from that scope
How we build
- Set up the chosen engine in your environment with the database type you have standardized on
- Rework Zeebe workers and Camunda-specific expressions into Flowable or Operaton service tasks and delegates
- Connect identity, monitoring and the async executor so that clustered nodes behave correctly under load
- Test each migrated process end to end and document the results against the agreed scope
How we hand over
- Deliver runbooks for deployment, upgrades, backup and restore, and database maintenance
- Provide architecture and configuration documentation that your platform and security teams can review
- Walk your engineers through operating the engine and the release cadence you will follow
- Hand over a list of open items, including any step that depends on a decision only your organization can make
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope work closes
- Plan version upgrades around the release cadence of the engine you select, and agree who applies each patch
- Keep the cost model current by reviewing infrastructure, licence and engineering effort each period with you
