Why a self-hosted Bizagi alternative now needs a new engine
Open-source BPMN engines such as Flowable, Operaton and CIB seven can run on your own servers or inside an air-gapped network, so an on-premises requirement no longer has to be met by staying on a cloud subscription. The deciding question is which support and upgrade model your organization can sustain over the life of the platform. Bizagi stopped selling on-premises licenses in 2022 and now sells its platform as a cloud PaaS, so organizations that must keep process automation on their own servers need to choose a new engine and a new operating model together. Start by confirming which obligation drives the decision, because a data residency rule, a regulator and an internal security policy each require different evidence.
The constraint has two parts. First, process state stays on your servers. Instance data, variables, timers and audit history live in the relational database the engine uses, so that database, its backups and its access controls become part of your scope. Flowable, Operaton and CIB seven each support PostgreSQL, Oracle and SQL Server, but supported versions differ, so check each vendor's current database list before you commit. Second, patching sits under your control. You decide when an engine version is upgraded, who tests it and how a fix reaches an air-gapped environment. For an air-gapped build, confirm that Maven artifacts and container images can be mirrored into your internal registries, and record who owns each step before the first pilot process goes live.
The support model is where the three engines diverge. Operaton has no commercial editions and no LTS line. It ships feature releases twice a year with monthly patch releases, each version is supported for six months until the next one ships, and professional support comes from several independent providers. CIB seven offers a free Community edition plus paid Community+, LTS and Enterprise editions. Its FAQ says paid distributions receive security patches and hotfixes every four to eight weeks, but it gives no fixed support duration per edition, so request that term in writing. Flowable's open-source edition includes a community forum, while professional services and its commercial products are offered separately. Map each vendor's release and patch cadence against your own maintenance windows and audit obligations before you choose.
What on-premises process automation requires from the platform
Once Bizagi is only available as a cloud PaaS, the question shifts from features to control: where process data lives, which databases hold instances, who patches the engine, and how users sign in. The cards below set out the requirements a self-hosted engine must meet, and what you still build yourself.
Process data stays in your facility
Process instances, variables, task history and audit records are written to the database and file storage that the engine uses. If you must keep them in your data center or an air-gapped network, confirm that the engine has no required call-home, licence check or telemetry path that needs internet access. Test the install in an isolated network before you commit, and document every outbound dependency, including container image pulls and Maven artifacts for builds.
Databases you operate
Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server. Operaton supports H2, PostgreSQL, MySQL, MariaDB, Oracle, SQL Server and DB2, with minimum PostgreSQL 14, MariaDB 10.11 and MySQL 8.4 in its 2.1 release. Pick the engine that matches the database standard your DBAs already back up, patch and monitor. Flowable also notes that MySQL versions below 5.6.4 lack millisecond precision, which matters for timers.
Patching on your schedule
Self-hosting only helps if you can take an upgrade when your change calendar allows. Operaton ships feature releases twice a year, with monthly patches, and supports each version for six months, with no traditional LTS line. CIB seven's paid LTS editions carry security patches every four to eight weeks. Ask each vendor how long a version receives fixes, whether the patch stream is public, and which upgrade path your current release follows.
Directory and identity integration
Process owners expect their directory accounts and groups to drive task assignment. Flowable lets you replace the identity service by overriding its identity implementation or by writing your own, and it ships an LDAP identity service as a reference. Plan this early, because candidate groups and role mapping decide who sees which work. Test with your actual directory structure, including nested groups and disabled accounts.
Forms and work portal are yours to build
A self-hosted engine executes BPMN, CMMN and DMN models, but it does not bring Bizagi's form designer, work portal or data model. Flowable 7 removed its UI applications, and CIB seven ships task lists and process monitoring, yet forms and screens for your cases still need design and development. Estimate that work separately from the engine, and confirm whether your users need a generic task inbox or custom front ends.
Clustering and job execution
Timers and asynchronous jobs must run once across several nodes, not once per node. Flowable's async executor uses lock owners and lock expiration times stored in the database, so expired locks are recovered and other nodes pick up jobs. Ask your team to test node failure during a timer firing, and confirm that your database supports the locking behavior the engine depends on.
Which open-source engine fits which self-hosted constraint
This table compares Flowable, Operaton and CIB seven against the constraints that come with leaving Bizagi's cloud-only model for self-hosting. Read each row against your own requirements for licensing, support and upgrade cadence, then check the trade-offs before shortlisting. Camunda 7 Community Edition and Camunda 8 Self-Managed production use fall outside this comparison because of their licensing and end-of-life status.
| Option | How it meets the on-premises constraint | Support and upgrade model | Trade-offs |
|---|---|---|---|
| Flowable | Apache-2.0 Java engines for BPMN, CMMN and DMN, embedded in your application or run as a REST service on your servers | Community forum for open-source users; professional services and partners sold separately; commercial editions available | Code-first; forms, UI and business rules must be built by your developers; version 8.0.0 requires Spring Boot 4 |
| Operaton | Apache-2.0 BPMN 2.0 engine with Camunda 7 compatible REST API and schema, deployable as Docker images or Helm charts | Community-governed with no commercial editions; several independent providers offer support; feature releases twice a year with patches monthly, each version supported 6 months | No single company controls the roadmap and governance is still forming; no LTS line, so upgrades must follow the release cadence |
| CIB seven | Apache-2.0 Camunda 7 fork with a native BPMN engine on the JVM and its own task list, process monitoring and user management | Free Community edition; paid Community+, LTS and Enterprise editions with security patches and hotfixes every 4 to 8 weeks; LTS recommended for regulated environments | Paid editions add cost; the FAQ gives no fixed support duration per edition, so confirm terms in writing |
| Camunda 7 Community Edition | Apache-2.0 code, but no longer a viable path for new on-premises work | End of life; repository archived November 4, 2025, with no further community security patches | Avoid for new work; migration to a maintained engine is required |
| Camunda 8 Self-Managed | Self-hosting is possible, but production use requires an Enterprise license | Enterprise license terms govern support and upgrades | Source-available core under Camunda License v1; production self-managed use is a licensed commercial product |
How support and upgrades replace Bizagi's model
Bizagi's support model is bound to its cloud PaaS, so the vendor patches and upgrades the platform on its schedule. Self-hosting moves that work to your team, a commercial edition vendor, or an independent provider, and the first decision is which of those three you are buying. Open-source engines do not come with a support contract by default. Flowable offers a community forum for its open-source edition, with professional services and partners offered separately. Operaton has no commercial editions and relies on several independent service providers. CIB seven sells paid Community+, LTS and Enterprise editions. Confirm each vendor's current support terms, response commitments and end-of-support dates directly with the vendor before you write them into a budget or a risk register.
Upgrade planning is the most concrete cost you will carry, and the versions differ in how much work they demand. Flowable 8.0.0, released on February 27, 2026, moves to Spring Framework 7 and Spring Boot 4, with no backward compatibility for Spring Boot 3. It also makes Jackson 3 the default JSON library with a Jackson 2 compatibility layer, and removes JUnit 3 and 4 support. If your applications run on Spring Boot 3 today, the engine upgrade is also a framework migration, and your custom Java code, tests and serialization must be reviewed. Operaton documents a support window of six months for each major or minor version until the next one ships, with no traditional LTS line. Your patch cadence must therefore keep pace with monthly patch releases, and you should plan a feature upgrade roughly every six months.
CIB seven's paid LTS edition is the option to examine if you need a longer support horizon. The FAQ recommends the LTS edition for high-volume or regulated environments and says security patches and hotfixes are released every 4 to 8 weeks, with urgent fixes as needed. It does not state a fixed support duration per edition, so ask for that figure in writing and compare it with your internal upgrade calendar. Whichever engine you pick, record who owns patch testing, who approves production changes, and who is on call for the database and Java runtime beneath it. These responsibilities replace the single vendor relationship you had with Bizagi.
How to deploy a process engine on your own servers or in an air-gapped network
This sequence takes a team from a confirmed data constraint to a tested, patchable engine running on infrastructure the organization controls, with the same steps applying to connected and air-gapped networks.
Confirm the constraint and data classification
Record which processes must stay on your servers, which data classes they touch (personal, financial, health or citizen data), and whether the target network is connected, restricted or fully air-gapped. Security, compliance and the process owners sign off on this document. You know this step is done when every in-scope process has a named data classification and a network zone assigned, and the signed record sits with the project files.
Select the engine and its edition
Shortlist the self-hostable engines that fit the notation you already use: Flowable for BPMN, CMMN and DMN under Apache 2.0, Operaton for a Camunda 7 compatible BPMN and DMN engine, or CIB seven for a Camunda 7 compatible engine with its own task interface. Confirm the license terms, the edition you need, and whether your team needs paid support or a long-term support line. You know this step is done when a written decision records the engine, the edition and the support model, with the reasons attached.
Choose and provision a supported database
Pick a database from the engine's supported list. Flowable lists H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server. Operaton lists PostgreSQL, MySQL, MariaDB, Oracle, SQL Server and DB2, with minimum versions in its 2.1 release notes. CIB seven lists its own supported versions per engine release. Confirm the exact versions against the vendor's environment page before provisioning. You know this step is done when the database version is on the engine's supported matrix and backups are configured on that instance.
Deploy the engine on your runtime
Choose the packaging that matches your operations model. Flowable can be embedded as a JAR in a Java application, run in Tomcat or Jetty, or deployed as a Spring Boot service. Operaton and CIB seven publish Docker images and Helm charts for Kubernetes, and both also support Tomcat, WildFly and Spring Boot. In an air-gapped network, the platform team builds or pulls the images from an internal registry. You know this step is done when a test instance starts, deploys one sample BPMN model and returns a process instance through its REST API.
Configure the async executor for clustered nodes
If you run more than one node, configure the job executor so nodes share timers and asynchronous jobs through lock owners and lock expiration times in the database. Flowable's documentation describes how expired locks are recovered and picked up by other nodes. Test a node stop during a running timer, and confirm the timer fires once on a surviving node. You know this step is done when the failover test shows no lost or duplicated timer in your logs.
Connect directory identity and monitoring
Replace the engine's default user store with your directory. Flowable documents an identity service interface and provides an LDAP implementation as a reference, so your developers adapt it to your directory and group model. Enable monitoring: Flowable's Spring Boot starters expose an actuator endpoint at /actuator/flowable for running processes. Connect these metrics to your existing monitoring stack. You know this step is done when a test user from the directory can log in with the right groups and the monitoring dashboard shows active process instances.
Mirror dependencies and images into the air-gapped network
For restricted networks, copy every artifact through an approved transfer process: Maven dependencies, container images, Helm charts, database drivers and the JDK. Verify checksums and signatures before import, and keep a record of each artifact version. Illustrative example: a bank mirrors the engine JAR, its Spring Boot starters and the database driver into an internal repository, and rejects any build that pulls from a public source. You know this step is done when a clean build and a deployment succeed with outbound internet access blocked.
Set a patch cadence and test backup and restore
Agree a patch calendar with the security team. Operaton publishes half-yearly feature releases with monthly patch releases and supports each version for 6 months until the next ships, so plan upgrades around that window. CIB seven's paid editions ship security patches every 4 to 8 weeks. Then restore a full backup of the database and the deployed models into a separate environment, and confirm running process instances resume correctly. You know this step is done when a restore test is documented with the date, the versions tested and the outcome.
Questions buyers ask before choosing a self-hosted engine
What does a self-hosted Bizagi replacement actually cost?
The engine license is free for Flowable, Operaton and CIB seven core functions, since all three are Apache-2.0 licensed, so the cost sits in the work around them. The components are hosting and infrastructure (paid to your cloud or data center provider), rebuilding forms, user interface and the data model (paid to developers or a partner), migration of running cases, support contracts (optional, paid to the provider you choose) and internal staff time for operations. Hosting and support recur every year. Rebuild and migration are mostly one-time. Scope size, the number of processes with custom forms, and the volume of open cases drive the total most. Ask any quote to show each component separately so you can compare options on equal terms.
How long does a self-hosted deployment take?
No fixed duration can be stated for this move because it depends on how many processes, forms, integrations and open cases you have. Your timeline should come from a written, scoped plan, not from a generic figure. Ask the engine provider or your implementation partner what the install, rebuild and cutover phases involve, which tasks sit on your side (identity, database, network approval), and which milestones require sign-off. A scoped quote from DeployOpen follows from an agreed written scope, and DeployOpen does not publish a price list or standard timeline.
What does the work need from our team?
Expect the work to need Java developers who can build and deploy BPMN models, a database administrator for the chosen database, an operations owner for the Kubernetes or virtual machine platform, and a business owner who can confirm process rules and forms. Bizagi's visual modeling and built-in work portal are not included in these engines, so you will need front-end developers or a separate task interface if users rely on them. Flowable's commercial editions add low-code modeling, but that is a separate product decision. Confirm with each vendor which tools ship in the open-source edition before you size the team.
Can our own developers do the deployment without an outside partner?
Yes, if your team already runs Java services on your own infrastructure and has the skills listed above. The open-source engines run as embedded libraries, standalone services with REST APIs, or Docker and Helm distributions, so the work is standard software delivery. The risk lies in the parts that are new to your organization: the process model, the rebuilt forms, data migration of open cases and the upgrade routine. Many teams run a pilot with one process first. A partner can take the parts you lack, and DeployOpen offers fixed-scope engagements that agree deliverables and timelines in writing before work starts.
Does each engine support air-gapped operation?
Each engine can run on infrastructure without internet access once its artifacts are copied into your own repository, but you must confirm this per engine for your exact setup. Check that the engine, its Java and database dependencies, container images and any Helm charts can be mirrored into your internal registries and Maven repository, and that no feature calls an external service at runtime. Ask each provider for written confirmation of offline installation and of any licensing or telemetry behavior in air-gapped mode. DeployOpen can test this in an isolated environment as part of the scope.
What commercial support is available for each engine?
Support differs by engine. Flowable sells commercial editions and offers professional services and partners separately, while open-source users get a community forum. Operaton has no commercial editions, and professional support comes from several independent service providers. CIB seven offers free Community, paid Community+, LTS and Enterprise editions, with security patches and hotfixes every 4 to 8 weeks for paid distributions, and its FAQ gives no fixed support duration per edition. Ask each vendor for the support period, response commitments and patch policy in writing before you choose.
How do we upgrade safely given the current release cadence?
Pin a tested version and upgrade on your own schedule rather than following each release. Flowable 8.0.0 was released on February 27, 2026, and it moved to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3, so any application stack change must be planned and tested. Operaton ships feature releases in April and October with monthly patch releases, and each version is supported for six months until the next ships, with no traditional LTS line. Build a staging environment, run regression tests on your process models, and schedule patching as an ongoing task with a named owner. A retainer can cover this routine if you do not want to staff it internally.
Evidence auditors and regulators ask for under this constraint
Once process automation runs on your own servers, the auditor's questions move to your infrastructure: where data sits, who can reach it, what version runs and whether it can be restored. The six items below connect those answers, and DeployOpen prepares this evidence for your assessors. DeployOpen does not issue audit reports or certifications.
Architecture showing where process data lives
A diagram and written description of every component that holds process instances, variables, history, task data and attachments, including the database engine, application nodes and file storage. Name the hosting location of each one, and state whether any component calls out to an external service. Auditors use this to confirm that case data stays inside the boundary you have declared. Confirm the database types you chose against the engine's supported list before you draw the diagram.
Access control and identity configuration
Records of how users, groups and administrators authenticate, which roles can deploy models, edit running instances and view history, and how identities are synchronized from your directory. Engines such as Flowable let you replace the identity service, so document which implementation runs in production and who approved it. Export role assignments on a schedule and keep them with the change tickets that created them.
Patch and upgrade records with versions
A dated register of every version running in each environment, with the upgrade or hotfix that moved it there and the test evidence behind the change. Note the support window for each release line, since open-source projects publish their own cadence and some do not offer long-term support. Your assessors will ask whether any version in production has stopped receiving fixes, so check the release notes before each upgrade.
Backup and restore test results
Evidence that backups of the engine database, model repository and file storage were taken on schedule and that a restore was rehearsed into a separate environment. Record the restore time you measured and whether running process instances resumed correctly. A backup that has never been restored is weak evidence, so schedule restore tests and keep the results with the recovery objectives you agreed internally.
Inventory of components and licenses
A bill of materials listing every engine, library, container image, Helm chart and database driver in the deployment, with its version and license. Permissive licenses such as Apache-2.0 still need to be recorded with their notices. Include any commercial add-on or paid edition, because its terms differ from the community code. Regenerate the list after each upgrade, not only at go-live.
Support agreement in force
A copy of the contract, or a record of the community and vendor channels you rely on, with the scope, named contacts, response expectations and end date. Some open-source engines are supported by several independent providers, and others by a single vendor, so the record should show which model applies to you. Keep it current, because an assessor will ask who fixes a critical defect and on what terms.
What moving off Bizagi's cloud PaaS involves
The core of the migration is that a Bizagi process is not one file. The BPMN 2.0 XML export carries the flow, tasks, gateways and sequence logic, but the forms, business rules, data model, user assignments and extended attributes do not travel with it in a form an open-source engine can run unchanged. Your team should inventory each process into four buckets before any build starts: the diagram, the forms, the decision logic and the data it writes. Decision logic is a good candidate for DMN tables in Flowable, where the engine evaluates rules directly. Forms and the data model will need to be rebuilt in whatever front end and database your organization chooses, and that rebuild is usually the largest effort item. The sibling topics on exporting from Bizagi and migrating to Flowable cover what each export format keeps and drops, so use them for the detail rather than repeating that work here.
Running old and new processes side by side is the step most often underestimated. Bizagi cases that are already open will not disappear when you deploy a replacement, so you need a cutover rule for each process: either let open cases finish on Bizagi until they close, or move them with a documented mapping of their data and current task. Plan for both systems to run in parallel for as long as your longest open case lasts, and keep Bizagi's cloud subscription active for that window, since it is a recurring cost. Confirm with your Bizagi account contact how long read access and exports remain available after your subscription ends, and whether audit history can be exported in a usable form. Record which team owns each process during the overlap, because ambiguous ownership is where stalled cases appear.
Engine choice affects how much of this work is code. Flowable's engines are Apache-2.0 licensed and run embedded in Spring or as a standalone service with REST APIs, but its open-source edition does not include the low-code modeling and work portal that Bizagi users are used to, so your developers build those parts. Before committing, ask each candidate vendor or community which production support, security patch and upgrade commitments they offer in writing, and map those against your own change-control and audit requirements. Operaton and CIB seven differ here, and their support models are covered in the sibling comparison and cost topics. Make a written inventory and a parallel-run plan a precondition of any quote, so that the scope you sign reflects the rebuild work rather than only the engine installation.
How DeployOpen deploys a self-hosted process engine under your constraint
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source process engines inside your own infrastructure, including air-gapped networks where required. For a Bizagi replacement, we start from the constraint that processes, data and approvals must stay on your servers, then choose and build the engine stack that fits it.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We inventory the Bizagi processes, forms, rules and integrations you need to carry over, and mark which ones stay out of scope.
- We confirm the target engine, database, hosting platform and whether the environment must run fully air-gapped.
How we build
- We deploy the chosen engine in your cloud accounts, data centers or isolated networks, with the database and identity integration you specify.
- We rebuild the task interface, forms and monitoring you need, since open-source engines do not ship the Bizagi work portal.
- We test process execution, timers, failover between nodes and integrations against the agreed acceptance criteria before cutover.
How we hand over
- You receive configuration, deployment and runbook documentation written for your operations team.
- We walk your administrators and developers through running, patching and backing up the engine and its database.
- We prepare control and evidence material for your compliance reviews, while independent auditors and certification bodies issue any assessment results.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- We track engine release and support windows so your upgrade plan matches the published schedule for the version you run.
- Ask any provider to confirm in writing the patch cadence, security fix process and support duration for the edition you choose.
