Moving Flowable from VMs to Kubernetes

Moving Flowable to Kubernetes without rewriting your process models

Moving Flowable from virtual machines or an application server to Kubernetes is a re-platforming of the runtime, and your process models, case models, decision tables and data stay where they are. The engines are the same Java components you run today, now packaged in container images, started by a scheduler, and configured through the environment instead of hand-edited files on a host. The work is about how those engines start, connect to the database, share jobs and receive new process definitions, not about redrawing the models.

Effort depends on four things: the target Flowable version and the Java and Spring baseline it requires (Flowable 8.0.0 moved to Spring Framework 7 and Spring Boot 4 and dropped support for Spring Boot 3, so a jump across that line is a separate upgrade), the number of engines and the custom delegates, listeners and identity services they carry, the database and its connection settings, and how much of today's deployment is manual. A team that deploys by copying a WAR and editing properties by hand has more to codify than a team with scripted pipelines. No effort figure is given here. Confirm the target version, inventory your engines and custom code, and ask any partner for a written scope before work starts, because the scope, deliverables and timeline are agreed in writing first.

What carries over from a VM deployment and what the container changes

This table compares how each part of a Flowable engine behaves on a VM or application server with its container equivalent on Kubernetes. Read the migration notes as the questions to answer before cutover, because most surprises come from assumptions the VM setup made without anyone writing them down.

Area	VM or application server	Kubernetes or container equivalent	Migration note: what to confirm
WAR or application server deployment	flowable-rest.war deployed to Tomcat or Jetty	Image built with the engine JAR or Spring Boot app, started as a pod	Confirm whether anything depends on the WAR layout, context path or server-level resources.
JVM and property files	JVM flags and properties set in server files	Environment variables, ConfigMaps and container JVM options	Confirm heap settings respect container memory limits and that no property relies on a host file.
Database URL and credentials	JDBC URL and password in config files on the host	Connection settings from ConfigMaps and Secrets, injected at startup	Confirm the secret is not baked into the image and that Secrets are encrypted at rest in etcd.
Local file paths and logs	Logs written to local disk, files read from fixed host paths	Logs to stdout collected by a logging agent, volumes for any files that must persist	Confirm nothing writes to the container filesystem that operations or auditors expect to keep.
Scheduled and async jobs	Timers and async jobs run by one or more nodes sharing a database	Multiple pods share the same database and lock owners, so job count scales with replicas	Confirm the async executor settings per pod and whether any job assumes a single node runs it.
Process definition deployment	Definitions deployed by a script or manual step on the server	Deployment as a pipeline step or init job, versioned with the image	Confirm how new definitions reach every pod and that running instances keep their version during rollout.
Monitoring through /actuator/flowable	Checked manually or by a host agent against one server	Probed and scraped per pod, with health checks pointing at the actuator	Confirm the endpoint is exposed only where intended and that dashboards aggregate across pods.
Identity service overrides	Custom IdmIdentityService implementation placed on the classpath	Same class packaged into the image, with its LDAP or directory settings supplied at runtime	Confirm directory connectivity from the cluster network and that no override reads host-local files.
Session handling	Users may reach one server, with sessions held in memory	Requests spread across pods through a Service or ingress	Confirm whether any client or proxy assumes sticky routing or in-memory session state.

Which documented paths get Flowable into containers

Flowable publishes several starting points for running engines in containers, but none of them moves an existing VM deployment onto Kubernetes. The cards below describe what each documented path provides and where your team still has to make decisions before a cluster rollout.

Docker Compose run configurations

The flowable-engine repository ships Compose configurations for Flowable REST with PostgreSQL, and for Flowable REST behind an HAProxy load balancer with PostgreSQL. Use them as a reference for how the REST container, database and load balancer connect, and for the environment variables and ports your manifests must reproduce. Check the database connection settings and version pins against your own platform before reusing anything in a cluster.

Cosign-signed Flowable images

Flowable Docker images are signed with cosign from version 6.7.3. Your admission and pipeline controls can verify the signature before a pod starts, which matters if your cluster enforces signed images only. Confirm which image tags you have run in production, verify signatures against the published key material, and mirror the verified images into your own registry.

Spring Boot starters and actuator

Flowable provides starters for all engines, for REST, and for the individual process, CMMN and DMN engines. Applications built on these starters expose an actuator endpoint at /actuator/flowable for monitoring running processes. Containerizing a Spring Boot application means externalizing configuration, wiring readiness and liveness probes to the actuator, and confirming the endpoint is exposed only to the monitoring path you intend.

Flowable REST application

The Flowable REST application lets an engine run as a standalone service accessed over HTTP, which is the usual shape for a VM-hosted war on Tomcat. Moving it to Kubernetes means deciding how the war is packaged in the image, which servlet container runs it, and how externally deployed process definitions reach each pod. Verify the REST paths and authentication settings your clients depend on before cutover.

Supported database types

The configuration docs list H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server as supported database types. In a cluster, every pod shares one database, so the database choice sets how the async executor locks and recovers jobs. Confirm that your target database and its connection pooling suit the number of replicas you plan, and note the MySQL precision requirement for older versions.

No importer for VM deployments

No documented importer moves a VM deployment to Kubernetes. The Kubernetes manifests, Secrets, image build, database configuration and deployment pipeline for process definitions are built by your team or its partner. Budget for that work explicitly, and ask any partner to show which parts of the current VM setup they will re-create and which they will retire.

How the async executor and process deployments behave across many pods

The async executor is the part of Flowable most likely to change behavior when you move from a fixed set of VMs to a Kubernetes deployment that scales by pod count. Each Flowable node runs timers and asynchronous continuations from its own thread pool, with documented defaults of 8 core threads, 8 maximum threads and a queue of 100 jobs. Nodes do not share that pool. They coordinate through a lock owner and lock expiration time stored on each job row in the database, so several pods can point at one schema safely. Before you set replica counts, confirm these defaults against the version you run in the Flowable advanced documentation, because the values are configuration, not guarantees, and your platform team should record the overrides each deployment uses.

Scaling out multiplies the number of pools competing for the same job table. Every additional pod adds up to 8 threads polling and executing work, and every pod holds its own database connection pool, so the total connection count grows with replicas and with any HPA scaling rule. If the queue fills, the engine unlocks the job and returns it to its table so another executor can take it. That keeps work moving, but a pod that is saturated will repeatedly release jobs, which adds write load and lock churn on the database. Watch queue depth, lock expiration timeouts and database connection saturation together, and test with the replica range your autoscaler will actually use. Lock expiration in particular should be checked against your longest job so that slow work is not picked up twice.

Process definitions should be deployed once per rollout, by a separate deployment step such as a Kubernetes Job or a pipeline stage, not by every pod at startup. When each pod deploys definitions on boot, a rolling update can register the same BPMN, CMMN or DMN resources repeatedly, create extra definition versions and contend for the same records during startup. Decide the deployment ownership model before the first cluster build, then rehearse a rolling update with running instances that span the old and new definitions. Load test with your own pod counts, job volumes and timer profiles, because no supplied figure predicts how your database and queue will behave under your workload.

Moving Flowable to Kubernetes: sequence from inventory to decommissioning

This sequence moves a running Flowable estate from virtual machines or application servers to containers in a controlled order, so that every engine, schema and job has a known owner at each point and the VMs are only retired after a verified rollback window.

Inventory engines, applications, delegates and schemas
Your team lists every Flowable engine (BPMN, CMMN, DMN, event registry and REST), the application or WAR that embeds it, the Flowable version and Java baseline, the custom delegates, listeners and identity service overrides, and the database schemas and their supported database type. DeployOpen can run this inventory with your engineers and produce a dependency map. The step is done when each engine has one owner, one schema and one written list of external dependencies such as message brokers, LDAP and file shares, and the team agrees which items are blockers for containers.
Build images and externalize configuration
The team builds a container image for each application, pinning the Flowable version and base image, and moves database URLs, credentials, identity settings and feature flags out of the image into Kubernetes configuration and Secret objects. Secrets should be encrypted at rest or pulled from an external store, since Kubernetes stores Secrets unencrypted in etcd by default. Images are scanned and signed under your own policy. The step closes when the same image starts in a test cluster with only environment-specific configuration changed, and the team can show which values come from where.
Rehearse the deployment in staging
Restore a copy of the production database into staging, deploy the containerized engines against it, and run the full set of process, case and decision regression tests plus a sample of real instance flows. The team records how long schema checks, process definition deployment and startup take, and whether the async executor behaves as expected with the planned replica count. The rehearsal is complete when the results are reviewed and every failure has a fix or an accepted risk, and the runbook for the cutover is written from what was actually observed.
Pilot with a small number of pods
Run a few pods of one non-critical engine against the production database, with readiness and liveness probes wired to Flowable health endpoints and the Spring Boot actuator where applicable. Observe job acquisition, lock ownership, timers, failed jobs and log output while the VMs keep serving the bulk of the work. The pilot ends when the team has seen timers fire, async jobs complete and a rolling restart of pods leave no stuck work, and each finding is either fixed or added to the cutover checklist.
Run old and new nodes in parallel with clear job ownership
Both VM nodes and pods share one database during the parallel run, so the team must define which nodes own which work. Flowable's async executor locks jobs with a lock owner and expiration time in the database, which allows several nodes to share a schema, but it does not decide business ownership for you. Your team decides, for example, whether a given process family or timer set is routed only to one side, and monitors that no job is executed twice or left unacquired. The parallel run ends when the ownership plan has held without duplicate side effects for an agreed observation period.
Execute the cutover window
During the agreed cutover window, the team drains new work from the VM nodes, confirms that remaining jobs are locked or released, scales the Kubernetes deployment to the planned replica count and points traffic and integrations at the new service. Process definition deployments are frozen during the window. The team keeps the VM nodes and their configuration intact so that a documented rollback can be executed. The step is done when smoke tests pass, failed job counts are within the agreed threshold, and the operations team confirms ownership of the new environment.
Decommission the VMs after the rollback window
Once the rollback window has closed without a rollback, the team stops the VM application servers, archives their configuration and logs according to your retention policy, removes their database connections and access grants, and updates the CMDB, backup jobs and monitoring. Before removal, confirm that backups for the new schemas and the Kubernetes control plane cover your recovery objectives. The step is complete when no traffic or scheduled job points to the old hosts, and the decommissioning record is signed off by the service owner.

Which deployment shape fits your current Flowable application

In this shape, the Flowable engine is a library inside your own Spring Boot or servlet application, so the container image is your application image. It carries your compiled classes, the Flowable JARs pulled in through the Spring Boot starters or the engine dependencies, your delegates and your BPMN, CMMN and DMN resources, usually packaged on the classpath. Health checks are whatever your application exposes, and the Flowable actuator endpoint at /actuator/flowable is available for monitoring running processes when the Spring Boot starters are used. Process definitions normally reach the engine at startup through deployment in the application, so a rollout of new definitions is a rollout of the application.

Image contents: application JAR or WAR, Flowable dependencies, JDBC driver and process resources, on a base image that matches your Java baseline.
Health checks: application readiness probes that confirm the database connection and engine start, plus the actuator endpoint where enabled.
Definition delivery: deployed by the application at boot, so definitions change with the image tag.
Questions to settle: whether any definitions are deployed at runtime through the API, and whether your delegates depend on servlet-container resources.

Confirm the Java and Spring baseline your Flowable version requires before choosing this shape, because the Spring Boot and Jakarta requirements differ between major versions.

What drives the effort and duration of the move

This table lists the factors that change how much work the move from virtual machines to Kubernetes takes, who pays for each piece, and whether the cost is one-time or recurring. Use it to shape the written scope and the quote request, then ask the partner to price each row separately.

Driver	Why it changes effort	What to ask for in a quote
Target Flowable version and baseline	Flowable 7 moves to Java 17, Spring Boot 3 and Jakarta EE. Flowable 8 moves to Spring Framework 7 and Spring Boot 4 with no Spring Boot 3 compatibility, so a jump to 8 can also mean a code and dependency rewrite (one-time).	A written list of the Java, Spring and Jakarta changes per engine and which version is targeted.
Number of engines and applications	Each engine, REST deployment or custom Spring Boot application needs its own image, configuration, health checks and rollout. Effort grows with each one (one-time build, recurring operation).	An inventory of every engine, application and deployment unit, with the one-time and recurring work estimated for each.
Custom delegates and identity service overrides	Custom Java delegates, listeners and overrides of the identity service must be rebuilt, retested against the container runtime and checked for classpath conflicts (one-time).	Count of custom delegates and overrides, and the test effort assumed for each.
Database scope and connectivity	Connection pools, credentials, TLS settings and any change of database type must be verified from pods. Moving to a different supported database adds schema and data work (one-time, with some recurring tuning).	Confirmation of the database types in use, connection method from pods and who owns the database service.
Async executor load and pod count	Several nodes share one database through lock owners and lock expiration, so the number of pods and the executor thread settings change job throughput and contention. Load tests are needed before scaling out (one-time tuning, recurring capacity review).	A load test plan, the executor settings to be tested and the pod counts planned for production.
Deployment pipeline for process definitions	Process and case definitions must be deployed in a controlled order during rolling updates, with versioning rules for running instances. A pipeline that deploys definitions separately from images is usually more work to build but easier to operate (one-time build, recurring use).	The pipeline design, rollback steps and who owns definition releases after handover.
Secrets handling and compliance evidence	Database credentials and tokens move into Kubernetes Secrets, which are stored unencrypted in etcd by default unless encryption at rest is configured. Access control, audit logs and change records must be produced for assessors (one-time setup, recurring evidence collection).	The secrets design, whether encryption at rest and external secret stores are in scope, and the evidence list for assessors.
Team Kubernetes maturity	A team that already runs production clusters needs less onboarding. A team new to Kubernetes needs training, cluster ownership decisions and runbooks, which add one-time and recurring cost.	A short capability review and a list of roles the partner will cover versus the client team.
Parallel run length	Running VM and Kubernetes environments side by side keeps both sets of infrastructure and support active for the length of the run, and it adds reconciliation work for any data written to both (recurring for the run period).	The planned parallel run length, the cutover criteria and the infrastructure cost the client keeps during the run.

What usually goes wrong on the way to containers

Moving a Flowable engine from a VM to Kubernetes changes how many copies of the engine run, how they share one database, and how they restart. The risks below cluster around three things: the async executor, configuration that travels with the image, and the cluster versions underneath. Each one has a check you can run before cutover.

Jobs run twice or stall in parallel

Several pods share one database, and the async executor coordinates them through lock owners and lock expiration times stored there. During a parallel run with the VM cluster, two engines can pick up the same timers or continuations, or jobs can wait for a lock to expire before anyone retries them. Prevention: decide which environment owns timers before go-live, and confirm lock expiration settings and the executor pool size with a load test that counts completed jobs per instance.

Rollouts interrupt locked jobs

A rolling update stops a pod while it holds locked jobs. The lock stays in the database until it expires, so those jobs pause until another node recovers them. Prevention: set a termination grace period long enough for in-flight work to finish, keep the rollout surge and unavailable limits conservative, and test a forced pod kill during a timer burst to measure how long recovery takes in your setup.

Database credentials baked into images

A datasource password written into a properties file during the image build ends up in every registry copy and every environment that pulls it. The Flowable engine reads its database settings at startup, so these values should arrive at runtime. Prevention: inject the JDBC URL, user and password from Kubernetes Secrets or an external secret store, scan the built image for literal credentials, and keep one image promoted across environments.

Probes restart pods during slow startup

A liveness probe with a short initial delay can kill an engine while it is still running schema checks or deploying process definitions. The pod then restarts in a loop and may never finish the startup it began. Prevention: use a startup probe for the first boot, point readiness at a check that reflects database connectivity, and keep liveness lenient. Confirm the actuator health path your Spring Boot build exposes before you write the probe.

Connection pools multiplied by pod count

Each pod opens its own JDBC pool, so the database sees the pool size multiplied by the replica count, plus any pods added during scale-out. A setting that worked for two VMs can exhaust PostgreSQL or Oracle connection limits once the deployment scales. Prevention: calculate the total connection budget across the maximum replica count, cap pool sizes per pod, and confirm the database and any connection pooler limits before setting autoscaling bounds.

Process definitions deployed out of step with code

If the container image ships new application code but process definitions are deployed separately, running instances and new starts can use mismatched models, and a pod may start before its definitions are in place. Prevention: version BPMN, CMMN and DMN files with the code, deploy them through one pipeline stage that runs before traffic shifts, and record the deployed definition versions so you can trace which version each instance uses.

Kubernetes versions fall out of upstream support

Upstream Kubernetes maintains only the three most recent minor releases, so a cluster that is not upgraded on schedule loses security patches and falls outside the version skew policy. A Flowable deployment tied to an old cluster then inherits both risks and a harder upgrade. Prevention: record the cluster minor version and its end-of-life date in the operations plan, schedule upgrades one minor version at a time, and check the Flowable image against each target version in a staging cluster.

What buyers ask before moving Flowable to Kubernetes

What drives the cost of moving Flowable from VMs to Kubernetes?

The cost follows the number of engines, environments and integrations that have to be containerized and tested, plus how much of the current deployment is scripted. Work covers image build, database connectivity, the async executor configuration, the process definition deployment pipeline, health checks and the cutover. Some costs are one-time, such as the migration itself, while others recur, such as cluster operations, image rebuilds for patches and Flowable upgrades. Ask any quote to separate these lines, to name who performs each one, and to state which Kubernetes platform and distribution the scope assumes.

How long does a Flowable move to Kubernetes take?

Duration depends on how many engines run, how far the current VM setup is from a container-ready state, and how many environments must be proven before production. The Kubernetes cluster itself may already exist or may need to be built, which changes the schedule substantially. Timing is also set by change windows, the number of integrations to retest and whether process definitions are deployed by hand today. No duration can be stated here without a written scope, so ask for a timeline that lists each phase, its entry and exit criteria and the dependencies on your team.

What does the work need from our own team?

Expect to supply people who know the current Flowable deployment, the database owners who approve schema and connection changes, and the platform team that operates the clusters. Someone must confirm which Flowable version and starters are in use, the database type and the identity setup. Your team also decides how secrets, certificates and network access are handled, since Kubernetes stores Secrets unencrypted in etcd by default unless encryption at rest is configured. Ask the partner to list these inputs in the scope so availability can be planned before the work starts.

Can our own engineers do this migration without a partner?

Yes, a capable team can containerize Flowable and run it on Kubernetes, and the Flowable Docker README includes Docker Compose examples for REST with PostgreSQL and behind HAProxy that show the general shape. The harder parts are sizing the async executor for several pods, designing rolling deployments of process definitions and running a cluster that meets your security baseline. Decide based on whether your team has done these before and whether it can absorb the work alongside production duties. A written scope lets you compare the two options on the same terms.

Is there a documented tool that moves Flowable data to a new platform?

Flowable's documented migration tooling covers moving from Camunda 7 and Activiti, not a move from VMs to containers. The engine itself does not change when the runtime moves, so the work is about deployment, database connectivity and operations rather than data conversion. Confirm this with Flowable for your exact version and check the Flowable advanced documentation for how nodes share the job tables. If you are also changing the database or upgrading the engine, those are separate projects with their own tooling and should be scoped separately.

Will running process instances survive the move to Kubernetes?

Running instances can continue because their state lives in the database, not in the VM, provided the new pods connect to the same schema and the cutover is planned. The async executor locks jobs with a lock owner and an expiration time, so expired locks are recovered and picked up by other nodes. A safe cutover needs a plan for timers and jobs that are mid-execution, a tested database backup and a rollback path. Ask the partner how in-flight jobs are drained or verified before the old nodes are stopped.

How does Kubernetes platform support affect the plan?

The Kubernetes minor releases you run set how often the platform must be upgraded, and each version has a limited patch window, so the cluster upgrade cycle becomes part of Flowable operations. The version skew policy requires the control plane to move one minor version at a time before nodes, which affects how long a Flowable release can wait. Confirm which distribution and version your organization supports, whether it is conformant, and who owns control plane upgrades and etcd backups. These answers change the recurring cost more than the first migration does.

What should we ask for in a quote for this work?

Ask for a written scope that lists the Flowable version, engines, starters and databases in use, the target cluster and its ownership, and each deliverable such as images, manifests, pipelines and runbooks. The quote should show one-time work separately from retainers for upgrades, patching and support, and it should state assumptions about your team's inputs. Ask how health checks and the async executor settings will be tested, and how the rollback and cutover are verified. DeployOpen plans most engagements as fixed scope, with timelines agreed in writing before work starts.

How DeployOpen scopes and delivers a Flowable to Kubernetes move

DeployOpen approaches moving Flowable from virtual machines to Kubernetes as a written, fixed-scope engagement covering images, database connectivity, async executor behavior across pods, deployment of process definitions and health checks. We build inside your own cloud accounts, data centers or air-gapped networks, and hand over documentation your team can run without us.

How we scope

We inventory your current Flowable engines, REST deployments, database types and how process definitions reach each node today.
We confirm the Flowable version, Java baseline and Spring Boot or servlet container in use before choosing an image and build approach.
The written scope lists the Kubernetes distribution, cluster ownership, environments and the workloads covered, and is agreed before work starts.

How we build

We build container images and Kubernetes manifests for your engines, including database connection settings and secrets handling.
We test async executor behavior with several pods sharing one database, checking lock owners, lock expiry and job pickup under load.
We set up rolling deployment of process definitions and health checks, then verify them in a non-production environment before cutover.

How we hand over

You receive the images, manifests, runbooks and configuration documentation written for your own operations staff.
We document the rollout procedure for process definitions, the rollback steps and the checks that confirm a healthy engine after deployment.
Knowledge transfer sessions cover the cluster components your team must own, such as etcd backups and version upgrades.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover, scoped in writing.
Retainers can cover Kubernetes minor-version upgrades and Flowable version upgrades, planned against each project's own support windows.
Confirm with DeployOpen what support hours, response expectations and upgrade testing a retainer includes before signing.

Moving Flowable from virtual machines to Kubernetes