Self-hosted Appian alternative without Kubernetes

Why a self-hosted Appian alternative without Kubernetes is a constraint decision

If you run self-managed Appian on 25.3 or earlier, you are on a version that keeps receiving hotfixes for its support lifetime, but you cannot move to 25.4 or later without migrating to Appian on Kubernetes or Appian Cloud. Flowable is the open-source engine that runs on plain servers or containers, so it can replace the process execution layer without a Kubernetes cluster. The rest of the work is a rebuild of the low-code layer: Appian's process models, interfaces and records do not carry over as-is, and your developers will build the screens, forms and data access that Appian currently provides.

The constraint decision is therefore about where you want to stop. Appian's documentation states that 25.3 is the last version supporting non-containerized deployment, so staying on Appian without Kubernetes means accepting a fixed version boundary, while an alternative means accepting a rebuild. Before you choose, confirm with Appian which hotfix and support dates apply to your exact version, and list which Appian features your processes depend on, such as records, sites, plug-ins and integrations, because each one changes the size of the rebuild.

This page covers self-managed deployments only and does not cover Appian Cloud, which Appian operates for you and which is a separate decision with different cost and control trade-offs. It also assumes your team can run a Java application server or container platform on infrastructure you already control. If you lack that capability, confirm the operations work your own staff would absorb before the rebuild starts, and ask any implementation partner to state in writing which components they will run and support.

What the no-Kubernetes constraint requires from the replacement

Moving off self-managed Appian before 25.4 removes the Kubernetes requirement, so the replacement has to run on plain servers or containers you already operate. The cards below cover the runtime, database, node coordination and identity decisions that determine whether Flowable fits your environment.

Plain server or container deployment

Flowable can be embedded as a JAR in Java SE applications, servlet containers such as Tomcat or Jetty, Spring applications and Java EE servers, or run as the standalone Flowable REST application. Choose the packaging that matches your current operations, because it decides what your team patches and monitors. Confirm with your platform team whether a Kubernetes-free deployment matches your change control, load balancer and backup procedures. Any Kubernetes-based operations you already have are optional rather than required here.

Java runtime and framework versions

Flowable 7.0.0 moved to Java 17, Spring Boot 3 and Jakarta EE. Flowable 8.0.0, released on February 27, 2026, upgraded to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3. Pick the major version against the JDK and application server your organization already supports. Test the version on your application stack before committing, since a Spring Boot 3 application cannot move to Flowable 8 without changes.

Supported relational database

Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server. H2 suits development and tests only. Confirm which database your organization already backs up, patches and audits, because the process state, history and job tables will live there. For MySQL, confirm the server version, since versions below 5.6.4 lack millisecond precision.

Node coordination for the async executor

The async executor runs timers and asynchronous jobs from a thread pool. When several nodes run, they coordinate through lock owners and lock expiration times stored in the database, so expired locks are recovered and jobs are picked up by other nodes. Without an orchestrator restarting pods, your team must decide how many nodes run, how they are load balanced and how a failed node is detected. Test node failure during timer-heavy processes before go-live.

Identity replacement with IdmIdentityService

Flowable does not bring your Appian user directory. You replace identity management by overriding IdmIdentityServiceImpl or implementing the IdmIdentityService interface, and Flowable provides an LDAP identity service as a reference. Map your Appian groups and roles to Flowable groups before writing the adapter, and confirm how task assignment and candidate groups will resolve for each process. Identity is also where access reviews and audit evidence come from, so agree the design with your identity team first.

Which open-source engines fit a no-Kubernetes estate

Flowable is an Apache-2.0 Java engine for BPMN process execution, CMMN case management and DMN decision rules. It meets the no-Kubernetes constraint directly because it can be embedded as a JAR in a Java SE application, a servlet container such as Tomcat or Jetty, a Spring application or a Java EE server. It can also run as a standalone service through the Flowable REST application, so your Appian nodes can move to application servers or containers you already operate.

Deployment choice: Embed the engine in your own services or run the REST application as a separate tier, so the topology follows your existing servers.
Multi-node coordination: The async executor stores lock owners and lock expiration times in the database, so jobs held by a failed node are picked up by another. Treat the shared database as a critical dependency.
Databases: H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server are supported. MySQL versions below 5.6.4 lack millisecond precision.
Version currency: Flowable 8.0.0 (February 27, 2026) moved to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3. Check your application stack before you choose a release line.
Commercial scope: Visual modeling, visual debugging and governance sit in the commercial products (Flowable Work, Engage, Orchestrate and Design). Open-source users get a community forum, and professional services come separately. None of this replicates Appian's low-code designer, so your team builds the task screens.

Confirm the Java, database and Spring Boot versions your platform team supports before you pick a Flowable release.

How to deploy Flowable without Kubernetes, step by step

This sequence takes a self-managed Appian team on 25.3 or earlier from version checks through a parallel-tested Flowable deployment on plain servers or containers. It sets the order of work so the cutover happens before the Appian hotfix window closes.

Confirm Flowable, Java and database versions
The platform engineering lead checks the target Flowable release against the Flowable 8.0.0 release notes and the configuration docs before anything is installed. Flowable 8.0.0 moved to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3, and version 7 requires Java 17 or later, so the team must confirm which Spring generation its application code and build tooling use. The configuration docs list the supported databases, including H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server. Done means a signed-off version matrix that names the Java runtime, Spring generation, database and application server for every environment. Confirm the Appian hotfix window for your current version with Appian at the same time.
Choose embedded or REST deployment
The architect decides how Flowable runs: embedded as a JAR inside a Spring, servlet container (such as Tomcat or Jetty) or Java SE application, or as a standalone service through the Flowable REST application. Embedded deployment suits teams that already run Java services and want task screens inside their own applications. The REST option suits teams whose front end calls process APIs over HTTP, which matches the way many Appian customers already integrate. Document the choice per process, since the two patterns affect how the Spring Boot starters are chosen. Done means a short architecture decision record approved by the application owner and security lead.
Provision the shared database and precision settings
The database administrator creates a shared schema for the engine on a supported database and sets it up for timestamp accuracy. The Flowable configuration docs note that MySQL versions below 5.6.4 lack millisecond precision, so the team should verify the server version before creating tables. Every application node must point at the same database, because the async executor depends on it. Set backup, access control and connection pool limits according to your own standards. Done means the engine starts against an empty schema on each environment, and a test process instance can be started and queried from the database.
Configure the async executor across nodes
The platform engineer enables the async executor on each node, which runs timers and asynchronous jobs from a thread pool. Flowable coordinates nodes through lock owners and lock expiration times stored in the database, so an expired lock is recovered and the job is picked up by another node. Without this coordination, a node restart or crash can leave timers stuck, so the team should test this deliberately by stopping one node during a timer-based process. Confirm the thread pool and lock settings against the advanced documentation for your load profile. Done means a timer fires exactly once across two nodes and resumes on the surviving node after one is stopped.
Replace identity with LDAP or a custom service
The identity engineer replaces the default identity handling with your directory. Flowable allows the identity management to be replaced by overriding IdmIdentityServiceImpl or by implementing the IdmIdentityService interface, and an LDAP identity service is provided as a reference. Map users, groups and roles from your Appian groups so that task assignment and candidate groups behave as they do today. Test the mapping with real role combinations, including users who belong to several groups and users who leave the directory. Done means a documented mapping table and test results showing that assignments match the Appian baseline for each role.
Wire monitoring through the actuator endpoint
The operations engineer connects the Spring Boot starters to your monitoring stack using the actuator endpoint at /actuator/flowable, which exposes information about running processes. Set access restrictions on this endpoint so that only monitoring hosts and administrators can reach it. Add alerts for stuck jobs, failed jobs and growth in the job tables, using the data the endpoint and database provide. Done means dashboards show running process counts and job backlog for every node, and an alert fires in a controlled test.
Run parallel testing before cutover
The migration lead runs Flowable alongside Appian for the same processes, feeding identical test inputs to both and comparing outcomes, task assignments, timer behavior and integration calls. Record every difference, decide whether it is a defect or an accepted change, and fix the defects before any production data moves. Confirm with your business owners which Appian applications continue to run during the parallel period. Done means a signed comparison report with zero open defects in the critical processes and a dated cutover plan that fits inside your remaining Appian hotfix window for version 25.3 or earlier, as stated in Appian's AoK FAQ.

What changes in migration scope when you skip Kubernetes

Skipping Kubernetes removes the container platform work from your migration, but it does not remove the rebuild. Appian 25.3 is the last self-managed release that runs without containers, and Appian's AoK FAQ confirms that 25.3 or earlier environments can only move to 25.4 or later by migrating to Appian on Kubernetes or Appian Cloud. If you move to Flowable instead, the work that stays in scope is the application itself: process models, Appian interfaces, records and integrations must be rebuilt in a custom front end, and business data must be exported from Appian's data stores into a database you run. Use the Appian on Kubernetes FAQ to confirm which hotfix and support dates apply to your current version before you set a deadline.

Flowable 7.0.0 moved to Java 17, Spring Boot 3 and Jakarta EE and removed the UI applications along with the form and content engines. For you, that means forms and document content are rebuilt, not carried over. Plan a separate workstream for every Appian form, record view and document repository, and decide early whether your front end or a standalone document store will hold them. Flowable 8.0.0 requires Spring Boot 4 with no backward compatibility for Spring Boot 3, so choose the Flowable major version before you start the Java build, not after.

Without Kubernetes, your team owns Java operations directly: JVM and application server patching, database backup and restore testing, the Flowable async executor's lock behavior across nodes, and monitoring through the Spring Boot actuator endpoint. Confirm with Flowable's advanced documentation how many nodes you need and which database you will run. Your migration scope should also cover identity, since Flowable expects you to replace identity management through its IdmIdentityService interface. For the sequence of application moves and export inventory, see the sibling topics on migrating from Appian to Flowable and exporting data from Appian.

Evidence an auditor or regulator will ask for after the move

Once Appian is replaced by a self-hosted Flowable runtime, auditors and regulators will ask for proof that the new system is controlled, tested and understood. The cards below cover the records that connect your pre-cutover Appian state to the Java platform you run after it. DeployOpen prepares this evidence, but independent auditors and certification bodies issue any audit reports or certifications.

Appian version and hotfix history

Record the exact Appian version, the hotfixes applied and the dates they were applied before cutover, since 25.3 or earlier is the last line that supports non-containerized deployment. Keep this with the change tickets that approved each step. Ask whether your environment has any gap between the last hotfix and the freeze date, and document why that gap is acceptable or closed.

Process and integration inventory

Maintain a dated inventory of every process model, case, decision rule, interface and external integration that the Appian application calls or serves. Map each item to its Flowable equivalent or to a documented retirement decision. Auditors use this list to confirm that no business process moved without an owner, a test and a sign-off.

Database and backup configuration

Document the database engine and version Flowable uses, the schema created at startup, the connection settings and the backup schedule with restore tests. Show who can change schema and who holds backup encryption keys. Include the retention period you chose and the last restore test result, because these records answer most data integrity and availability questions.

Identity and access mappings

Produce a table that maps each Appian group, role and administrator to its replacement identity source and Flowable permission scope. Flowable identity management can be replaced through an identity service interface, so record which implementation you chose and how it authenticates users. Reviewers look for removed leavers and dormant accounts.

Async job and timer test results

Keep test evidence for timers, asynchronous jobs and failover between nodes. Flowable's async executor uses lock owners and lock expiration times in the database, so tests should show that an expired lock is recovered and that another node picks up the job. Record the test date, the configuration tested and any failed runs with their fixes.

Java runtime operating records

Name the team that patches the JVM, the application server or container image, Flowable itself and the operating system beneath them. Record the runbook for restarts, upgrades and incident response, and the on-call rota. Since you now operate the Java runtime yourselves, this ownership record is the first document a regulator will request.

Questions buyers ask before choosing Flowable over Appian

What drives the cost of moving off self-managed Appian to Flowable?

The cost is driven by how much Appian work has to be rebuilt, not by the Flowable license, which is Apache 2.0. Costs fall into engineering time for process models, a custom front end, data migration, integration rewrites, infrastructure, and ongoing support. The main drivers are the number of applications, how much of each app depends on Appian's low-code interfaces, the number of integrations, the volume of records and history to carry over, and the Java skills already on your team. Ask any quote to split one-time build costs from recurring run costs, and to state which Appian packages are in scope.

How long does a migration from Appian to Flowable take?

No duration can be stated for your environment without an inventory, so treat any figure you see without one with caution. Duration grows with the same drivers as cost: application count, custom UI volume, integration count, and data volume. Sequencing matters too, because applications with few dependencies can usually move first while those tied to many other systems wait. Ask for a schedule built from a written scope, with milestones for process rebuild, data movement, integration cutover and user acceptance.

What does our team need to provide during the move?

Your team supplies the knowledge of how the Appian applications behave and the access needed to examine them. That includes Appian package exports, process and interface owners who can confirm business rules, the owners of each integrated system, and staff who will approve test results. You also need someone to own the target infrastructure, whether plain servers or containers, along with the database, identity source and monitoring that Flowable will depend on. Confirm these named roles before work begins, because gaps in them are a common cause of delay.

Can our own developers migrate from Appian to Flowable without outside help?

Yes, a capable Java team can run the migration, but the decision depends on whether it has spare capacity and experience with Spring, REST APIs, relational databases and BPMN modeling. Flowable's engines run embedded in Java applications or as standalone services, so the work is ordinary Java engineering rather than a new platform. The harder parts are rebuilding Appian interfaces without a low-code builder and validating business rules that were never written down. Many teams combine internal ownership with a fixed-scope partner for the riskiest parts. Ask each option for a written list of the skills and hours it assumes.

Do Flowable's commercial editions or support change the decision?

They can, because the commercial editions add low-code modeling, visual debugging, security controls, monitoring and governance on top of the same engines, and professional services are sold separately. The open-source edition is Apache 2.0 licensed and includes a community forum, so you can start without a subscription. Whether you need commercial tooling depends on whether your users will model processes themselves and how much governance you require. Ask Flowable for its current edition comparison and support terms, and compare those against the internal effort you would otherwise carry.

Is Operaton or CIB seven a better fit than Flowable?

It depends on your starting point and the skills you want to keep. Operaton is an Apache 2.0 BPMN 2.0 engine born from the Camunda 7 codebase, and its repository describes a compatible REST API, database schema and an OpenRewrite recipe for Camunda 7 migrations, so it suits teams already on that stack. CIB seven is also Apache 2.0 and runs a native BPMN engine inside the JVM, with its own task list and monitoring. Flowable is the better fit when you need BPMN, CMMN and DMN in one engine family with REST APIs. Compare the three on the case management and decision features your applications use before choosing.

What should we check before we commit to a Flowable migration?

Start with an inventory of what Appian actually does for you, not only what you pay for. Confirm which applications, interfaces, integrations and records will move, which will be retired, and which Appian features have no direct equivalent. Check your target database support against the engines you plan to run, and confirm how identity will be handled, since Flowable lets you replace the identity service with your own implementation. Finally, confirm your hotfix coverage on Appian 25.3 or earlier, because that support continues only for that version's lifetime.

Where to confirm the Appian and Flowable facts for your environment

Start by confirming the two Appian facts that drive this whole path: that your installed version is 25.3 or earlier, and that Appian's own documentation still states that 25.4 and later run only on Kubernetes. Check the exact version in your Appian Designer or administration console, then read the Appian on Kubernetes FAQ against that version. Pay particular attention to the hotfix support window for 25.3, because it sets your deadline for a decision. Ask your Appian account team to confirm in writing how long hotfixes will be delivered for your specific version and whether any exceptions apply to your contract.

Next, confirm Flowable compatibility against your own stack rather than against a general summary. Flowable 8.0.0 moved to Spring Framework 7 and Spring Boot 4 and dropped Spring Boot 3 compatibility, while Flowable 7.0.0 moved to Java 17, Spring Boot 3 and Jakarta EE. Read the Flowable 8.0.0 release notes and the Flowable configuration documentation together, and confirm the Java runtime, application server and database versions your operations team supports. Check that your database engine appears in the supported list, and test the specific database version in a non-production environment.

Finally, treat both checks as inputs to a written decision. Record the confirmed Appian version, support end date, Java and database versions and Flowable release line in one document, and have your architects and security team sign off on it. If any item is unclear or depends on a contract term, put it on the list of questions for your implementation partner and your Appian account team before any work is scoped.

How DeployOpen plans a no-Kubernetes Flowable deployment

DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move off Appian 25.3 or earlier to a Flowable engine on plain servers or containers, we start with a written scope that separates the engine work from the application rebuild, so your team can see exactly what changes.

How we scope

Written scope lists which Appian applications, process models and integrations move, and which stay on Appian.
We inventory your Appian packages and identify custom code, plug-ins and data stores that need a decision.
We confirm the target runtime (Java SE, Tomcat, Jetty or Spring Boot) and the database engine before any build starts.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.

How we build

We deploy Flowable engines on the server or container platform you already operate, with no Kubernetes requirement.
We configure the async executor and database locking for every node so timers and jobs recover correctly across nodes.
We connect identity through a supported identity service, such as an LDAP implementation, and document the mapping.
We test process paths, integrations and role-based task access against the scope before cutover.

How we hand over

You receive installation, configuration and runbook documentation for the engines, database and backup procedures.
We document the decisions made during scoping, including which Appian capabilities were rebuilt and which were not.
Operational monitoring, such as the Flowable actuator endpoint, is set up and explained to your operations team.
Knowledge transfer sessions cover upgrade steps, so your team can plan future Flowable version changes.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover Flowable version upgrades, including any framework changes called out in release notes.
Security testing of the deployed applications and APIs can be scoped separately from the migration work.
Confirm with us in the quote which support hours, response paths and upgrade windows apply to your environment.