Flowable Engine: a Java BPMN, CMMN and DMN engine you embed or run as a service

What Flowable Engine is for, and who ends up using it

Flowable Engine is a workflow and Business Process Management platform aimed at developers, system admins and business users. The part that matters to an engineering team is the execution layer: a BPMN process engine, a CMMN case engine and a DMN rule engine, all written in Java and distributed under Apache 2.0. The README describes it as something that "can run embedded in a Java application, or as a service on a server, a cluster, and in the cloud" and that "integrates perfectly with Spring".

That sentence is the whole positioning. This is not a SaaS product with a signup form. It is a library and a runtime you place somewhere in your own architecture. The intended user is a developer who wants process state, task assignment and decision tables handled by a proven engine rather than by hand-rolled status columns in a database. System admins get a deployable service and a REST surface. Business users get models, but only through tooling that sits on top of the engine.

The repository layout supports that reading. The top level carries modules/, distro/, docker/, k8s/, qa/, tooling/ and docs/ alongside the Maven wrapper and pom.xml. A project that ships Kubernetes manifests and a Docker directory next to its engine modules is telling you it expects to be operated, not just imported.

Three engines, one runtime: how the pieces fit together

The mechanism is model-driven execution. You author a process as a BPMN file, a case as a CMMN file, or a decision as a DMN file, and the corresponding engine parses and executes it. The README names three engines explicitly: BPMN for processes, CMMN for cases, DMN for rules. Each is a separate engine artifact in the org.flowable group, which is why the Maven Central badge on the README points at flowable-engine, flowable-cmmn-engine and flowable-dmn-engine rather than a single coordinate.

At runtime the engine keeps the state of running instances in a database and exposes a Java API and a REST API over it. The README frames the API as the integration point: "With a rich Java and REST API, it is the ideal engine for orchestrating human or system activities." In practice that means a service task in your BPMN can call your code, a user task can wait for a human through the task API, and a decision can be delegated to a DMN table instead of an if-else chain.

The deployment story follows from the same design. The docker/ directory and the flowable/flowable-rest image on Docker Hub exist so the REST layer can run without you writing a Java host application. If you embed instead, you take on the schema and transaction management yourself. That is the real fork in the road, and the README does not hide it: embedded, service, cluster and cloud are all listed as supported shapes.

Getting Flowable Engine into a Java project

The README points downloads at https://www.flowable.org/downloads.html and states that the distribution contains most sources as jar files. For a Java project the normal path is Maven Central, which the README surfaces through its Maven Central badge. The badge searches for the org.flowable group and the flowable-engine, flowable-cmmn-engine and flowable-dmn-engine artifacts, so those are the coordinates to look up before you add anything to a build file.

Before any of that runs, check the JDK. The README is explicit: "Flowable V7 runs on a Java higher than or equal to version 17." Verify with the command the README itself gives.

java -version

You should see a version of 17 or higher printed. If you are on Java 8, the README says Flowable V6 is still maintained and supports Java 8+, and links the flowable6.x branch. That is a deliberate branch decision, not a configuration flag.

If you would rather run the engine as a service than embed it, the README's Docker badge points at the flowable/flowable-rest image on Docker Hub. The README does not document the endpoints, the default credentials or the database configuration for that image, so treat the container as a starting point and check the docs/ directory in the repository for the specifics you need.

For modelling, the README mentions Flowable Design, a free to use cloud application for CMMN, BPMN, DMN and other model types, reachable through the account registration page at https://www.flowable.com/account/open-source.

Where Flowable Engine is the wrong tool

The first limitation is environmental. Flowable V7 and V8 require JDK 17 or newer. If your platform is pinned to Java 8 and you cannot move, you are pushed to the flowable6.x branch, which the README says is still maintained. Staying on a previous major line is a real cost, and the README does not describe an upgrade path between V6 and V7 or V8.

The second is operational. Running the engine as a service means a database schema, a deployment process for your BPMN and DMN files, and a REST surface to secure. The repository ships docker/ and k8s/ directories, which tells you the project expects this work to happen, but the README does not walk through schema creation, migration between engine versions, or cluster configuration. Those are the questions that decide whether an upgrade is a redeploy or a project.

The third is scope. Flowable is an engine. If your team wants a finished low-code application where business analysts publish processes without engineering involvement, the engine alone does not give you that. The README separates the engine from Flowable Design, which is a cloud modelling application, and it does not claim the open source engine ships a full end-user UI. Teams that read "BPM platform" as "product" will be surprised by how much assembly is left to them.

Flowable and Camunda: two engines, two governance models

The comparison engineers actually make is with Camunda, and the difference that shows up first is licensing and packaging rather than execution semantics. Flowable is distributed under Apache V2, stated plainly in the README's licence section and in the LICENSE file at the repository root. That permissive licence is the reason the engine can be embedded in a commercial product without a commercial agreement.

The second difference is breadth in one distribution. Flowable ships a BPMN process engine, a CMMN case engine and a DMN rule engine under the same project and the same licence. A team that needs case management alongside process orchestration does not have to assemble that from separate vendors. Camunda's own product line has moved toward a commercial model for parts of its stack, which is exactly the kind of decision that sends teams looking at Apache-licensed alternatives.

The third difference is the Java baseline. Flowable V7 and V8 require JDK 17 or newer, with V6 held open for Java 8+. That split is a governance choice: the project keeps an older line alive for slower-moving shops instead of forcing a single runtime floor on everyone. Whichever engine you pick, the migration question is the same, and neither README answers it for you.

Maintenance, versions and what the licence lets you do

The repository is not archived, and the last push was on 2026-09-17. Recent releases are flowable-8.0.0 on 2026-02-27, flowable-7.2.0 on 2025-08-21 and flowable-7.1.0 on 2024-10-07. That cadence, roughly one minor line per year with a major in early 2026, is the number to plan against. If you pin flowable-engine at 8.0.0, you should expect a new minor line within about a year and a major somewhere beyond that.

The upgrade cost is not documented in the README. There is a docs/ directory and a wiki linked for contributing, and the README sends problem reports to https://forum.flowable.org and to the GitHub issue tracker, but it does not publish a compatibility matrix between engine versions or a schema migration guide. Budget for reading release notes yourself before you move a production engine across a major version. The qa/ directory in the repository suggests the project runs its own test suites, which is a signal about internal rigour, not a promise about your upgrade.

On licensing, Flowable is Apache 2.0, which permits commercial and closed-source use and modification. That is a statement about the licence text, not legal advice; if you are embedding the engine in a distributed product, have your own counsel read the Apache 2.0 terms and the NOTICE requirements rather than relying on a summary.

Editorial conclusion

Adopt Flowable if you are a Java team that wants to keep process definitions in BPMN, CMMN and DMN files and execute them inside your own application or behind the REST API, and if JDK 17 or newer is already your baseline. Do not adopt it if you need a hosted modelling and operations product out of the box, or if you are still on Java 8 and unwilling to stay on the Flowable V6 branch. Before committing, verify two things in your own environment: that the flowable-engine artifact resolves from Maven Central at the version you intend to pin, and that the deployment and repository service APIs you plan to call behave as the documentation describes for that version.

Frequently asked questions

Official sources

1. flowable/flowable-engine on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases