Flowable cost of ownership: what the free engine still costs you
The Flowable engines for BPMN, CMMN and DMN are licensed under Apache 2.0, so there is no license fee to pay for the open source code. That does not make the platform free to own. Development, hosting, the user interface, upgrades and support all carry cost, and most of that cost lands on your own budget and staff. A cost of ownership assessment exists to make those costs visible before a decision is made, not after the first production release.
Teams usually start this assessment for one of three reasons. The first is a choice between the open source engines and a commercial Flowable edition, such as Flowable Work, Orchestrate or Design, which add low-code modeling, visual debugging, security controls, monitoring and governance on top of the same engines. The second is a budget request, where finance wants a multi-year view of what the open source route will cost compared with a licensed product. The third is a planned move away from another engine, such as Camunda 7 or Activiti, where the migration effort and the ongoing run cost both need to be compared. In each case, the question is not whether the engine is free but what your organization must build, pay for and maintain around it.
Most teams model this in-house first, because the cost components are visible to the people who already run the Java stack: engineers who build delegates and integrations, the database team that hosts the schema, and the platform group that operates the nodes. Partners are often brought in to check the assumptions, scope the parts that are unfamiliar, such as the user task interface that the open source distribution no longer provides, or to produce a written estimate. Either route should end with a written list of cost components, each assigned to a role, so the figure can be challenged line by line.
Before you build the model, confirm which Flowable version and baseline you plan to run. Flowable 8.0.0, released on February 27, 2026, moved to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3, and made Jackson 3 the default JSON library. Those changes affect how much upgrade and regression work you should expect in the next few years. Ask your own engineers to estimate the effort for your current stack, and ask any partner to state the assumptions behind their figures.
What a Flowable cost of ownership assessment includes
A written cost model turns Flowable's open source licensing into a full ownership picture. Each deliverable below covers one part of that picture, from the components you run to the decisions that remain yours after the assessment ends.
Component inventory
The model lists every running part of the platform: the BPMN, CMMN and DMN engines, the event registry, the REST application or the embedded JAR in your own services, the relational database, the identity source, and the messaging layer if events flow through a broker. Each item gets an owner, a hosting location and a note on who patches it. Check that the inventory matches how your architecture actually runs Flowable, because a REST deployment and an embedded deployment carry different effort.
One-time versus recurring split
Costs are separated into what you pay once, such as modeling, service integrations, custom task interfaces and testing, and what recurs, such as infrastructure, database operations, engine upgrades, regression testing and support. Ask for each line to name who is paid, whether that is your staff, a contractor or a vendor. A split that shows only a total hides the recurring share that usually determines long-term cost.
Edition comparison
The model compares the Apache 2.0 engines with Flowable's commercial products, which are built on the same engines and add low-code modeling, visual debugging, security controls, monitoring and governance. For each capability you need, record whether your team would build it, buy it, or do without it. Confirm current commercial product scope and terms directly with Flowable, since the assessment should not assume feature parity or pricing.
Assumptions register with owners
Every estimate rests on assumptions, such as the number of process models, expected transaction volume, the Java and Spring versions your standards allow, and whether task UIs are built in-house. Each assumption is written down with a named owner and the date it was last confirmed. When an assumption changes, the owner can see which cost lines move with it, which keeps the model useful after the first budget cycle.
Outputs and remaining decisions
At the end you receive the written model, the inventory, the cost split, the edition comparison and the assumptions register. Some decisions stay with you: which edition to adopt, whether to build or buy, which team carries long-term ownership, and how much support coverage to fund. DeployOpen works from a written scope and does not publish a price list, so the model's cost figures come from a quote tied to the scope you agree in writing.
What pushes Flowable cost of ownership up or down
This table lists the factors that most change what a self-hosted Flowable setup costs to build and run. Read each row for why the driver moves effort and one practical way to keep it in check. The engines are Apache 2.0 licensed, so the cost sits in effort and in any commercial edition chosen, and that effort varies with the drivers below.
| Driver | Why it moves cost | How to keep it down |
|---|---|---|
| Number of process, case and DMN models | More models mean more modeling, Java delegates, regression tests and change control for each release. | Standardize naming, reuse subprocesses and decision tables, and automate model tests in the build pipeline. |
| Deployment style | Embedding in Spring Boot, a servlet container or running the REST application each carries different packaging and operations work. | Choose one style per estate and use the official starters where the stack already runs Spring Boot 4.x. |
| Database type | Schema setup, drivers, database licensing and DBA skills differ by engine. MySQL below 5.6.4 lacks millisecond precision. | Use the database your organization already operates, and confirm version support in the configuration docs before build. |
| Nodes and async executor | Multiple nodes need a shared database, lock settings, monitoring of timers and jobs, and load testing. | Start with the node count you need, and test expired lock recovery before adding nodes. |
| Identity source | Replacing IdmIdentityService or building a custom directory link is code that must match your user and group model. | Start from the documented LDAP reference implementation where it fits, and keep custom identity code in one module. |
| Integrations and event channels | Each system adapter, broker connection and event registry channel adds build, security review and failure handling. | Prioritize integrations by business value, reuse one adapter pattern, and agree message contracts with each system owner. |
| Need for a task UI | The open source UI applications were removed in version 7, so any user interface must be built, hosted and maintained by your team or a partner. | Decide early whether tasks appear in existing applications, and reuse your current front-end standards and components. |
| Compliance evidence | Assessors look for access control, change, backup and audit records that the team must produce and keep current. | Define evidence needs before build, generate configuration and deployment records automatically, and assign control owners. |
| Edition choice | Open source users rely on a community forum, while commercial products add modeling, debugging, security controls and monitoring, each quoted separately. | List the features you need, weigh them against in-house effort, and request a written quote for each option. |
Apache 2.0 engines or Flowable's commercial products
Flowable's open source engines are licensed under Apache 2.0 and provide BPMN process execution, CMMN case management and DMN decision rules, with Java and REST APIs. The engine carries no license fee, so the cost sits in the work around it: building the application layer, hosting the platform, and supporting it after go-live.
- Engines and APIs: BPMN, CMMN and DMN engines, with Java APIs and the REST application available for integration.
- Deployment options: the engines can be embedded as a JAR in Java SE applications, servlet containers, Spring applications or Java EE servers, or run as the REST application over HTTP.
- Support channel: a community forum for questions. It is a public forum, not a contracted support agreement.
- Separately sourced services: professional services and partners are sold separately, so implementation, training and support appear as additional line items.
- Internal build effort: your team builds and maintains the custom task UI, identity wiring and operational tooling, because the open source UI applications were removed in version 7.0.0.
Before you compare totals, confirm which release line your team will adopt, and list every component you must staff or buy from a partner.
Flowable's commercial products, including Flowable Work, Engage, Orchestrate and Design, are built on the same BPMN, CMMN and DMN engines as the open source distribution. They add low-code modeling, visual debugging, security controls, monitoring and governance on top of those engines.
- Same engine layer: process and case execution runs on the same engines, so the Java and REST skills your developers build apply to either route.
- Low-code modeling: product tooling lets business analysts and process owners work on models with less developer involvement than hand-coded changes.
- Visual debugging: visual tools help teams trace running instances, which the open source route covers only through what you build yourself.
- Security controls and governance: product-level controls for access and oversight. Confirm their exact scope in the product documentation.
- Monitoring: product-level monitoring, which you should compare with what the open source Spring Boot actuator endpoint and your own monitoring already provide.
Ask Flowable which products and features are included in each offering and which are add-ons, and get that list in writing.
This page does not state prices, license terms or the feature split between Flowable's editions, so the comparison needs current figures from Flowable. Cost depends on who pays for each component and whether that component recurs, so separate one-time work from ongoing items before you request a quote.
- Licensing: ask which products are licensed, on what basis, and what renewal terms apply.
- Included features: ask for the feature list of each product, and match it against your requirements.
- Support scope: ask what support covers after go-live, what response expectations apply, and whether upgrades are included.
- Open source effort: estimate developer, infrastructure, UI build and support effort for the open source route, then compare it with the commercial scope.
- Version support: the 8.0.0 release, published on February 27, 2026, moved to Spring Boot 4, so confirm which versions each edition supports.
Put each cost component in one comparison sheet, mark which items recur, and request a written quote that names the exact products and versions.
Recurring Flowable cost of ownership after go-live
The Flowable engines are licensed under Apache 2.0, so the recurring cost of an open source setup is not a license fee. It is the set of people and infrastructure that keep the engines running, changing and current after go-live. Before you compare this with a commercial product such as Flowable Work or Orchestrate, list these recurring lines in your own budget: hosting and database operations, developer time, upgrades, monitoring, a task interface and support. Each one has an owner, and an owner who is not named usually means the cost lands on whoever notices the outage first.
Hosting and database operations are the first line. The engines run inside your application or as the Flowable REST application, and they keep process state, history and job locks in a relational database. Confirm which of the supported database types you have chosen (H2, MySQL, Oracle, PostgreSQL, DB2 or Microsoft SQL Server), who patches and backs up that database, and what the job executor's lock behavior means for a multi-node cluster. Ask whether your team or a partner will own backups, restore tests and capacity reviews, because those tasks recur every month rather than once.
Developer time recurs in two places. Business process models change as policies change, and every BPMN, CMMN or DMN change usually touches a Java delegate, an expression or a service integration that must be tested again. Monitoring is the second place. The Spring Boot starters expose an actuator endpoint at /actuator/flowable for running processes, so decide who reads that data, which alerts are wired to it, and who responds when running instances stall. Put both into your run budget as named hours per month, not as a general allowance.
Upgrades are the largest recurring risk. Flowable 7.0.0 moved to Java 17, Spring Boot 3 and Jakarta EE, and Flowable 8.0.0 moved to Spring Framework 7 and Spring Boot 4, with no backward compatibility for Spring Boot 3, Jackson 3 as the default JSON library and removal of JUnit 3 and 4 support. Plan who tests each release, how long your regression suite takes to run, and whether your Java, database and framework baselines are still supported. Also account for the 7.0.0 change that removed the UI applications, which means a task interface is now a build and maintenance item for your team.
Finally, decide how you will get support. Options include internal skills that you build and keep, a retainer with a partner for upgrades and incident response, or vendor professional services that Flowable offers separately from its community forum. For each option, ask for a written quote that separates one-time work (initial build, task UI build, migration) from recurring work (monthly run, patch cycles, upgrade windows), and ask what happens to the price when a major version arrives. Ask the vendor or partner to confirm which versions their support covers before you sign.
How the cost of ownership assessment runs
The assessment works through six phases in sequence, and each phase closes with a written output the buyer can check, so the final model reflects their own processes, architecture and staffing rather than a generic estimate. The length depends on the number of process models and integrations and is set in the written scope.
Inventory current or planned process and case assets
We list the processes, case models, decision tables and integrations the Flowable setup must cover, whether they already run on another engine or are still planned. Each item is tagged as BPMN, CMMN or DMN, with its owning team, its main system dependencies and its expected change rate. Your process owners and architects confirm the list. Done means a signed inventory that sets the boundary of the model, with anything out of scope named explicitly.
Choose the architecture and deployment model
We compare the two supported patterns: embedding the engines as a JAR in a Java application, including Spring Boot, or running the Flowable REST application and calling it over HTTP. For each process group we record the trade-offs for release coupling, team ownership, scaling and the database you already operate, and we note which database types from the supported list fit your standards. Your platform team confirms the choice. Done means a written deployment decision per process group, with the reasons recorded.
Compare editions and licensing options
We set the Apache 2.0 open source engines beside Flowable's commercial products, which are built on the same engines and add low-code modeling, visual debugging, security controls, monitoring and governance. For each capability your inventory needs, we record whether the open source build covers it, whether a commercial product would be needed, or whether custom work fills the gap. Procurement and legal review the license terms and confirm current commercial pricing with Flowable. Done means a capability matrix showing which option covers which requirement.
Model effort by role
We estimate the work for each role the setup depends on: developers who write delegates, service tasks and integrations; platform operators who run databases, nodes and the async executor; UI builders, who must now supply their own task interface because the open source UI applications were removed in version 7; and support staff who handle incidents after go-live. Each role gets hours per activity, with the assumptions written down. Your leads check the assumptions against their staffing. Done means a role-by-activity effort table that you can challenge line by line.
Build the recurring cost model and upgrade cadence
We separate one-time costs (design, build, migration, testing) from recurring ones (platform operation, dependency updates, release upgrades, regression testing of process models and support). The upgrade cadence follows the Flowable release history, and the model notes that the move to version 8.0.0 changed the Spring and Jackson baselines, which affects how much regression work each upgrade carries. Done means a year-by-year cost structure with each recurring line tied to a named role and trigger.
Hand over the written cost of ownership model
We deliver the model as a written document with the inventory, architecture decision, edition comparison, effort tables, recurring cost structure and open assumptions. We walk your architects, finance and procurement through it, and we list the items to confirm with Flowable and with your own environment before a decision. Done means your team can rerun the model with its own rates and see what changes when the process count, integrations or upgrade cadence changes.
Which cost lines teams keep in-house and which they outsource
This table compares who usually owns each Flowable cost line when a team runs the open source engines, and which skills each line needs. Read the middle column for the skills and the right column for where most teams draw the line between internal work and a partner. The main takeaway is that the engine license is free, so the recurring cost sits mostly in people who can keep the engines current.
| Cost line | Skills needed and who usually holds them | Usually kept in-house or outsourced |
|---|---|---|
| Architecture decisions | Java and Spring architecture, identity engineering and security review. Usually held by the internal platform or architecture team. | Keep in-house. Partners can review options, but the team must own the long-term design. |
| Engine selection between BPMN, CMMN and DMN | BPMN modeling and CMMN case modeling. Usually held by process owners with an engineering lead, and CMMN skills are scarcer. | Split. A partner can run the first scoping workshop, then the team confirms the engine for each process. |
| Effort modeling | FinOps-style cost modeling and delivery planning. Usually held by engineering managers or a PMO, and sometimes by a partner's scoping lead. | Either. A fixed-scope quote moves planning to the partner, but internal owners must check the assumptions. |
| Infrastructure sizing | Database administration, container or VM operations and load modeling for the async executor. Usually held by the infrastructure team. | Keep in-house, with partner input during design. Sizing depends on your own cloud accounts or data centers. |
| UI build | Frontend engineering and UX for task lists and forms, since the open source UI applications were removed in version 7.0.0. Usually held by application teams. | Often outsourced for the first build, then owned internally. Confirm the scope before requesting a quote. |
| Upgrade planning | Spring Boot, Jackson and database schema skills, plus regression testing of process models. Usually held by the team that owns the application. | Good candidate for a retainer. Major jumps, such as to 8.0.0 with Spring Boot 4, often benefit from partner review. |
| Ongoing support | Incident response, async job monitoring, security patching and on-call coverage. Usually held by the internal operations team. | Often split. Partners offer retainers, while the team keeps first-line response and ownership of its data. |
How the cost picture changes by starting point
Moving from a commercial BPM suite usually changes the largest recurring line. The engine license fee falls away under Apache 2.0, but work that the suite vendor bundled into the license now has to be paid for in build and support effort. The cost moves from the vendor invoice to your team's time or your partner's fixed-scope fee.
- License and maintenance: Flowable's open source engines have no license fee. Check whether your current contract includes modeling tools, support or hosting that you will need to replace.
- Modeling and task UI: The open source UI applications were removed in version 7. Budget for task lists, administration screens and monitoring views, or evaluate Flowable's commercial products for those needs.
- Porting effort: Converting process models, delegates and integrations is a one-time cost. Ask for an estimate per process family so you can see which models are simple and which need redesign.
- Support model: Community forum support is available to open source users. Professional services and partner support are offered separately, so ask which response commitments a quote includes.
Compare three years of current suite license, maintenance and administration costs against the open source build, hosting and support lines, using the same process scope for both.
Teams moving from Camunda 7 or Activiti already run a BPMN engine, so the recurring costs often stay close to current levels. The main new cost is the migration itself, which is a one-time expense. Flowable's engineering guidance describes in-place migration of data, including active process instances and history, and offers the free LEAP tool to report ahead of time what a migration involves. That report is the input that makes the migration estimate reliable.
- Migration effort: The size of the one-time cost depends on the number of running instances, the history you must keep and the number of BPMN XML extension changes. Read the Camunda 7 to Flowable migration topic for the steps and checks behind these drivers.
- Delegate rework: Java delegates and listeners may need changes to match the Flowable APIs. Ask the quote to show which classes change and which ones move unchanged.
- Testing on a database copy: Test environments and a database copy are a cost line in their own right. Confirm who provisions them and who pays for the test cycles.
- Cutover planning: Cutover coordination, in-flight instance handling and rollback steps are planned work that carries a fee. Ask whether the quote includes a rollback rehearsal.
- Ongoing run cost: Once migrated, the recurring costs look like any other open source engine, so the change is largely in the one-time line.
Check the LEAP report output against your own process inventory before you accept any fixed-scope price.
A new build on Spring Boot concentrates cost in two places: modeling the processes and writing the delegates that connect them to your systems. There is no existing suite or legacy engine to retire, so the budget starts with the work that defines your process behavior. Flowable's Spring Boot starters cover the BPMN, CMMN and DMN engines and the REST application, which shortens the setup work but not the modeling work.
- Process and case modeling: Analysts and engineers must agree on each model, including decision tables and case stages. This is the largest single effort line for most new builds.
- Delegates and integrations: Service tasks, event handling and identity mapping consume developer time. Ask for the number of integration points included in the scope.
- Database and async executor: Choose a supported database and plan its backup and sizing. Confirm how the async executor is configured for timers and jobs.
- Framework version: Flowable 8.0.0 requires Spring Boot 4 and Jackson 3, so the upgrade path from earlier Spring Boot versions carries its own effort. Ask which framework baseline the quote assumes.
- Testing: Process tests and regression checks for each model are recurring work once the models change.
Ask the quote to show modeling, delegate and integration effort as separate lines so you can see which part changes if the scope grows.
An air-gapped or self-managed Kubernetes estate shifts cost from the engine to the platform around it. The engine license is still zero, but your team carries the work that a connected cloud service would otherwise handle, including image delivery, patching, backups and monitoring. These lines recur every year, so they usually matter more to the total than the one-time build.
- Offline dependency delivery: Packages, container images and database drivers must be mirrored into the network and updated through an approved route. Confirm who runs that pipeline and how often it runs.
- Database high availability: Shared databases, backups and restore tests are required for the engine nodes to recover. Ask whether the quote includes restore testing.
- Platform operations: Kubernetes clusters, ingress, secrets and node upgrades need a platform team. Ask how the quote separates Flowable work from the platform work.
- Monitoring: The Spring Boot starters expose an actuator endpoint at /actuator/flowable for running processes. Confirm which metrics your monitoring stack collects and who responds to alerts.
- Security updates: Dependency updates for Spring and Jackson must pass through the offline pipeline before they reach production. Budget for that cycle every time a release ships.
Ask for the recurring platform operations cost as a separate line item, because it is the figure most likely to differ between the quote and your actual running cost.
Where open source cost estimates usually go wrong
Flowable's open source engines have no license fee, which makes the estimate easy to start and easy to get wrong. The errors below recur across Flowable projects, from the UI build after version 7.0.0 to the support gap after go-live. Each card names the error and the check that prevents it.
Zero license fee as zero cost
Flowable's engines are licensed under Apache 2.0, so the engine itself carries no license fee. The total cost still includes developers, hosting, database operations, testing and any support contract, and most of these recur for the life of the platform. Prevention: build a cost model with one line for each labor and infrastructure component, and ask any partner to price those lines in writing.
UI build after version 7.0.0
Version 7.0.0 removed the open source UI applications, so teams that expected a ready-made task inbox or admin console must build their own front end or license a commercial product. The UI build is a separate item covering task forms, authentication, screens and testing against the REST API. Prevention: list every screen the processes need before estimating, and confirm which of them the commercial products would cover.
Upgrade effort for version 8.0.0
Version 8.0.0 moved to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3. It also made Jackson 3 the default JSON library, with a Jackson 2 compatibility layer, and removed JUnit 3 and 4 support. Teams on Spring Boot 3 face a framework migration that touches application code, tests and process models, so it needs its own work item. Prevention: inventory the Spring Boot, Jackson and JUnit versions in each application and schedule the baseline change with regression testing.
Database and async executor operations
Each node in a clustered deployment shares one database, and the async executor coordinates timers and asynchronous jobs through lock owners and lock expiration times stored there. Costs appear in database sizing, backup and failover, monitoring of locks and jobs, and the time needed to prove that another node recovers expired locks. Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server, so the database choice also sets the operations skills required. Prevention: choose the database with the operations team before estimating, and test a node failure during timer and job execution in staging.
Compliance evidence and audit history
Regulated teams need evidence of who changed a process, who acted on each task and when, and that evidence must be retained and exportable for assessment. Flowable's audit history and surrounding logging must be configured, stored and reviewed, and no license line covers that effort. Cost includes control mapping, retention settings, log storage and walkthroughs with the auditor. DeployOpen prepares systems and evidence for assessment, but independent auditors issue the findings and any certification. Prevention: ask the compliance lead to list the evidence each assessment requires, then confirm which history and log settings produce it.
Support assumed from the forum
Open source users get access to a community forum, while professional services and partner support are offered separately. A forum gives no contractual response time and no one accountable for a production defect, and it does not cover upgrades, security patches or out-of-hours incidents. Budget for a support arrangement with written terms, or staff the expertise in-house and name the owner. Prevention: decide which incidents your team handles, define the response you need, and get support scope and response terms in writing before go-live.
What to gather before you ask for a Flowable cost model
The most useful thing you can bring to a Flowable cost conversation is a written inventory of what you intend to run on the engines. Start with the process and decision inventory: for each candidate workflow, note whether it is a BPMN process, a CMMN case or a DMN decision table, roughly how many models you expect, and which ones are already modeled in Camunda 7, Activiti or a spreadsheet. The count and type of models drive most of the modeling, testing and custom delegate effort, and that is where the open source route spends its money. You can assemble this list internally with your business process owners in a few sessions. Ask for the list to be ranked by business value so the first scope is small and defensible.
Next, record the target deployment shape. Decide whether the engines will be embedded in your Spring Boot or other Java applications, or whether teams will call the Flowable REST application over HTTP. The Flowable getting started and Spring Boot documentation describe these as different paths with different build, security and operations work, so a cost model needs to know which one applies to each process. Also capture your database and hosting standards. Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server, so state which of these your database team already operates, whether it is managed or self-run, and what backup and failover rules apply. Your platform team can answer this internally. Confirm the MySQL version if it is in play, since the configuration docs flag versions below 5.6.4 for missing millisecond precision.
Third, document the identity source, integrations and volumes. Name the identity provider and whether group membership will map to candidate users and tasks, because replacing the IDM identity service is a discrete build item. List the systems each process must call and any event brokers in use, since event registry channels add integration scope. Describe expected user counts and process volumes in general terms, such as peak concurrent users or whether timers run at high frequency. A workshop with your platform and integration architects is the right setting for the identity and broker questions, because the answers depend on design decisions rather than facts you can look up.
Fourth, settle the edition questions and compliance obligations. Ask your business sponsor whether you need the low-code modeling, visual debugging, security controls, monitoring or governance features that Flowable's commercial products add, or whether community support and internal tooling will do. Record any regulatory controls that apply to audit history, data retention or access to the engine, and say which assessor will review them. DeployOpen does not issue attestations, so the evidence you need should be named in the scope. Finally, name an accountable owner in finance, in platform engineering and in business process. Each owner should sign off on their part of the inventory, because a quote that lacks a decision owner tends to stall at the first change request.
Once these inputs exist, separate what you can answer internally from what needs a workshop. Internally you can usually settle the process inventory, the database standard, the hosting model and the named owners. A workshop is better for the embedding versus REST decision, identity mapping, broker integration design and edition trade-offs, because those choices interact with your architecture. Bring the written inventory, the platform standards document and the list of owners to that session. The result is a scope that can be priced from written assumptions rather than a rough estimate.
Questions buyers ask about Flowable cost and editions
Does Flowable open source have a license fee?
No license fee applies to the engines themselves. The Flowable BPMN, CMMN and DMN engines are licensed under Apache 2.0, so you can use and deploy them without paying Flowable a license fee for the engine code. Your cost comes from people, infrastructure and any products or services you add.
What you still pay for:
- Developers to embed the engine and build Java delegates and integrations
- Modelers to build and maintain process, case and decision models
- Database and hosting in your own cloud or data center
- A custom task UI, because the open source UI applications were removed in version 7.0.0
- Testing, upgrades and any support contract you choose
Have your legal team review the Apache 2.0 obligations for your distribution model, such as license notices.
What does a commercial Flowable edition add over open source?
Commercial products add tooling and governance on top of the same engines. According to Flowable's open source page, Flowable Work, Engage, Orchestrate and Design are built on the same engines and add low-code modeling, visual debugging, security controls, monitoring and governance.
Open source users get access to a community forum. Professional services and partners are offered separately.
Ask Flowable directly which product covers the features you need, how it is licensed, whether fees recur, and what support is included. Product packaging changes over time, so confirm the current lineup and terms with Flowable before you compare costs.
What drives the cost of running Flowable yourself?
Staff time is usually the largest variable cost, and it grows with the number of processes and integrations you build.
One-time costs:
- Engine setup, such as Spring Boot starters or a servlet or REST deployment
- Process, case and decision modeling
- Service integrations, identity integration and a custom task UI
- Migration from Camunda 7 or Activiti, if it applies
Recurring costs:
- Upgrades, including the Spring Boot and Jackson changes in version 8.0.0
- Dependency patches and security updates
- Database operations and monitoring
- On-call coverage for running processes
Costs rise with the number of processes, custom delegates, event integrations and compliance evidence you must produce. Ask any partner to show these components separately in the quote.
How long does a Flowable assessment take?
The duration is set by the written scope, and no single figure applies across projects. A short assessment of one process differs greatly from a review of an entire estate.
The factors that set the length include the number of processes, which engines you need (BPMN, CMMN or DMN), whether you run Camunda 7 or Activiti today, how identity and environments are set up, and how many integrations are involved.
DeployOpen works mainly on fixed-scope engagements, and scope, deliverables and timelines are agreed in writing before work starts. Ask for milestones, deliverables, assumptions and the client inputs each milestone depends on.
Can our own team implement Flowable without a partner?
Yes, a team with strong Java and Spring experience can often implement Flowable without outside help, but the gaps should be assessed before you commit.
Flowable runs as a JAR in Java SE, servlet containers, Spring applications, Java EE servers or through the REST application, so the engine itself is familiar territory for Java teams.
Common gaps include BPMN, CMMN and DMN modeling skills, clustering and async job behavior, identity integration, building a task UI and planning upgrades. The move to version 8.0.0 requires Spring Framework 7 and Spring Boot 4, and it drops Spring Boot 3 compatibility, so plan that change early. Score your team against these areas before you decide.
What does the Flowable work need from our team?
The work needs named owners, access and time from your side, and the requirements should be written into the scope before work starts.
Typical inputs:
- Process owners who review and approve models
- Domain experts who explain rules, exceptions and decisions
- Access to development, test and production environments
- Access to the database, identity provider, cloud accounts and CI/CD pipeline
- Representative test data and, for migrations, a copy of the existing database
DeployOpen implements Flowable inside your own infrastructure, so your infrastructure team should confirm network, secrets handling and change approval processes early. Get each input, its owner and its due point in writing.
How do we compare a Flowable partner quote?
Compare the written scope line by line, because the scope is what the price reflects. DeployOpen does not publish a price list, and a quote follows from the written scope.
Check each quote for:
- The engines and versions named, and which process types are covered
- The number of process models, service integrations and identity integrations
- Whether a custom task UI, testing and documentation are included
- Migration assumptions, if a Camunda 7 or Activiti move is in scope
- Environments, handover and support after go-live
- Exclusions and the change control process
- Any licenses for commercial Flowable products, listed separately
A quote that lacks these items is hard to compare with another one.
How DeployOpen scopes and hands over a Flowable cost model
DeployOpen works out the cost of owning Flowable from the written scope, not from a license line item, because the open source engines carry no license fee while the team, infrastructure, UI and support work still do. Each engagement is fixed-scope, so the cost model, its assumptions and its recurring items are agreed in writing before work starts.
How we scope
- Confirm which engines (BPMN, CMMN, DMN, event registry) each process needs and whether the REST application is in scope.
- Record the target Flowable version, Java baseline and Spring Boot line, including the 8.0.0 Spring Boot 4 and Jackson 3 changes.
- Inventory the database type, hosting model and number of engine nodes so infrastructure and operations effort can be estimated.
- Decide who builds and maintains the task UI, since the open source UI applications were removed in version 7.
How we build
- Build a cost model that separates one-time build effort from recurring developer, infrastructure and support effort.
- Document each assumption, such as the number of process models, service integrations and expected change requests.
- Compare the open source path with a commercial Flowable product on the same line items, so the trade-off is visible in numbers you can check.
- Test the cost assumptions against a proof of concept run on your own infrastructure before the full estimate is locked.
How we hand over
- Deliver the cost model as a document with its formulas, inputs, owners and the points where the estimate changes.
- Hand over the build, deployment and configuration documentation so your team can run the platform without DeployOpen.
- Walk your finance, architecture and platform leads through the recurring cost items and the quote basis.
- Provide a list of open questions to confirm with Flowable, such as commercial product features or support terms.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, priced separately from the fixed-scope build.
- Review the cost model when Flowable releases a new major version or when your process volume changes materially.
- Keep the cost model current with actual developer hours, hosting spend and incident effort reported by your team.
- Agree support scope, response expectations and upgrade responsibilities in writing as part of the retainer.
