Flowable embedded engine vs REST service: which model fits your team
Choose the embedded model when a Java or Spring Boot team owns the process logic and wants it in the same deployable as the rest of the application. Flowable ships as a JAR that can be added to Java SE, servlet containers, Spring applications and Java EE servers, and its Spring Boot starters, such as flowable-spring-boot-starter-process, bring the engine in as a library. The advantage is that process changes move through your normal build, test and release pipeline, and calls to the engine stay in-process. The cost is coupling: every Flowable upgrade becomes an application upgrade, and the engine's database, async executor and identity configuration sit inside each service that embeds it. This matters most when one team owns the process and the systems around it.
Choose the standalone model when several non-Java systems need one shared process service. Deploying flowable-rest.war to a servlet container such as Apache Tomcat gives those systems a single HTTP surface, so the engine is upgraded and patched once and changed on its own schedule. The trade-off is the security perimeter. All Flowable REST resources require a user with the rest-access-api privilege by default, the REST app creates a default admin user whose password must be changed, and the documentation recommends Basic authentication combined with HTTPS. Confirm how your identity provider and reverse proxy will front the service, and who owns the credentials for each calling system. Those controls are your responsibility in either model, but a shared service concentrates them in one place.
How the two models compare on deployment, security and upkeep
This table sets the embedded Flowable engines against the standalone flowable-rest service on the factors that shape day-to-day running. Read each row as a question to answer for your own team, since the right model depends on which runtime your engineers will own and who calls the process engine.
| Factor | Embedded engine in your Java or Spring Boot app | Standalone flowable-rest service |
|---|---|---|
| Language fit | Java application code calls the Java API directly, using the engine JAR or Spring Boot starters | Any language that can send HTTP requests to the REST API; the service itself is Spring Boot based |
| Release coupling | Engine upgrades ship with your application build and its Spring Boot version | Engine upgrades are a separate deployment of the WAR or service, decoupled from calling applications |
| Scaling | Scale with the host application; the async executor coordinates nodes through lock owners and expiry times in the database | Scale the REST service as its own tier behind your load balancer, with the same database coordination |
| REST security defaults | Not applicable unless you expose REST endpoints from your own app, which then need your own authentication | All REST resources require the rest-access-api privilege by default; change the default admin password before go-live |
| Transport and authentication | Governed by your application's own security configuration | Docs recommend Basic authentication combined with HTTPS; confirm TLS termination and certificate handling in your environment |
| Identity integration | Override IdmIdentityServiceImpl or implement IdmIdentityService; an LDAP identity service is documented as a reference | Same identity service options apply inside the REST deployment, configured in that service |
| Spring Boot 4 upgrade path | Adopt flowable-spring-boot-starter variants for your engines; Flowable 8.0.0 dropped Spring Boot 3 support | Deploy a Spring Boot 4 based flowable-rest build; Flowable documents Spring Boot 4.x support in its starters |
| Who operates the runtime | Your application team owns the engine, its database schema and its monitoring, including the /actuator/flowable endpoint | A platform or integration team typically owns the service, its admin accounts and its access control, and callers depend on its API |
How each deployment is laid out
In the embedded model, the Flowable engines run as libraries inside your own application. You add a Spring Boot starter to the build, and the process engine, its database connection and its job handling start in the same JVM as your business code. Flowable describes its engines as lightweight Java components that can be added to Java SE, servlet containers such as Tomcat or Jetty, Spring applications and Java EE servers.
- Starter choice:
flowable-spring-boot-starterloads all engines, while single-engine starters such asflowable-spring-boot-starter-processload only what you need. The-restvariants add an engine's REST API to your own application, which is a middle path between the two models. - Database: the engine schema lives in a database your application connects to, and Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server.
- Async executor: timers and asynchronous jobs run from a thread pool in each application node. Nodes coordinate through lock owners and lock expiration times stored in the database, so a job whose lock expires is picked up by another node.
- Identity service: you can override
IdmIdentityServiceImplor implement theIdmIdentityServiceinterface, and an LDAP reference implementation is provided. - Scaling: each replica of your application carries its own engine, so you scale the engine by scaling the application.
Before you commit, confirm which database and application server your platform team supports, and check the async executor and lock settings with your own engineers in a test cluster.
In the standalone model, the Flowable REST application runs as its own service and other systems call it over HTTP. Flowable documents two installation routes: deploy the flowable-rest.war, which is based on Spring Boot, to a servlet container such as Apache Tomcat, or add the REST servlet and its dependencies to another web application.
- Deployment unit: the WAR is deployed to a servlet container, so the engine, its REST resources and its database connection form one service that your platform team owns.
- Security defaults: all REST resources require an authenticated user with the
rest-access-apiprivilege. The REST app configures a default admin user, and the docs say to change that password. - Transport: the docs recommend Basic authentication combined with HTTPS, so certificate management and TLS termination become part of the service's design.
- Async executor and identity: timers and jobs run inside the service's nodes, and identity sits behind the same service, so an LDAP or custom identity implementation is a change to the deployed service rather than to each caller.
- Coupling: calling systems depend on the REST contract, not on Java classes or library versions.
Confirm the authentication model, the upgrade path for the WAR and the process for rotating the default admin credentials before you put the service on a shared network.
The two models place the same components in different hands. In the embedded model, application teams usually own the engine version, the database connection and the job configuration because they ship with the application. In the standalone model, a platform or integration team typically owns the service, and application teams interact only through its API and its process definitions.
- Upgrades: an embedded upgrade moves with your application's release train, and Flowable 8.0.0 requires Spring Framework 7 and Spring Boot 4, with no backward compatibility for Spring Boot 3.
- Monitoring: the Flowable Spring Boot docs describe an actuator endpoint at
/actuator/flowablefor monitoring running processes, which you can expose in your own application's monitoring stack. - Access control: a standalone service concentrates privileges in one place, so review who holds the REST privilege and the admin account.
- Database ownership: a shared engine database serves several applications, which needs clear schema ownership and backup windows.
- Skills: embedded teams need Java and Spring expertise in each application, while standalone teams need API and service operations skills.
Ask your teams which group will carry on-call responsibility for timers and stuck jobs, because that answer often decides the topology.
How the async executor shapes high availability in either model
The async executor decides whether a Flowable deployment can survive a node failure without losing timers or asynchronous jobs, and it behaves the same way whether the engine sits inside your application or behind the REST application. According to the Flowable advanced documentation, the executor runs timers and async jobs from a thread pool and coordinates nodes through lock owners and lock expiration times stored in the database. When a node dies holding a lock, that lock eventually expires and another node picks up the job. The failover logic lives in the shared database, so the database is the coordination point in both models, and its availability, transaction behavior and clock handling become part of your high availability design.
For one embedded instance per application, the question is whether each application node runs its own executor and how many of them share one schema. Several copies of an embedded service behind a load balancer will each run an executor against the same database, so the lock behavior described above applies directly to your application pods or servers. For several REST instances behind a load balancer, the same mechanism applies to the flowable-rest deployments, and you also need to confirm that the REST application's own session and authentication settings allow any instance to serve any request. The shared database and its lock expiration settings are the failover mechanism in both cases, so plan them as a shared dependency rather than a per-node detail.
Before relying on either model, test the failover path in your own environment. Start a long timer and an async job, kill the node holding the lock during processing, and measure how long it takes for another node to resume the work and whether any job runs twice. Confirm the lock expiration setting in the configuration docs, check that all nodes use synchronized clocks, and verify the database type you chose is on the supported list in the configuration documentation. Ask the engineers who will operate the system to document the recovery steps and the monitoring signals, including the /actuator/flowable endpoint if you use the Spring Boot starters. Those results, not the architecture diagram, should decide whether this model meets your recovery targets.
Which teams should embed and which should run the REST service
Embedding and running the REST service are two ways to host the same Flowable engines, and the right choice follows from who owns the process logic, who operates the runtime and how often the application must change. The cards below name the condition under which each model is the better fit, so you can match your team to one before comparing costs.
Java product team that owns the process
A product team that already builds and releases a Java or Spring Boot application usually gets the most from embedding. The process model, service tasks and Java delegates live in the same codebase, go through the same pipeline and share the same database transactions as the business data. The main check is whether the team can keep the Flowable starter aligned with its Spring Boot version, since Flowable 8.0.0 dropped Spring Boot 3 support. Confirm that the team's upgrade cadence can absorb that.
Shared platform team serving many languages
When several teams write services in different languages and need one process engine, a standalone REST service lets every caller use HTTP instead of linking a Java library. The platform team owns deployment, backup, patching and the default admin credentials, while product teams deploy and version their own process definitions through the API. Ask whether the platform team has the capacity to run the service as a shared dependency with its own availability targets.
Team customizing identity through IdmIdentityService
If users, groups and roles must come from an in-house directory or a corporate identity system, the team needs to replace the identity layer. Flowable documents this through overriding IdmIdentityServiceImpl or implementing the IdmIdentityService interface, with an LDAP implementation as a reference. That work is Java code inside the process application, so it fits a team that owns that code. Teams that only need standard authentication against the REST app should not take on this effort without a clear requirement.
Team with strict change control on the application
Where the process application falls under formal change approval, a separately versioned REST service can be easier to govern, because the engine release is a single artifact that changes on its own schedule. Embedding ties every engine upgrade to a full application release and its regression testing. Confirm with your change board whether engine upgrades count as application changes, and whether the REST WAR can be deployed through the same controls as your other middleware.
Team without Java operations skills
A team that lacks Java build, servlet container and JVM operations skills should weigh the operating burden before choosing to embed. Running the flowable-rest.war on a servlet container such as Tomcat still requires Java operations, so the real question is who will patch, monitor and secure that runtime. If no one on the team can do that, a managed or partner-run deployment inside your own infrastructure may be a better route, with the scope agreed in writing before work starts.
Upgrades, monitoring and skills for each model
This table compares what each Flowable deployment model asks of your team over time: upgrades, monitoring, database backups and the skills needed to run it. Read it as a checklist of questions to settle before choosing, since several operating details are not covered by the sources we used and need confirming with Flowable or in your own environment.
| Operating item | Embedded engine in your Spring Boot app | Standalone flowable-rest WAR service |
|---|---|---|
| Major upgrade path | Flowable 8.0.0 dropped Spring Boot 3, so your application must move to Spring Boot 4 and Spring Framework 7 to take it. | The REST WAR is also Spring Boot based, so the same Spring Boot 4 path applies. Confirm the WAR build for your servlet container before upgrading. |
| Monitoring | The Spring Boot starters expose an actuator endpoint at /actuator/flowable for monitoring running processes. | Confirm which metrics and endpoints the standalone WAR exposes. Plan to wire the servlet container and application logs into your own monitoring. |
| Database backup | Your application owns the database, so backups, restore tests and schema changes follow your existing application release process. | The service owns the Flowable schema, so backups and restore tests are run by the team operating the WAR. Confirm the supported databases for your version. |
| Security patching | Patches to Flowable libraries ship with your application build, so each engine update is a dependency change you test and release. | Patches are deployed to the shared service, which affects every calling system at once. Confirm the notification and patch channel with Flowable. |
| Operating skills | Java, Spring Boot, build tooling and the Flowable Java API. Developers who maintain the application also maintain the engine. | Servlet container administration, HTTP and HTTPS configuration, Basic authentication and identity administration. Platform or middleware engineers usually run it. |
| Identity and access administration | Identity can be replaced by implementing the IdmIdentityService interface, which is a development task inside your application. | REST resources need the rest-access-api privilege, and the default admin password must be changed. Confirm how your team manages those accounts. |
| Async job handling | The async executor uses lock owners and lock expiration in the database, so you must size the thread pool and confirm node behavior in your cluster. | Job behavior depends on how the service is clustered. Confirm the async executor settings and node coordination for your deployment. |
| Vendor support and operating help | Community forum for open source users. Professional services and partners are offered separately, so scope them in writing. | Same community forum and separately offered services. Ask Flowable which support terms cover the WAR in your environment. |
Steps to choose and secure the right model
This sequence turns the embed-or-service question into a decision you can defend, with the caller inventory, release ownership, database choice, REST hardening and executor behavior all settled before production.
Inventory every caller and its language
List each system that will start processes, complete tasks or query history, and record its language and runtime. Teams writing Java or Spring Boot services can embed the engines directly, while Python, Node.js or other non-JVM callers will need the REST API over HTTP. Note which callers are internal to one application and which are shared across several. The output is a caller table that shows how many systems need the REST surface and whether any of them can reasonably join a single JVM. Review it with the application owners before choosing a model.
Assign ownership of the release cadence
Decide who upgrades Flowable and on what schedule. An embedded engine is versioned with the host application, so the application team owns every engine upgrade, including framework changes. A standalone REST service is deployed separately, so a platform or middleware team may own it while application teams stay on their own release trains. Confirm the Spring Boot line you need, since Flowable 8.0.0 (released February 27, 2026) is based on Spring Framework 7 and Spring Boot 4 and drops Spring Boot 3 support. The check is a written owner and upgrade process for the engine, signed off by both the application and platform leads.
Confirm the supported database types
Check the Flowable configuration documentation for the database types it lists, which include H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server. Match that list against your approved database platforms and your backup and high-availability standards. If you use MySQL, verify the version, because versions below 5.6.4 lack millisecond precision. Ask your DBA to confirm the schema creation and upgrade approach for the chosen model, because embedded and REST deployments both write to the same engine schema. The output is a signed database decision that names the vendor and version your team will operate.
Change the default REST admin password
If you deploy the flowable-rest application, the REST app configures a default admin user, and the documentation says its password should be changed. Replace the default credential with a managed secret before the service sees any traffic, and store it in your existing secrets platform. Confirm that every REST resource requires an authenticated user holding the rest-access-api privilege, then create named service accounts with only the privileges each caller needs. Test that an unauthenticated request is rejected and that the default credential no longer works. Record the result in the change ticket.
Enforce Basic authentication over HTTPS
The Flowable REST documentation recommends Basic authentication in combination with HTTPS. Terminate TLS at your gateway or the service itself, disable plain HTTP for the REST endpoint, and make sure credentials are never logged by proxies or application logs. For embedded deployments, apply the same principle to any HTTP endpoint you expose from the host application, including the /actuator/flowable monitoring endpoint in Spring Boot. Your security team should verify the configuration with a scan or a manual request test against the production-like environment. Keep the result as evidence for your review file.
Replace identity services with your directory
Decide how users and groups will be resolved. Flowable documents that identity management can be replaced by overriding IdmIdentityServiceImpl or by implementing the IdmIdentityService interface, and it provides an LDAP identity service as a reference. Plan this work in both models, because it affects every caller. Confirm with your identity team which directory is authoritative and how group membership changes propagate to running tasks. The output is a tested identity service that resolves users from your directory in a non-production environment.
Pilot async executor behavior under node restarts
Run a pilot on at least two nodes that share one database. The Flowable advanced documentation says the async executor runs timers and asynchronous jobs from a thread pool and coordinates nodes through lock owners and lock expiration times stored in the database, so expired locks should be recovered and jobs picked up by another node. Stop one node while jobs and timers are in flight, then confirm that the remaining node completes them after the lock expires. Repeat with the REST service and with the embedded deployment, since the lock behavior is the same but your operational procedures differ. Record the observed recovery behavior and the job backlog before and after each restart. Do not go to production until this test passes and the operations team accepts the runbook.
What buyers ask before choosing or hiring help
What drives the effort and cost of running Flowable embedded versus as a REST service?
The embedded model moves most of the work into your application codebase, so effort scales with your Java release cycle, testing and how deeply the engine is wired into your domain code. The standalone REST model shifts work toward hosting, servlet container administration, HTTPS termination, authentication configuration and the contract that other systems depend on. Both models carry recurring work for engine upgrades, since Flowable 8.0.0 moved to Spring Framework 7 and Spring Boot 4 without backward compatibility for Spring Boot 3. In a written quote, ask for the scope of engine upgrades, integration and load testing, identity provider integration, backup and restore of the process database, and documentation handover. Ask whether the price covers one-time build work, recurring support, or both, and which party owns each component after handover.
How long does a Flowable pilot take to run?
No supplied duration exists for a Flowable pilot, so no timeline can be stated here. The length depends on how many process models you need to run, whether you use BPMN only or also CMMN and DMN, how many systems call the engine, and how many identity sources and databases must be connected. Ask any provider to state the pilot scope, the deliverables, the environments it will run in and the acceptance criteria in writing before work starts. DeployOpen plans most engagements as fixed-scope, with scope, deliverables and timelines agreed in writing before work begins, so ask for that document rather than an estimate in a sales call.
Can an in-house Java team run Flowable without outside help?
A team with strong Java and Spring Boot skills can run the embedded engines alone if it can own the operational tasks that come with them. Those tasks include tracking Flowable release notes, handling breaking changes between major versions, configuring the async executor and its lock expiration in a multi-node deployment, and monitoring through the actuator endpoint at /actuator/flowable. Teams that have never run a BPM engine in production often underestimate the BPMN modeling, process versioning and database administration work. A useful self-check is whether two engineers can each explain the database schema, the job executor behavior and the upgrade path without reading the documentation again. Teams that lack this depth can scope a fixed engagement for the first build and keep knowledge transfer in the contract.
How do you harden the Flowable REST API against misuse?
Start by treating the REST application as an internet-facing or network-facing API that needs the same controls as any other service. Flowable's documentation says all REST resources require an authenticated user with the rest-access-api privilege by default, and that the REST app creates a default admin user whose password you must change. The docs recommend Basic authentication combined with HTTPS, so terminate TLS at the servlet container or reverse proxy and restrict which networks can reach the endpoints. Remove or disable default accounts, scope privileges to the minimum each calling system needs, and log authentication failures. Confirm with your security team how these controls map to your own access policy, and test them in a staging environment before exposing the service to other systems.
Can we move from the flowable-rest WAR to embedded starters later?
Moving between the two models is usually a code and deployment change rather than a change to the process data, because both run the same Flowable engines and use the same database types. Flowable documents the REST application as a WAR deployable to a servlet container such as Apache Tomcat, and it also documents Spring Boot starters with -rest variants that add the REST API to your own application. Confirm with the vendor that your Flowable version, database and process definitions carry over unchanged, and check how deployment IDs, custom identity services and scripts are reconnected. Plan for re-testing every calling system, because the HTTP contract and authentication path can change even when the engine does not. Ask for a written exit or move plan as part of any quote.
What does the work need from our own environment?
The work needs access to the infrastructure where Flowable will run, including the database server, application hosts or servlet container, network paths to calling systems, and your identity sources. Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server, so confirm which of these you already operate and who administers them. You will also need build pipelines, a test environment that mirrors production, certificates for HTTPS, and a way to supply LDAP or other identity services, since Flowable documents an LDAP reference implementation that you can replace. Ask any provider to list these prerequisites, the named client contacts, and the access they need, and confirm how they will be granted and revoked during the engagement.
Which parts of the cost recur after the first build?
Most recurring cost comes from keeping the engine current, operating the database and maintaining integrations. Flowable publishes separate release lines, including 7.x releases in 2024 and 2025 and the 8.0.0 release on February 27, 2026, so budget for upgrade cycles that include framework changes and test suites. The database requires backups, patching and capacity planning, and the async executor requires monitoring so that timers and jobs keep running. Ask whether a retainer covers upgrades, security patching, continuous testing and incident response, and whether those services are priced separately from the initial implementation. Also ask who pays for Flowable commercial products if you later need low-code tooling, since the open-source engines do not include those.
What it costs to switch models later
Moving from an embedded engine to the REST application, or back, changes how callers connect and where identity and security sit, but it does not change the process definitions and the database, which are the core asset. BPMN models, deployed process versions, running instances and history rows live in the schema the engine manages, so they carry across the switch if the engine version and database stay constant. The cost lies in what surrounds them: the Java calls in your application, the HTTP clients in other systems, and the authentication path that each model requires.
Expect the effort to concentrate in three places. First, the embedded model puts engine calls inside your application's transactions, so moving to REST means redesigning those boundaries and deciding how failures are retried across an HTTP call. Second, the REST model requires authenticated users with the rest-access-api privilege by default, so every caller needs an identity, role mapping and HTTPS in front of Basic authentication, and the default admin password must be changed. Third, if you replace identity management by overriding IdmIdentityService, that custom code must be carried into whichever deployment you choose. Each of these is recurring maintenance as well as one-time migration work.
Before committing, confirm with Flowable and in your own environment: the engine version you will run, since Flowable 8.0.0 requires Spring Boot 4 and drops Spring Boot 3 support; that your database type is on the supported list in the Flowable configuration documentation; how the async executor's lock settings behave when several nodes share one database; where identity and token validation will sit; and who will own the REST service's upgrades and patching. Ask any implementation partner to quote these items separately, so the cost of a later switch is visible before the first design decision.
