Which open-source durable execution engine fits which team
Start with Temporal if your team must keep long-running business processes alive through crashes, deploys and downstream outages, and your developers will write the workflows in Go, Java, TypeScript or Python. Temporal workflows are ordinary code, and the service keeps a complete ordered event history so a workflow can replay and resume after a failure. That model fits teams that want their workflow logic reviewed, tested and versioned like application code. Before you commit, confirm the operating side: a self-hosted Temporal Service runs Frontend, History, Matching and Worker services plus a persistence store, and the default noopAuthorizer allows every API request until you configure an Authorizer. Plan for mTLS, a ClaimMapper and OIDC for the Web UI from day one, and keep the services off the public internet.
Choose Cadence when your organization wants an Apache-2.0 engine under the Cloud Native Computing Foundation's open governance and your workers are written in Go or Java, the two languages with official SDKs. Cadence has the same workflow-as-code model as Temporal, so the decision often turns on governance and ecosystem rather than programming model. Confirm with the project which SDK and version your team will run, since Python and Ruby SDKs are community-maintained rather than official. Expect a backend of several services plus Cassandra, MySQL or PostgreSQL, and optionally Kafka and Elasticsearch for advanced visibility. The CLI and web UI cover operations, so a team with Go or Java platform skills and a preference for CNCF stewardship will find it a natural fit.
Choose Conductor OSS when much of the process is orchestration across services written in different languages, and you want workflow definitions in JSON that are versioned and inspectable as graphs. Business logic lives in workers in any language, and official SDKs cover Java, Python, JavaScript, Go and C#. This suits platform teams who want non-developers or architects to review the workflow shape without reading worker code. Check the operating footprint before you choose it: the server requires Java 21 or later, you must pick one of its supported persistence backends and a message broker, and a Docker image bundles the server and UI. If you later need vendor support, Orkes offers an enterprise platform that is documented as fully compatible with Conductor OSS.
Which engine to shortlist for each scenario
This table maps common team situations to the durable execution engine most likely to fit, with the supplied fact behind each choice. Read each row as a starting shortlist, then confirm the fit against your own identity, network and operating constraints before committing.
| Scenario | Best fit | Why |
|---|---|---|
| Code-first developer teams writing workflows in general-purpose languages | Temporal | Workflows are written as code in Go, Java, TypeScript or Python, and Temporal keeps an ordered event history used to replay and resume after failures. Confirm the SDK languages your teams use and how your engineers will test replay-safe code. |
| Teams that want workflows as inspectable JSON graphs | Conductor OSS | Workflows are defined in JSON as versioned, inspectable graphs while workers in any language run the business logic. Confirm that a JSON-first model suits your review process and that the official SDKs cover your worker languages. |
| Teams already running Cadence | Cadence | Cadence is Apache-2.0 licensed, a CNCF project, and offers official Go and Java SDKs, so existing workers and operating knowledge carry over. Confirm your current Cadence version and upgrade path against the release you plan to run, such as v1.4.2. |
| Teams that need a managed service | Temporal (Temporal Cloud) or Conductor (Orkes hosted) | Temporal Technologies sells Temporal Cloud, with pay-as-you-go pricing and a 99.9% SLA (99.99% with high availability) per Temporal's pricing page, and Orkes offers hosted Conductor on major clouds. Confirm data residency, SLA terms and quoted pricing directly with each vendor. |
| Teams with strict identity or network requirements | Temporal, if you can supply the security controls | Self-hosted Temporal supports mTLS, a ClaimMapper, an Authorizer plugin and OIDC for the Web UI, but the default noopAuthorizer allows every API request until you configure one. Temporal's docs also advise keeping services off the public internet. Confirm that your IdP, certificate lifecycle and network segmentation can meet your requirements before choosing. |
| Teams that need a fully managed, self-hosted-free operation with minimal platform work | Confirm with each vendor before shortlisting | Self-hosting any of the three requires running a server, persistence and visibility stores, and workers. Ask each vendor for the managed options, operating responsibilities and support terms in writing before deciding. |
How the programming model changes who builds and maintains workflows
The main difference between these engines for staffing is where the workflow logic lives. In Temporal and Cadence, a workflow is ordinary code written in a general-purpose language such as Go, Java, TypeScript or Python, so the people who build and maintain it are the developers who already ship services. The engine keeps a complete, ordered event history and replays it to resume a workflow after a failure, which means workflow code has to be deterministic. Teams should confirm that their developers understand this constraint, because a change that reorders calls or alters logic for in-flight executions can break replay. Code review, unit tests and versioning of workflow code become the main controls, and they belong in the same pipeline as the rest of the service code.
In Conductor, the workflow is a versioned JSON graph, and workers written in any supported language perform the business logic. Official SDKs cover Java, Python, JavaScript, Go and C#, so a team can keep its workers in the languages it already runs while the flow definition stays readable to people who do not write application code. That readability is useful for operations, risk and process owners who need to see the sequence of steps, but it does not remove the need for developers. Someone still has to build and test the workers, manage their deployment, and decide how versions of a JSON definition roll out to running executions. Reviewers should check whether the JSON graph and the worker code change together and whether both are tested before release.
Non-developers can inspect a process in each model, but in different ways. With Temporal or Cadence, the most reliable view is the workflow history and the web UI, which show what the code did; a reviewer usually needs a developer to explain the flow. With Conductor, the graph itself is the primary artifact, so a process owner can often follow the path without reading worker code. Before choosing, ask which group must approve changes, which group must answer an incident at night, and whether the team has the skills to test each model. The Conductor JSON graph is easier to scan, but a team should not assume that scanning the graph is enough to verify what the workers do.
Capability and license comparison across Temporal, Cadence and Conductor
This table sets Temporal, Cadence and Conductor OSS against the same set of decision points, from license and latest supplied release to persistence, SDKs, deployment and managed options. Cells marked to confirm have no supplied fact, so check them with the vendor before you shortlist. Use the table to narrow your options, then read the programming model and operations rows closely because they drive most of the long-term effort.
| Capability | Temporal | Cadence | Conductor OSS |
|---|---|---|---|
| License | MIT (temporalio/temporal) | Apache-2.0 (cadence-workflow/cadence) | Apache-2.0 (conductor-oss/conductor) |
| Latest supplied release | v1.32.1, October 8, 2026 | v1.4.2, October 2, 2026 | v3.32.5, September 25, 2026 |
| Programming model | Workflows as code in Go, Java, TypeScript, Python; replay from ordered event history | Workflows as code with official Go and Java SDKs; workers hold the workflow implementation | Workflows defined in JSON as versioned graphs; workers in any language perform business logic |
| Supported persistence | Cassandra, PostgreSQL, MySQL tested; SQLite for development only | Cassandra, MySQL or PostgreSQL | Five persistence backends including PostgreSQL and Redis |
| Visibility or indexing | Elasticsearch 7 and 8, OpenSearch 2+, MySQL, PostgreSQL or SQLite for advanced visibility; Elasticsearch or OpenSearch recommended at scale | Optional Kafka and Elasticsearch; GKE codelab uses OpenSearch for advanced visibility | Elasticsearch or OpenSearch for indexing |
| SDKs | Official SDKs for Go, Java, TypeScript, Python (confirm the full current list with Temporal) | Official Go and Java; unofficial community Python and Ruby | Official Java, Python, JavaScript, Go and C#; Ruby incubating |
| Deployment methods | Docker Compose, Go binaries, Helm charts on Kubernetes, custom Go build | Official Helm chart from cadence-charts repository on Kubernetes | Docker image bundling server and UI; requires Java 21 or later |
| Managed service option | Temporal Cloud (vendor-sold) | Not stated in supplied facts; confirm with the project or a vendor | Orkes hosted deployments across major cloud providers |
| CLI or web UI | Web UI with OIDC single sign-on (confirm CLI details in the docs) | CLI for workflows, task lists, domains and clusters; web UI for histories and traces | Web UI bundled with the server Docker image (confirm CLI support) |
What each engine ships with for access control and encryption
Temporal's self-hosted security model has a notable default that changes how you plan the first deployment. If no Authorizer is configured, the server uses the default noopAuthorizer, which allows every API request with no authentication or access control. Protection has to be added deliberately, and the supplied options cover several layers.
- Default access: Until an Authorizer is configured, any client that can reach the frontend can call the API.
- mTLS: Self-hosted Temporal supports mutual TLS, with separate settings for internode traffic and frontend traffic.
- ClaimMapper and Authorizer plugin: A ClaimMapper maps JWT or certificate claims to namespace roles, and an Authorizer plugin enforces the decisions.
- OIDC for the Web UI: Single sign-on for the Web UI can be configured through OIDC.
- Payload encryption: Custom codecs and a codec server can encrypt workflow payloads before they are stored.
The deployment documentation also says Temporal services should run on hosts not reachable from the public internet. Confirm the Authorizer and network controls in the self-hosted security documentation before any environment with real data is reachable from a shared network.
The supplied facts for Cadence cover its architecture, SDKs and deployment options, but they do not describe its access control defaults, its authorization model or its encryption options. Do not assume Cadence matches Temporal's controls, or differs from them, until you have checked the sources yourself.
- Access defaults: Confirm whether the server accepts unauthenticated API calls out of the box and what must be configured to change that.
- Authentication and authorization: Check whether the project offers TLS, client authentication, role-based controls or namespace-level (domain-level) permissions, and how they are enabled.
- Encryption in transit and at rest: Check the supported TLS settings for the frontend and internode traffic, and whether payloads can be encrypted by the application or through a codec.
- Persistence and visibility stores: Confirm how the Cassandra, MySQL or PostgreSQL backend, and any Kafka or Elasticsearch components, are secured and which credentials they use.
- Code and configuration: Review the server configuration files and the Helm chart values in the cadence-charts repository, and read the relevant code paths in the cadence-workflow/cadence repository.
Ask the project maintainers or your DeployOpen contact to document the exact settings you will use, and record them in your security baseline before the environment is built.
The supplied facts for Conductor describe its persistence backends, message brokers, SDKs and Java 21 runtime requirement, but they do not describe its access control defaults or its encryption features. Treat the security baseline as an open item until the vendor documentation and code confirm it.
- Authentication defaults: Confirm whether the server and the UI require credentials out of the box and how API access is restricted.
- Authorization model: Check whether workflow and task permissions can be scoped by user, role or application, and where that is configured.
- Transport encryption: Confirm which TLS options the server, UI and workers support, and how certificates are supplied.
- Data protection: Check whether workflow inputs and outputs can be encrypted at the application level and how sensitive data is kept out of search indexes.
- Commercial distinction: Orkes Conductor is the enterprise platform built on Conductor OSS, so confirm in writing which access features are in the open-source server and which come from the paid platform.
Review the Conductor documentation and the conductor-oss/conductor code for the settings you need, then test them in a non-production environment before you rely on them.
Each engine in brief, with its license and managed options
All three server projects in this comparison are open source, so you can run them in your own infrastructure. Temporal Cloud and Orkes Conductor are commercial managed services built around those projects, and each carries its own terms. Each card names the license, the main model and one condition under which that option is the better choice.
Temporal Server (MIT)
Temporal Server is the MIT-licensed core of Temporal. Workflows are ordinary code in Go, Java, TypeScript or Python, and the server keeps a complete ordered event history so workflows can replay and resume after failures. Self-hosting means operating the Frontend, History, Matching and Worker services plus a persistence store, and you must add authentication yourself, because the default authorizer allows every API request. Choose it when your team wants code-first durable workflows and can carry that operating load. Check the upgrade path first, since upgrades move one minor version at a time.
Temporal Cloud (commercial)
Temporal Cloud is the managed service sold by Temporal Technologies, so the vendor operates the cluster and you pay for usage. Pay-as-you-go pricing starts at 50 US dollars per million actions, with separate active and retained storage charges. The published SLA is 99.9%, or 99.99% with high availability, and SAML SSO is included. Choose it when you want Temporal's model without running persistence and visibility stores yourself. Confirm data residency, network path and support terms, because managed hosting moves those decisions to the vendor.
Cadence (Apache-2.0, CNCF)
Cadence has been an open-source platform since 2017 and is a CNCF project under the Cloud Native Computing Foundation's open governance. The project names Uber, DoorDash and NetApp as users. Its backend runs several services on Cassandra, MySQL or PostgreSQL, optionally with Kafka and Elasticsearch, while workers hold the workflow code. Official SDKs cover Go and Java, and the Python and Ruby SDKs are community maintained. Choose it when you want an Apache-2.0 engine under foundation governance and your team works in Go or Java. Confirm the maturity of any community SDK before you depend on it.
Conductor OSS (Apache-2.0)
Conductor OSS started at Netflix and is now maintained by Orkes and the community under Apache-2.0. Workflows are JSON graphs that you can version and inspect, and workers in any language carry the business logic. Official SDKs cover Java, Python, JavaScript, Go and C#, and the server requires Java 21 or later. The documentation lists five persistence backends, including PostgreSQL and Redis, plus Elasticsearch or OpenSearch for indexing. Choose it when teams in several languages need inspectable workflow graphs. Confirm that your upgrade source is the Orkes-maintained project, since Netflix stopped maintaining its repository on December 13, 2023.
Orkes Conductor (enterprise)
Orkes Conductor is the enterprise platform built on Conductor OSS, and the documentation states full compatibility between the two. Orkes offers hosted deployments across major cloud providers. Choose it when you want the Conductor model with a vendor-run hosted option or enterprise support, instead of operating the server yourself. Ask Orkes which edition, support terms, hosting regions and license conditions apply, because the commercial terms sit outside the Apache-2.0 project. Confirm compatibility with the exact Conductor OSS version you run before any migration.
What running each engine costs in people, infrastructure and upgrades
The main cost of self-hosting a durable execution engine is rarely the license, since all three engines here are open source. The cost is the platform team's time to run the service, the stores behind it, the compute that hosts it, the upgrades that keep it supported, and the developers who write and maintain the workers that carry the business logic. A written scope should split these components so each one has a named owner and a recurring or one-time label. For a self-hosted Temporal Service, the infrastructure list is larger than many teams expect: Frontend, History, Matching and Worker services, a persistence store (Cassandra, PostgreSQL or MySQL, per the tested versions), and a visibility store if you want advanced search. Ask each vendor or partner to price the stores you intend to run, not only the engine.
Upgrades are where Temporal's operating model shows its cost most clearly. The Temporal upgrade guidance says to move one minor version at a time, starting with the latest patch of your current minor, because backward compatibility is guaranteed only between two successive minor versions. Where release notes call for it, schema upgrades must run before server upgrades. If you deploy with Helm, note that chart versions below 0.73.1 do not work with server images 1.30 and later, so chart pinning belongs in your upgrade plan. Your team should confirm the upgrade calendar, test environment capacity and rollback steps before committing to a version line, because each minor step is recurring work.
For managed options, the Temporal Cloud pricing page lists pay-as-you-go starting at 50 US dollars per million actions, active storage at 0.042 dollars per GB-hour and retained storage at 0.00105 dollars per GB-hour, with a 99.9% SLA or 99.99% with high availability. Action volume and storage retention are the main drivers, so model your expected workflow volume and history retention before comparing against self-hosting. Cadence and Conductor costs depend heavily on which stores you choose (Cassandra, MySQL or PostgreSQL for Cadence; PostgreSQL, Redis and a search index for Conductor), plus whether you add Kafka or Elasticsearch. Request a written scope from any partner that specifies the stores, environments, upgrade cadence and worker development hours before you estimate totals.
How to choose and pilot a durable execution engine
This sequence turns a shortlist of Temporal, Cadence and Conductor into a documented decision, based on your own processes, skills, storage and security rules rather than on feature lists alone.
Inventory business processes and their failure cases
Process owners and platform engineers list the long-running processes that are candidates for durable execution, such as payments, provisioning or document approvals. For each one, record the steps that call external systems, the retries and compensations expected when a call fails, the waits for human or partner responses, and the maximum time a run may stay open. The output is a short register of processes with their failure cases, which becomes the test basis for the pilot. Done when every candidate process has a named owner and at least one written failure scenario.
Assess developer language and skills
Engineering leads check which languages the teams that will write and maintain workflows already use. Temporal workflows are written as code in Go, Java, TypeScript and Python. Cadence has official Go and Java SDKs, with community Python and Ruby SDKs. Conductor defines workflows in JSON and runs workers in any language, with official SDKs for Java, Python, JavaScript, Go and C#. Confirm whether each SDK's maintenance status and support terms fit your standards, and record which team owns workflow code after go-live. Done when the team has a signed-off list of languages and named owners for each engine's SDK.
Confirm existing persistence and visibility stores
The platform team compares each engine's backing stores with the databases and search services it already runs and supports. Temporal's tested persistence options are Cassandra, PostgreSQL and MySQL, with SQLite for development only, and its advanced visibility supports Elasticsearch, OpenSearch, MySQL, PostgreSQL and SQLite depending on server version. Cadence needs Cassandra, MySQL or PostgreSQL, optionally with Kafka and Elasticsearch. Conductor lists five persistence backends and indexing on Elasticsearch or OpenSearch. Ask each vendor or community channel to confirm the exact versions your environment requires. Done when a table maps each engine's stores to your existing operating model, including who patches and backs them up.
Check security defaults against identity and network rules
Security and identity teams review each engine's defaults before any environment is built. Temporal's self-hosted default authorizer allows every API request until an Authorizer is configured, so access control must be enabled deliberately, along with mTLS, a ClaimMapper for roles and OIDC for the Web UI. Temporal's deployment guidance says services should not be reachable from the public internet. Confirm the equivalent settings for Cadence and Conductor, including how their UIs, APIs and workers authenticate, and how payload encryption will be handled. Done when the security team signs off a configuration checklist that names each control, its owner and the evidence it will produce.
Define the upgrade and version policy
The platform team writes the rule it will follow for upgrades before the pilot starts. For Temporal, the upgrade guidance says to move one minor version at a time to the latest patch of the current minor, and to run schema upgrades before server upgrades when release notes call for them. Check the equivalent guidance for Cadence and Conductor, including the Helm chart and server compatibility notes for your chosen deployment method. Record which release lines your team will track and who approves each upgrade. Done when the policy is written, approved and linked from the pilot plan.
Run a time-boxed pilot with a failure and an upgrade
Build one non-production environment on the shortlisted engines using the same infrastructure pattern you would use in production. Implement one process from the register, then run it with injected failures, such as a downstream outage, a worker crash and a timeout, and check that each run resumes or compensates as designed. Then perform a version upgrade following the policy from the previous step and repeat the test. Set the time box in writing before work begins. Done when the pilot has passed or failed each scenario and the team can explain every failure it observed.
Record pilot evidence for a side-by-side decision
The pilot lead keeps one shared scorecard for every engine, covering the effort to implement the process, the number of configuration steps, the failures observed and how each was recovered, the upgrade steps and any issues, the operational tasks the team would own, and the security controls verified. Add the licensing terms and any managed or paid options you would need, and note what each quote would need to include. The output is a dated decision record that names the chosen engine, the rejected options and the reasons. Done when the record is reviewed by platform, security and the process owners.
What buyers and practitioners ask before choosing a durable execution engine
Can our team self-host a durable execution engine without outside help?
Yes, several of these engines can be self-hosted by an in-house team, but the answer depends on the skills and capacity you have for running stateful services. Temporal Server runs as Frontend, History, Matching and Worker services plus a persistence store, and it can be deployed with Docker Compose, Go binaries or Helm charts on Kubernetes. Conductor needs Java 21 or later and a backing store. Cadence needs a database such as Cassandra, MySQL or PostgreSQL. Confirm internally whether you have people who can operate the persistence layer, upgrades and monitoring over time. If you do not, DeployOpen can plan, implement, harden, back up, upgrade and document a self-hosted deployment inside your own infrastructure under a fixed-scope agreement, or provide ongoing support as a retainer.
How long does a pilot take, and what drives the timeline?
No pilot duration is set by the researched facts, so treat any number you hear from a vendor or partner as something to confirm against a written scope. The main drivers are the number of workflows, the languages and SDKs your teams use, the persistence and visibility stores you must run, the identity and network controls you must integrate, and how many services call into the engine. Temporal's documentation says its services should run on hosts that are not reachable from the public internet, which adds network work in a regulated environment. DeployOpen agrees timelines and deliverables in writing before work starts, so ask for a scope that lists each of these drivers separately.
What do developers and the platform team need to supply?
Developers need to write workflows and activities in the language their services already use, and that work is different for each engine. Temporal workflows are code in Go, Java, TypeScript or Python, so developers must learn determinism rules for replay. Conductor workflows are JSON graphs with workers written in any language, and Cadence workers hold the implementation with official Go and Java SDKs. The platform team owns the cluster, databases, upgrades, certificates, identity integration and backups. Ask each vendor which SDKs and skills you must hire or train for, and confirm who on your side will own on-call responsibility for the engine.
Do we need Temporal Cloud, or can we run Temporal ourselves?
You do not need Temporal Cloud to use Temporal, because Temporal Server is MIT licensed and can be self-hosted. Temporal Cloud is a managed service that Temporal Technologies sells, and its published pay-as-you-go pricing starts at 50 US dollars per million actions, with active storage at 0.042 dollars per GB-hour and retained storage at 0.00105 dollars per GB-hour, according to the Temporal pricing page. Cloud also lists a 99.9% SLA, or 99.99% with high availability. Choose Cloud if you want to avoid running the cluster, and self-host if data residency, network isolation or your own cost model requires it. Ask Temporal for current pricing and terms, since the figures may change.
How hard is it to switch engines later, and what affects the cost?
Switching is expensive because workflow logic is tied to each engine's programming model, history format and SDK. Temporal and Cadence workflows are code that depends on deterministic replay, while Conductor workflows are JSON definitions with workers in any language, so the rewrite scope differs. The main cost drivers are the number of workflows still running during the move, how long in-flight executions must survive, the state stored in each engine, and the number of services that call the engine. Keep workers thin, isolate business logic from orchestration, and document workflow contracts early. Ask any implementation partner to estimate the move against a written inventory of workflows.
Are Cadence or Conductor safe to start on today?
Both are open source under Apache-2.0 and both have recent releases, so they are viable candidates, but safety depends on your maintenance plan. Cadence v1.4.2 was published on October 2, 2026, and it is a CNCF project under open governance with official Go and Java SDKs. Conductor v3.32.5 was published on September 25, 2026, and it is actively maintained by Orkes and the community, after Netflix discontinued maintenance of the Netflix/conductor repository effective December 13, 2023. Check the SDK for your language, the persistence and visibility stores you plan to run, and the upgrade path for your chosen version. Confirm support options with each project or a commercial vendor before committing.
What security controls should we confirm before going to production?
Confirm authentication before anything else, because Temporal's documentation says that if no Authorizer is configured, self-hosted Temporal uses a noopAuthorizer that allows every API request. Temporal also supports mTLS for internode and frontend traffic, a ClaimMapper for JWT or certificate claims, an Authorizer plugin, OIDC single sign-on for the Web UI and payload encryption through custom codecs. Confirm which of these your security team requires, how workflow payloads containing personal data are handled, and how the engine's audit trail is retained. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or certification.
How DeployOpen scopes and delivers a durable execution engine implementation
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so a durable execution engine runs in your cloud account, data center or air-gapped network. Engagements are usually fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts.
How we scope
- Confirm which engine and which SDK languages your teams will use, since Temporal, Cadence and Conductor differ in programming model and client libraries.
- Record the persistence and visibility stores you must run, and who operates them, before any deployment work is quoted.
- Agree in writing whether the engagement includes identity integration, payload encryption and network isolation for the cluster.
How we build
- Deploy the chosen engine's services in your environment using the deployment method your platform team has approved.
- Configure authentication, authorization, mTLS and the Web UI sign-on path against your identity provider, then test each access rule.
- Run security testing of the workflow services and their APIs, and document findings with fixes before the cluster goes live.
How we hand over
- Deliver runbooks for upgrades, schema changes and rollback, written for the versions your team will actually run.
- Document backup and restore procedures for the persistence store, and test a restore against the agreed scope.
- Provide compliance-oriented evidence of configuration and controls, noting that independent auditors, not DeployOpen, issue any attestation.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the initial build.
- Ask any quote to name who operates the persistence store, who applies server patches and who owns SDK upgrades in workflow code.
- Confirm release support windows with the vendor before choosing a minor line, since those windows set the upgrade cadence.
