Running Flowable on Kubernetes: when a cluster deployment makes sense
Flowable can run as several engine nodes that share one database, and the async executor is what lets them divide the work. A cluster deployment makes sense when a platform team needs more than one Flowable node for throughput, needs a node to be replaced without stopping process execution, or wants Flowable to follow the same build, deploy, probe and rollback standards as the rest of its services. If one application server with a single database already meets the required load and recovery targets, a cluster adds moving parts that someone must operate. 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 a job locked by a failed node is picked up by another once its lock expires. That design is the reason multiple pods are worth running, and it is also the first thing to test before scaling out.
Flowable is licensed under Apache 2.0, and its engines can be embedded as a JAR in a Spring application or run as a service through the Flowable REST application. Those two choices change what the container holds. An embedded engine means your own Spring Boot service image contains the engine, your process definitions and your delegates, so each release of the business application is also an engine release. The REST application keeps the engine in a separate image and lets teams call it over HTTP, which suits shared process services but still needs its own database credentials, probes and configuration. Decide this first, because the image pipeline, the Helm or manifest layout and the upgrade sequence all follow from it.
The cluster itself is your responsibility to scope. Flowable does not provide the Kubernetes control plane, the ingress, the etcd backups, the Secrets handling or the node pools, and those carry their own upgrade cadence and security controls. Before committing, confirm who operates the cluster, which distribution and version it runs, how workloads authenticate to the database, and who approves changes to process definitions in production. Plan the database as a shared dependency with its own high availability and backup. A cluster deployment is the right answer when those owners exist and have agreed to run them; without them, a well-configured single-node deployment is usually easier to keep correct.
Which Flowable packaging fits a Kubernetes workload
Embedding the engine in your own Spring Boot application is the route where Flowable becomes part of your service. You add the Flowable Spring Boot starters to the build, choose between the all-engines starter and the single-engine starters for process, CMMN or DMN, and package the result as one executable image. The starters document which engine tables and endpoints each choice brings in, so the footprint is decided in the build file rather than at runtime. Configuration arrives through Spring properties, environment variables and config maps, and the image carries your delegates, listeners and any identity service you wrote.
- Image contents: one JAR per service, including your process models, delegates and any Java classes the engine must load.
- Configuration: datasource, pool and async executor settings are normal Spring properties, injected per environment.
- Probes: the actuator health endpoint fits liveness and readiness, and the Flowable actuator endpoint at /actuator/flowable is useful for monitoring, not for probes.
- Deployments: model changes usually mean a new image, so rollouts and rollbacks follow your application release process.
- Team skills: the Java and Spring team owns the upgrade path for the engine together with the application.
Check that the starter you chose matches your Spring Boot line, since the Flowable 8.0.0 release notes state it targets Spring Boot 4 without backward compatibility for Spring Boot 3.
The Flowable REST application is a ready-made web application that exposes the engines over HTTP, so the Kubernetes workload is a service that other systems call. You deploy the REST application as a container and point it at an external database and identity source. This route suits teams that want the engine as shared infrastructure without writing a Java service, or that have non-Java callers. The image is generic, so most differences between environments come from external configuration and the database, not from rebuilding the image.
- Image contents: the generic REST application, with process definitions usually deployed through the API or a pipeline.
- Configuration: database type, JDBC settings and authentication mode are set externally, which keeps one image across environments.
- Probes: probe the REST application's HTTP health path, after confirming the path in the version you run.
- Security: the default accounts and authentication mode need to be changed before the service is reachable from the cluster network.
- Scaling: several replicas can share one database, and the async executor coordinates job pickup between them.
Confirm the health path, default credentials and supported database drivers for your exact release in the Flowable configuration documentation before writing probe definitions.
A custom image runs the Flowable WAR or the engine JARs inside a servlet container you choose, such as Tomcat or Jetty. The Flowable getting started guide lists servlet containers as a supported embedding option, so this route fits teams that already standardize on a servlet base image, or that need the engine deployed alongside other web applications. The image build is your responsibility: you pick the container version, add the JDBC driver, and assemble the WAR or libraries. Compared with the other two routes, more of the packaging, patching and probe wiring falls to your platform team.
- Image contents: the servlet container, the Flowable WAR or libraries, the JDBC driver and your models and classes.
- Configuration: externalize the properties file or environment settings so the image stays the same across stages.
- Probes: the readiness check must wait for the engine and database connection, not just for the container to start.
- Patching: base image updates for the container and the Java runtime become a recurring build task.
- Compatibility: the container version must match the Java and Jakarta baseline of the Flowable release.
Before committing, ask the vendor or your platform team which container version the chosen Flowable release supports, and who will rebuild the image when the base layer receives security updates.
The three routes differ less in what Flowable does than in who owns the image, the configuration and the upgrade. A Spring Boot application gives the most control over engine behavior and ties releases to application code. The REST container gives a shared service with the fewest packaging decisions. A custom servlet image gives a fixed container standard at the cost of more build and patch work. Whatever route you pick, the probe design must match what the process reports at startup, because a pod that is alive but cannot reach its database will still receive traffic.
- Ownership: decide whether developers, the platform team or a shared service team builds and patches the image.
- Model delivery: decide whether process definitions ship inside the image or are deployed separately from a pipeline.
- Probe scope: readiness should reflect database reachability and engine startup, not only process liveness.
- Upgrade path: plan for the Java, Spring and Jakarta baseline each Flowable major version requires.
- Exit cost: a service-style deployment is easier to replace than an application that embeds the engine.
Write the chosen route into the deployment design, then confirm each step against the release notes for the Flowable version you plan to run.
Configuration options and when each one fits
This table compares the configuration choices that shape a Flowable pod on Kubernetes, from database type to image tag. Read each row as a decision: the trade-off determines whether the value suits a demo, a single replica or a production cluster. Exact property names, defaults and limits must be confirmed in the Flowable configuration and Spring Boot documentation for your version before you set them.
| Option | Trade-off | When it fits |
|---|---|---|
| Database type | H2 is in-process and resets with the pod, so state is lost on restart. MySQL versions below 5.6.4 lack millisecond precision, which affects timer and job ordering. | H2 for local demos only. Choose MySQL, Oracle, PostgreSQL, DB2 or Microsoft SQL Server for any cluster where pods share state, and confirm the driver and version in the configuration docs. |
| Connection pool size per pod | Each pod opens its own pool, so total connections grow with replica count. Too small a pool slows job execution, too large a pool exhausts the database. | Size per pod against the database connection limit divided by planned replicas, then load test. Confirm the pool property names for your datasource library. |
| Async executor settings | Thread pool size and lock timing control how many jobs a pod runs in parallel and how quickly another pod recovers an expired lock. | Keep defaults for first deployments. Tune only after measuring job backlog, and confirm the lock and thread pool properties in the advanced docs. |
| Replica count | More replicas add job throughput and availability, but every replica competes for the same jobs and rows in the shared database. | Start with two or more replicas when uptime matters, since the async executor coordinates nodes through the database. Scale after verifying database capacity. |
| Actuator exposure at /actuator/flowable | The endpoint reports on running processes, so it can reveal operational detail to anyone who can reach it. | Expose on the internal management port only, behind a Kubernetes network policy. Confirm the exposure properties in the Spring Boot docs for your starter. |
| Image version pinning | A floating tag can pull a new major version during a rollout. Flowable 8.0.0 requires Spring Boot 4 and removes Spring Boot 3 support, while the 7.x line uses Spring Boot 3. | Pin an exact tag from the 8.0.0 or 7.x line and upgrade deliberately. Confirm the Java and Spring baseline in the release notes before choosing. |
How the async executor shares jobs across pods
The async executor is the component that decides which pod runs a given timer or asynchronous job, so it determines whether several Flowable pods on one database add capacity or simply compete. Flowable runs timers and asynchronous jobs from a thread pool inside each node, and it coordinates the nodes through lock owners and lock expiration times stored in the database. When a node picks up a job, it writes its own identifier as the lock owner and a lock expiry into the job row. Other nodes skip jobs that are locked and not yet expired. Because all coordination happens in the shared schema, every pod pointing at the same database must see the same job tables, and the database clock and transaction behavior must be dependable enough for those lock writes to mean something.
Expired locks are the recovery path. If a pod crashes or is evicted in the middle of a job, its lock is never released, but once the expiration time passes, another node can acquire the job and run it. That is the main reason a Kubernetes rollout does not strand timers, and it is also why a job may run more than once if the original pod had already done part of the work. Your process delegates and service tasks should be written so that repeating them is safe, and your team should test a forced pod kill during a timer firing to confirm the behavior in your own environment. Review the async executor settings in the Flowable advanced documentation, since the lock duration and the wait between job acquisition attempts are the values that decide how long recovery takes.
Before you scale beyond one replica, confirm four things. First, the connection pool size on each pod multiplied by the replica count must stay below what your database accepts, and the thread pool size must not exhaust the pool, because a waiting job thread holds nothing useful. Second, every node must run with a clock that is synchronized with the others, since lock expiry is compared against time values written by different pods. Third, the lock duration must be longer than the slowest legitimate job, or healthy work will be taken over mid-run. Fourth, confirm that your database settings, including isolation level and the precision of timestamp columns for your engine version, match what the Flowable configuration docs describe for your chosen database. Write these values into the deployment manifests and load test them before the first scale-out.
Setup sequence for Flowable pods on a cluster you run
This sequence takes a Flowable engine from a verified cluster baseline to several pods sharing one database, with each step closed by a check so the team knows it is safe to move on.
Confirm the cluster baseline and version support window
The platform team confirms the Kubernetes minor version in use is still inside the project's support window, checking the current list on the Kubernetes releases page, and that the API server is upgraded before kubelets under the version skew policy. Confirm the control plane runs on a highly available topology if the cluster is self-built, and record the etcd backup plan. Done when the team has a written baseline showing the cluster version, support end date and backup owner, and the same version will be used in staging and production.
Build or pin the Flowable container image
The platform or application team chooses the Flowable release line that matches its Java, Spring and Jakarta baseline, then either builds an image from the Flowable artifacts or pins a published image by version tag rather than a floating tag. Check the release notes for the chosen version before pinning, since major releases change the required Spring Boot and Java versions. Done when the image reference, digest and Java runtime are recorded in the deployment repository and the image starts locally with the expected version in its startup log.
Provision the database and assign schema ownership
The DBA or platform team creates the database, a dedicated application user and the connection path from the cluster, and decides who owns schema creation and upgrades. Confirm the database type is on Flowable's supported list and that MySQL users are on 5.6.4 or later for millisecond precision. Decide whether the engine creates tables at startup or whether DBA-managed scripts run first. Done when a test connection from a pod-like network location succeeds and the schema owner is written down.
Configure secrets and externalized settings
The team moves JDBC URLs, database credentials and any identity settings into Kubernetes Secrets and ConfigMaps, not into the image. Because Secrets are stored unencrypted in etcd by default, confirm encryption at rest is enabled and restrict read and list access with RBAC, or use an external store through the Secrets Store CSI Driver. Set the default Flowable accounts to new credentials. Done when the pod spec references the secrets by name, no credential appears in the image or manifests in plain text, and a deployed pod reads the values without errors.
Set liveness and readiness probes from actuator
The team enables the Spring Boot actuator health endpoints in the Flowable application and points the liveness and readiness probes at them. Liveness should only confirm the process is responsive, while readiness should reflect whether the engine and database are ready to take traffic. Set initial delays long enough for schema creation on first start, and confirm the flowable actuator endpoint is exposed only where intended. Done when a probe check returns healthy on a running pod and a deliberately stopped database connection makes readiness fail.
Deploy a single pod and confirm the engine starts
The team deploys one replica with the chosen image, configuration and probes, then reviews the startup log for schema validation, a completed engine initialization and no unresolved bean errors. Deploy one simple process definition through the REST API or auto-deployment to confirm the engine accepts models. Done when one pod runs ready, the test process starts and completes, and the job executor logs show it is active on that node.
Scale to several pods and verify job pickup
The team scales the deployment to at least two replicas that share one database, then starts timer or asynchronous jobs that must be executed. Check that the async executor logs on both pods show lock owners taking turns, and that no job runs twice. Next, stop one pod while a job is locked and confirm that after the lock expiration time another pod picks the job up. Done when a successful job run is visible across both pods and the lock recovery test completes without a stuck job in the database.
Apply rolling updates and record the result
The team runs a rolling update to a new image tag while jobs are running, watching readiness, the job queue and error logs throughout. Confirm the update respects the pod disruption and surge settings the team chose. Record the procedure, the rollback image and the result so the next update repeats the same checks. Done when the rolling update finishes with all replicas ready, no failed jobs introduced and a documented rollback path tested in staging.
How rolling updates and schema changes interact
Can pods running different Flowable versions share one database during a rolling update?
Do not assume it. The Flowable material available for this page does not say whether mixed versions can run against one schema, so confirm that with Flowable before you plan an overlap. The risk is concrete: the async executor coordinates nodes through lock owners and lock expiration times stored in the database, so an old pod and a new pod can both pick up timers and asynchronous jobs from the same tables. A rolling update creates that overlap by design. Treat the overlap window as a test case in a staging environment that mirrors production. Start one new pod beside the old ones, let jobs flow, and watch for failed or duplicated jobs. If the overlap is not supported, change the rollout strategy, for example by stopping old pods before new ones start, and accept a pause in job processing during the change.
Does moving to Flowable 8 change how container images are built?
Yes. Flowable 8.0.0 moves to Spring Framework 7 and Spring Boot 4, and its release notes state there is no backward compatibility for Spring Boot 3. A custom image built on a Spring Boot 3 application cannot simply swap the Flowable version tag. Rebuild the application image from the new dependency set instead of patching the old one. Jackson 3 is now the default JSON library, with a Jackson 2 compatibility layer, so custom serializers and JSON handling need review. JUnit 3 and 4 support was removed, so test suites and build plugins that depend on them must move to a supported runner. Pin the image digest that passed these tests, and confirm the minimum Java version for 8.0.0 in the release notes before you choose a base image.
Which Java baseline applies to Flowable 7 and 8 container images?
Flowable 7.0.0 moved to Java 17, Spring Boot 3 and Jakarta EE, so a base image for version 7 must provide at least that runtime. For Flowable 8.0.0, the release notes describe Spring Framework 7 and Spring Boot 4, but the Java minimum for that version should be confirmed in its release notes and in your own build before you choose a base image. Check that your application code and libraries compile and run on that level. Version 7.0.0 also removed the UI applications, the form and content engines, Mule integration and async history, so an image that depended on any of them needs changes. Keep a separate base image for each major version so that a rollback can point to the previous one.
When must a schema upgrade finish before new pods start?
Before the first new pod connects to the database. New engine code expects the new tables and columns, so it must not start against an old schema. Run the upgrade as a controlled step before the Deployment changes. Old pods that still serve traffic during the rollout expect the old schema, so each schema change has to work with both versions for the length of the overlap, or the overlap has to be removed. Check how your configuration controls schema updates at startup. If each pod can alter the schema on boot, the first pod to start changes the database for every other pod, which makes the change hard to review and hard to roll back. Many teams run the schema scripts through a DBA or a pipeline step first. Confirm the exact upgrade scripts for your database and Flowable version in the Flowable documentation.
How do you roll back a failed Flowable release on Kubernetes?
Kubernetes can return a Deployment to its previous image, but it cannot undo database changes. A rollback is safe only when the schema still works with the previous version. Before the release, take a database backup and record the image digest of the running version. Keep schema changes additive during a release so the old pods can still run, and remove any destructive step in a later release. Check which process, case and decision deployments the new version created, because running instances may already depend on them. Confirm with Flowable whether schema downgrades are supported for your version pair. Rehearse the rollback in staging with a copy of production data before you rely on it.
What do the Flowable 8.0.0 release notes say about compatibility changes?
The Flowable 8.0.0 release notes list three compatibility changes that affect deployment:
- Spring Boot 4 and Spring Framework 7: the upgrade has no backward compatibility for Spring Boot 3.
- Jackson 3 as default: Jackson 3 is the default JSON library, with a Jackson 2 compatibility layer.
- JUnit 3 and 4 removed: test code that relies on those versions must be migrated.
Read these changes against your application code before you change the image or the database. Version 7.0.0 also removed the UI applications, the form and content engines, Mule integration and async history, so teams moving from older releases should check those dependencies as well. Confirm any change that touches your configuration or persistence layer with the release notes for the exact version you deploy.
Does the Kubernetes version skew policy limit Flowable rolling updates?
Not directly. The skew policy governs Kubernetes components, not Flowable versions, but it shapes the cluster work that happens alongside a release. Upgrade kube-apiserver one minor version at a time, before kube-controller-manager, kube-scheduler and kubelets. Kubelets may be up to three minor versions older than kube-apiserver. Schedule cluster upgrades in a separate change window from Flowable releases so that a failure can be traced to one change. Confirm that your Kubernetes distribution supports the cluster version you plan to run, and check the Flowable image's runtime requirements before you combine the two changes.
What drives the effort and cost of a Flowable upgrade with schema changes?
No single figure applies to every upgrade, so ask for one in a written scope. The main drivers are the application code: Spring Boot 3 applications need migration, and custom delegates, JSON handling and test suites all need review. Database type matters, since Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server, and each has its own schema path. Running instances and history volume affect how much rehearsal is needed. One-time work includes code changes, image rebuilds, schema scripts and rollback rehearsal. Recurring work includes patches, Kubernetes upgrades and regression testing. When requesting a quote, ask what testing is included, whether a rollback rehearsal is part of the scope, and who runs the production change window.
Security and operational controls for the cluster
A Flowable engine on Kubernetes inherits the security posture of the cluster around it. The controls below cover who can operate the cluster, how Flowable's own credentials and identity settings are stored, and how running processes are watched once the pods are live.
Operator authentication options
Kubernetes does not store normal users as API objects. It relies on X.509 client certificates, bearer tokens including OpenID Connect and JWT, webhook token authentication, or an authenticating proxy. Decide which method your operators use before the cluster is shared, and confirm that offboarding removes access in your identity provider, since a certificate or token issued outside it may outlive the person.
Secrets stored unencrypted by default
Kubernetes Secrets are stored unencrypted in etcd by default. Flowable database passwords, identity service credentials and mail settings usually end up in Secrets, so confirm that encryption at rest is enabled for etcd, or that the values come from an external store through the Secrets Store CSI Driver. Ask who can read etcd snapshots, because those backups hold the same data.
Least-privilege RBAC on Secrets
Limit which service accounts and people can get, list or watch Secrets in the namespace that runs Flowable. List and watch access can expose every value in a namespace even when get is restricted, so grant those verbs only where a controller needs them. Check that the Flowable deployment uses its own service account rather than the namespace default, and review role bindings after each upgrade.
Pod Security Standards and CIS benchmark
Apply the Pod Security Standards to the Flowable namespace, starting with the restricted profile where the image allows it, so pods run without privilege escalation and with a non-root user. Use the CIS Kubernetes Benchmark as a reference for cluster configuration checks. Both are references for your own review, not certifications, so record which checks you ran and which you accepted as exceptions.
Database credentials and identity configuration
Flowable connects to its database with JDBC settings that include a username and password, and its identity service can be replaced with a custom implementation or an LDAP-based reference. Keep both sets of credentials out of image layers and plain ConfigMaps, rotate database passwords through a planned process, and confirm that identity service settings are reviewed as part of every release, because they control who can start and act on processes.
Monitoring running processes through actuator
With the Flowable Spring Boot starters, the actuator endpoint at /actuator/flowable exposes information about running processes. Decide who can reach this endpoint, keep it off public ingress, and wire its data into your monitoring stack. Confirm which fields it returns in your engine version, since the data reflects live process state and can reveal business activity.
What running Flowable on Kubernetes costs and requires
What drives the cost of running Flowable on Kubernetes?
The main cost drivers are who operates the cluster, who operates the database, how identity is integrated, and how many engines and pods you run. Flowable itself is open source under Apache 2.0, so the license is not the cost line. Cluster ownership matters most: if your platform team already runs supported clusters, the Flowable work is mostly packaging, configuration and testing. If not, the cluster build and its upgrade cadence become part of the scope. Database operations, backups and connection pool sizing add effort, as does each additional engine that needs its own deployment and probes. Ask any partner to split the quote by these components so you can see which parts you can absorb internally.
Can our platform team run Flowable on Kubernetes without outside help?
Yes, many platform teams can, provided they already operate Kubernetes and a supported relational database. The work needs skills in container images, Helm or manifests, JDBC connection pooling, Spring Boot actuator probes and rolling update practices. The Flowable-specific knowledge that is easy to miss is the async executor: multiple pods share one database and coordinate jobs through lock owners and lock expiration times, so pool sizes and pod counts must be planned together. Teams without that experience usually benefit from a short review of the design before go-live. Assess your own skills honestly against each item in the build sequence, and confirm the Flowable version and Spring Boot baseline in the release notes before you commit.
How long does a Flowable Kubernetes deployment take, and what sets the timing?
No duration can be stated here without a written scope, so ask for a timeline tied to specific deliverables. The timing is set mainly by the state of the cluster and the database when the work starts, by how many engines and environments must be promoted, and by how long your database and identity owners take to approve schema changes and credentials. Work that depends on a cluster you have not yet built or hardened usually takes longest. Release cadence also matters: Kubernetes ships a few minor versions a year and supports only the three most recent, so an upgrade plan can extend the schedule if your cluster is behind. Ask the partner to list the approvals and handoffs on the critical path.
What do we need to provide for a Flowable Kubernetes engagement?
The engagement needs four kinds of access and input from your side:
- Cluster access: a namespace or cluster in which the engines will run, with rights to create deployments, services, secrets and probes, and a path to lower environments.
- Database owner: a DBA or database team that provisions the database, the schema approach and backups, and that signs off on pool limits.
- Identity owner: the person who controls the identity provider and any LDAP or directory the Flowable identity service will read.
- Release process: the change approval path, the image registry and the pipeline that deploys process definitions.
Confirm early who holds each role, because delays usually come from these owners rather than from the engine.
What should we ask for in a fixed-scope quote for Flowable on Kubernetes?
Ask for a written scope that names each deliverable, the environments covered, and the acceptance checks. The quote should list the Flowable version and Spring Boot baseline, the deployment topology, the number of engines and pods, the database type and version, and the probe and rolling update configuration. Look for explicit lines for knowledge transfer, runbooks, and any follow-on support, which is typically offered as a separate retainer. Ask what is excluded, such as cluster provisioning, cluster hardening, identity integration or history data migration. Also ask which assumptions the price depends on, so changes can be handled through a written change request. Clear exclusions protect both sides.
Which costs are one-time and which recur after go-live?
One-time costs cover design, building the container images and manifests, database setup, identity integration, testing and the first production rollout. Recurring costs cover running the cluster, patching the engine when a new Flowable version is released, keeping up with Kubernetes minor version upgrades, database backups and capacity growth, and monitoring the actuator endpoint. Kubernetes minor versions are supported for a limited window, so the upgrade effort recurs on a predictable cycle. Ask whether a quote includes an upgrade plan for future Flowable and Kubernetes versions, and whether ongoing support is a retainer or hourly work.
Does running Flowable on Kubernetes change our security and audit workload?
It adds controls you must own. Kubernetes stores Secrets unencrypted in etcd by default, so encryption at rest, least-privilege RBAC on secret list and watch access, and a method for database credentials must be part of the design. Pod security settings and the CIS Kubernetes Benchmark provide a reference for cluster hardening, and you should confirm the control IDs your auditors use. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors issue any audit report or certification. Ask the partner which evidence they will hand over and which controls remain with your team.
Where to read the official documentation
Start with the Flowable configuration documentation, because the database settings, supported database types and schema behavior decide most of what your Kubernetes manifests must carry. Read the Flowable configuration docs before you write the datasource environment variables, and confirm which database type and version your platform team will run. Then read the Spring Boot chapter in the Flowable Spring Boot docs to confirm the actuator endpoint at /actuator/flowable and the starter you chose, since probe paths and exposed endpoints depend on that choice.
Read the Flowable advanced documentation for the async executor, which is the part of the design that changes when you run several pods against one database. Its lock owner and lock expiration behavior determines how a rolling update interrupts jobs in flight, so review it before you set replica counts or termination grace periods. Also read the Flowable 8.0.0 release notes if you are choosing a version, because they state the move to Spring Framework 7 and Spring Boot 4 without backward compatibility for Spring Boot 3, which affects your base image and build.
For the cluster side, read the Kubernetes version skew policy before you schedule any control plane or node upgrade, because it sets the order in which kube-apiserver, the controller manager, the scheduler and kubelets must move. Then read the kubeadm high availability guide if your team builds its own control plane, and confirm with your platform owner which topology and load balancer they run. Plan a pre-production check against each documented step so the upgrade sequence is tested before it touches the Flowable database.
How DeployOpen scopes and supports Flowable on Kubernetes
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including Flowable engines on Kubernetes. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory the Flowable engines, REST application and Spring Boot services that will run as pods
- Confirm the database engine, version and pool sizing that every replica will share
- Record the async executor, health probe and rolling update requirements in the written scope
- Agree which Kubernetes distribution, cluster topology and etcd backup arrangements are in scope
How we build
- Build container images and manifests that match the Flowable version and Spring Boot baseline you select
- Configure database connectivity, connection pooling and actuator health probes for each deployment
- Test several pods sharing one database, including lock expiry and job pickup across nodes
- Rehearse rolling updates and rollback on a non-production cluster before the production change
How we hand over
- Deliver manifests, configuration, runbooks and the test evidence agreed in the written scope
- Document upgrade steps, Kubernetes version skew checks and etcd backup and restore procedures
- Walk your platform and engineering teams through the operating model before handover
- Record the secrets handling, access and RBAC decisions your security team needs to review
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Retainers can cover Flowable version upgrades, Kubernetes minor version upgrades and patch cycles
- Ask any partner for the support scope, response arrangements and exclusions in the written quote
- Confirm with your own team who owns cluster operations, database backups and on-call escalation
