BPMN Engine
A BPMN engine is the runtime that takes a process modeled in BPMN 2.0 and actually executes it: it holds the state of every running instance, fires timers, waits for messages, dispatches work to your services, and survives restarts without losing its place.
QuantumBPM is a BPMN 2.0 process engine written in Go and built on Temporal for durable execution. It ships as one product with a web modeler, an operations UI, and a DMN decision engine alongside it - not a broker plus a constellation of companion services.
What a BPMN engine has to do
Most of the difficulty in running business processes is not drawing the diagram. It is everything the engine has to guarantee once a process is live and a step takes three weeks.
| The engine's job | How QuantumBPM does it |
|---|---|
| Keep long-running state | Every instance is a Temporal workflow, so state survives process restarts, deploys, and crashes |
| Version models safely | Deploying a definition auto-increments a version per process, running instances stay on the version they started with |
| Wait reliably | Timers, message correlation, and signals are durable, not in-memory timers that die with the pod |
| Dispatch work | Service tasks push jobs to a queue that any HTTP-speaking service can long-poll |
| Recover from failure | Failed steps raise incidents you resolve from the UI, retries and compensation are engine-level, not your code |
| Let operators intervene | Cancel, migrate, modify token state, and resume from a chosen node set |
If you only need to run a sequence of steps with retries, a workflow library is enough. A BPMN engine earns its place when the process itself is the artifact that non-engineers need to read, change, and audit. We wrote about where that line falls in BPMN vs. Temporal and BPMN vs. n8n.
Durable execution on Temporal
Most BPMN engines write their own persistence layer for long-running state. We did not. QuantumBPM compiles a BPMN model into a Temporal workflow, so durability, retries, timers, and history come from a runtime that is already proven at scale.
What that gives you:
- Crash tolerance by default. A process waiting six months on a timer is not holding memory. It is durable state that replays deterministically when it wakes.
- Deterministic replay. The execution trace can be reconstructed exactly, which is what makes the replay slider and debugging after the fact possible.
- Operational maturity you inherit. Backpressure, rate limiting, and worker scaling are Temporal's problem, not a bespoke scheduler we maintain.
If you are already running Temporal, BPMN gives you a visual, auditable, business-readable layer over workflows you would otherwise express only in code. That trade is the subject of Building a BPMN engine on Temporal.
BPMN element coverage
The engine implements the executable subset of BPMN 2.0 that real processes use, not a token sample of it.
| Category | Supported |
|---|---|
| Events | Start, end, intermediate catch and throw, boundary (interrupting and non-interrupting) |
| Event types | Timer, message, signal, error, escalation, compensation, terminate, conditional |
| Gateways | Exclusive, parallel, inclusive (OR-join), event-based |
| Tasks | Service, user, script, business rule, send, receive, manual |
| Structure | Embedded, event and ad-hoc sub-processes, call activities, multi-instance (sequential and parallel) |
| Data | Process variables with a scope chain, I/O mappings, FEEL expressions throughout |
Full element reference with attributes lives in the BPMN elements docs.
Compensation that does not stop at the boundary
BPMN compensation is the saga pattern with reverse-order rollback and snapshot data built into the engine. QuantumBPM propagates compensation across call activities into called processes, and handles recursive sub-process compensation.
This is a real differentiator: Camunda 8 stops compensation at the call activity boundary. If your rollback has to reach into a sub-process you invoked, that difference decides whether the engine does the work or you do. See The Saga Pattern in BPMN and the compensation docs.
External workers in any language
Service tasks do not run code inside the engine. They dispatch jobs to a queue, and any service that can speak HTTP pulls from it, does the work, and reports back. That keeps your business logic in your codebase, in your language, on your deploy cycle.
First-party SDKs cover Go, TypeScript/Node, Python, and Java, and the whole platform is one OpenAPI spec, so anything else is a generated client away.
const worker = client.newWorker({ clientId: 'billing-svc' });
worker.handle('charge-card', async (job) => {
const receipt = await billing.charge(job.vars.get<number>('amount'));
return new Vars().set('receiptId', receipt.id);
}, { maxJobs: 10, lockDuration: '1m' });
await worker.run(ac.signal);
Details in the external workers guide and the SDK reference.
Operating processes that are already running
Modeling is the easy half. These are the controls that matter at 3am:
- Replay slider - scrub through a reconstructed execution trace to see exactly where an instance went and what the variables were at each step.
- Incidents - failures surface as incidents you inspect and resolve in the same UI, with the variables and stack context attached.
- Messages and signals - publish to a running instance from the UI to unblock it.
- Live migration - move running instances to a new process version with an explicit migration plan.
- Resume from state - start a new instance already positioned at a chosen node set, which is how you recover a batch that failed halfway.
- Token modification - insert or cancel tokens via the API.
More in operating live instances.
Running it
One backend service against one Postgres and one Temporal. Self-hosted deployments can optionally split the web UI into its own container, but there is no event-sourced broker and no companion product to operate.
- Local:
docker-compose up, cold start in seconds - Enterprise: Helm chart, per-project schema, namespace and RBAC isolation, any OIDC provider
- SaaS: managed, no infrastructure
One honest limitation worth stating up front: QuantumBPM exposes user tasks through an API for you to embed in your own inbox UI. There is no bundled tasklist product. If you need an out-of-the-box end-user task inbox, that is a gap you would have to fill.
Frequently asked questions
What is a BPMN engine?
A BPMN engine is the runtime that executes a process modeled in BPMN 2.0. It holds the state of every running instance, fires timers, correlates incoming messages, dispatches work to external services, applies retries and compensation on failure, and keeps an audit trail of what happened. The model is the program, and the engine is the interpreter.
Do I need to know Go to use it?
No. The engine is written in Go, but you integrate over HTTP. Service tasks dispatch jobs that any language can pull from, and there are first-party SDKs for Go, TypeScript/Node, Python and Java. The whole platform is one OpenAPI spec, so you can generate a client for anything else.
How does a BPMN engine handle long-running processes and state?
In QuantumBPM every process instance is a Temporal workflow, so state is durable rather than held in memory. A process can wait weeks on a timer or a message without consuming resources, and it survives deploys, restarts and crashes. Because execution replays deterministically, the full trace can be reconstructed afterwards for debugging and audit.
Can I run BPMN processes from TypeScript or Python?
Yes. Processes execute in the engine, and your code implements the work. External workers long-poll for jobs over HTTP, so a Node or Python service can carry out service tasks without a JVM anywhere in the stack. See the JavaScript SDK and Python SDK.
Is QuantumBPM open source?
No, and we would rather say why plainly. Our aim is a ready-to-use product at a fair price, funded well enough to sustain ongoing development, maintenance and support. In this category open source often means open core: a stripped runtime given away while the parts you actually need in production sit behind a licence anyway. We would rather charge fairly for the whole product than publish a hollow core and sell the rest back. That does not mean lock-in. BPMN 2.0 and DMN 1.5 are vendor-neutral OMG standards and FEEL is part of the DMN spec, so your models move to any conformant engine, and our 99.32% DMN TCK pass rate is what makes that portability real rather than theoretical. You can also run the whole platform in your own infrastructure with the Enterprise Helm chart, or evaluate it locally with the Docker dev server without talking to sales.
How is this different from Temporal on its own?
Temporal gives you durable execution primitives in code. QuantumBPM adds the BPMN layer on top: a visual model that non-engineers can read and change, standard event and gateway semantics, engine-level compensation, an operations UI, and a DMN decision engine sharing the same FEEL expression language. If your workflows never need to leave code, raw Temporal is simpler. See BPMN vs. Temporal.