A few years ago, “workflow engine” usually meant a BPMN tool owned by a business-process team. Today it’s a core piece of the application platform. Order fulfilment, payment sagas, infrastructure provisioning and, more and more, AI agents all need the same guarantee: a multi-step process must run to completion even when individual services, networks or machines fail.
Three open-source engines come up most often when teams evaluate options: Dapr Workflow, Temporal and Camunda. They all provide durable, long-running orchestration, but they come from different design philosophies, and the differences matter once you’re running them in production. This guide compares them across the dimensions that usually decide the choice.
The short version
- Camunda fits best when business analysts need to model, read and change processes visually in BPMN, and human task management is central.
- Temporal is a mature, code-first engine with a large community, and a strong option if you’re comfortable running (or paying for) a dedicated workflow cluster.
- Dapr Workflow is a code-first engine built into the Dapr runtime. It runs as a sidecar next to your app, stores state in databases you already operate, and comes with messaging, state and service-invocation APIs in the same runtime.
The rest of this article explains why.
Programming model
Temporal and Dapr Workflow both use the “workflow as code” model. You write orchestration logic in a general-purpose language, and the engine persists an event history so it can replay the code after a failure. Both require the workflow function to be deterministic, and both push side effects into separate units: activities in both cases.
A Dapr Workflow in Python: import dapr.ext.workflow as wf from datetime import timedelta wfr = wf.WorkflowRuntime() retry = wf.RetryPolicy(first_retry_interval=timedelta(seconds=2), max_number_of_attempts=5, backoff_coefficient=2) def order_saga(ctx: wf.DaprWorkflowContext, order: dict): yield ctx.call_activity(reserve_stock, input=order, retry_policy=retry) try: yield ctx.call_activity(charge_card, input=order, retry_policy=retry) except Exception: yield ctx.call_activity(release_stock, input=order) raise yield ctx.call_activity(ship_order, input=order)
The equivalent Temporal code looks very similar. If your team is already comfortable with one, moving to the other is mostly a matter of API names.
Camunda takes a model-first approach. You design the process as a BPMN 2.0 diagram, and the engine (Zeebe, in Camunda 8) executes it. Code shows up as job workers that handle individual service tasks. The big advantage is that the diagram is the process: non-developers can read it, and it doubles as living documentation. The trade-off is that complex control flow such as dynamic loops, data-driven branching or agent-style re-planning is often more natural in code than in a diagram. If you are weighing BPMN against workflow-as-code, it is worth looking at how a Dapr-based durable execution platform handles the same processes in code.
Architecture and infrastructure footprint
This is where the three engines differ most, and where operating costs are won or lost.
Temporal runs as a separate server cluster made up of several services (frontend, history, matching and internal worker), backed by a persistence store (Cassandra, PostgreSQL or MySQL) and optionally Elasticsearch for advanced visibility. Your application workers connect to that cluster over the network. It’s a proven architecture that scales well, but it’s a significant stateful system to run, tune and upgrade. Many teams choose Temporal Cloud for exactly that reason.
Camunda 8 has a similar shape: a Zeebe broker cluster plus supporting components such as Operate, Tasklist and a search backend for process data. It’s powerful, but it’s also a platform of its own.
Dapr Workflow takes a different approach. The workflow engine is embedded in the Dapr sidecar that runs next to each application instance, so there’s no separate workflow server to deploy. Workflow state is stored in a pluggable state store, which can be PostgreSQL, Redis, Azure Cosmos DB, MongoDB and others, so you can often reuse a database your platform team already operates. Dapr’s control plane handles actor placement and scheduling, but workflow execution itself happens next to your code, which cuts network hops.
For teams already running Dapr for pub/sub or service invocation, adding workflows costs almost nothing in infrastructure. For teams starting from scratch, the question is whether a sidecar model fits their platform. It fits naturally on Kubernetes, and Dapr also runs self-hosted on VMs.
Language support
- Temporal has official SDKs for Go, Java, TypeScript, Python, .NET, PHP and Ruby.
- Dapr Workflow has official SDKs for .NET, Java, Python, Go and JavaScript. The rest of the Dapr API is available over HTTP and gRPC from any language.
- Camunda job workers can be written in any language with a Zeebe client, with official clients for Java and a REST API. The process logic itself lives in BPMN rather than code.
Beyond workflows: what else you get
Workflow engines rarely stand alone. A payment saga also needs to publish events, call other services and store state.
Temporal and Camunda focus on orchestration and leave messaging, service discovery and state management to other tools. Dapr is a broader distributed-application runtime, and workflows are one building block alongside pub/sub messaging, state management, service invocation with mTLS, secrets, configuration, distributed locks and bindings to external systems. A workflow activity can publish to Kafka or call another service through the same sidecar, using the same security and observability setup. Whether that’s an advantage depends on whether you want one runtime or a best-of-breed toolchain.
AI agents and LLM workloads
Agent workloads have become a real selection criterion. Agents are long-running, call unreliable external APIs, and increasingly need audit trails, which makes them a natural fit for durable execution.
All three engines can orchestrate LLM calls as ordinary activities or service tasks. The differences are in the ecosystem around them. Temporal has published integrations for some agent SDKs. The Dapr ecosystem has Dapr Agents, an open-source framework for building agents on top of Dapr Workflow, and vendor integrations that run agents from frameworks like LangGraph, CrewAI and Google ADK on Dapr Workflow without rewriting them. Camunda has put its emphasis on agentic orchestration inside BPMN processes, which suits human-plus-agent business processes.
If agents are on your roadmap, check which frameworks your teams actually use and make sure the engine integrates with them without a rewrite.
Data residency and deployment
For regulated industries this can be the deciding factor. All three engines can be self-hosted. Managed offerings differ, though. A fully managed SaaS workflow service generally stores workflow history, which includes activity inputs and outputs, on the vendor’s infrastructure. If those payloads contain customer data, check where the data lives and whether a bring-your-own-cloud or on-premises option exists.
Pricing and licensing
- Temporal is MIT-licensed. Temporal Cloud is priced on consumption (actions, plus storage), which is easy to start with but can be hard to predict for high-volume or chatty workflows.
- Camunda has changed its licensing over the years. Check the current terms for self-managed production use before you commit.
- Dapr is Apache 2.0 and a CNCF graduated project. Commercial support and managed offerings come from vendors, some with flat per-cluster licensing rather than per-action pricing.
Cost modelling is worth doing with real numbers. A workflow with twenty activities, each with a retry and a timer, can generate many billable actions per execution on a consumption-priced service.
A decision framework
Choose Camunda if:
- Business stakeholders need to read and edit process models directly.
- Human task management, forms and BPMN/DMN compliance are core requirements.
Choose Temporal if:
- You want a mature, dedicated orchestration platform with a large community.
- You’re happy to operate a workflow cluster, or to use Temporal Cloud and its consumption pricing.
Choose Dapr Workflow if:
- You want workflow-as-code without running a separate workflow cluster.
- You’d like to reuse existing databases for workflow state.
- You also need messaging, state and secure service invocation, or already run Dapr.
- You’re building AI agents and want durable execution across several agent frameworks.
Final thoughts
There’s no universally “best” workflow engine, only the best fit for your team’s skills, infrastructure and compliance constraints. Build a small proof of concept with a real process (a saga with compensation and at least one long wait is a good test), then deliberately kill workers mid-run and measure recovery, latency and operational effort. That exercise will tell you more than any feature matrix.
To go deeper, the official Dapr Workflow documentation covers patterns such as fan-out/fan-in, monitors and external events. For a vendor view on how a Dapr-based platform compares with Temporal on architecture, pricing and data sovereignty, see the comparisons published by Diagrid. As with any vendor comparison, test the claims against your own workload.
