Temporal vs Cadence vs Conductor: which fits your team's situation
Pick Temporal if your team wants to write long-running business logic as ordinary code in Go, Java, TypeScript or Python and may prefer a managed option later. Pick Cadence if Apache-2.0 licensing and CNCF open governance matter most and your engineers work in Go or Java, the two languages with official SDKs. Pick Conductor if you want workflows defined as versioned JSON graphs and business logic written as workers in several languages, with Java 21 or later available for the server. The choice depends on your SDK languages, your persistence and visibility choices, and whether your team wants to operate the cluster itself. No single engine wins on every axis, so the shortlist should be narrowed by those three factors before anyone runs a proof of concept. Temporal Server is MIT licensed, and Temporal Technologies sells Temporal Cloud as a managed service, which matters if you want a provider to run the Frontend, History, Matching and Worker services for you. Self-hosting Temporal means you choose the persistence store (Cassandra, PostgreSQL or MySQL, with SQLite for development only) and a visibility store, and you must review the default noopAuthorizer before exposing any API, because it allows every request. Cadence sits on a similar architecture with Cassandra, MySQL or PostgreSQL and optional Kafka and Elasticsearch, and its official Helm chart from the cadence-charts repository gives a Kubernetes path. Confirm with each vendor which SDK versions your language requires, since Cadence's Python and Ruby SDKs are community-maintained. Conductor suits teams that want the workflow definition to be inspectable outside application code. Its Apache-2.0 repository is maintained by the community and Orkes, and Netflix archived its own repository after ending maintenance on December 13, 2023, so confirm which codebase and release line your governance review should accept. Before committing, run one representative workflow on each candidate, check how your team handles versioning and replay, and ask each provider for written support boundaries for your chosen deployment model.
Which durable execution engine fits which scenario
This table maps four common team situations to the engine that tends to fit, along with the condition that makes the fit hold and what to confirm before committing. Read each row against your own language mix, hosting rules and workflow review process, since the right choice often depends on one of those conditions rather than on feature lists alone.
| Scenario | Best fit and the reason | Condition and what to confirm |
|---|---|---|
| Go or Java backend team building long-running application workflows | Temporal, because workflows are plain Go or Java code with a complete ordered event history used to replay and resume after failures. Official Go and Java SDKs exist for Cadence too, so Cadence is a close second. | Holds when the team wants code-defined workflows and can run a separate persistence store plus the Frontend, History, Matching and Worker services. Confirm the persistence and visibility stores your team will operate and the Temporal Server minor line you will pin. |
| Polyglot team that wants a managed option | Temporal, because Temporal Cloud is offered as a managed service and the SDK model covers several general-purpose languages. Conductor also offers hosted deployments through Orkes, which may suit teams that prefer JSON-defined graphs. | Holds when a hosted control plane is acceptable under your data residency and contract rules. Confirm the Temporal Cloud regions and SLA tier in the pricing terms, and ask Orkes which hosting regions and support levels apply to its enterprise platform. |
| Team that wants JSON-visible workflow graphs | Conductor, because workflows are defined in JSON as versioned, inspectable graphs, while workers in any language carry the business logic. This suits reviewers who need to read the flow without reading code. | Holds when the process shape changes more often than the worker code and reviewers work from diagrams or definitions. Confirm the persistence backend and the search index you will run, and check that your team is comfortable with Java 21 for the server. |
| Team already in the CNCF ecosystem with Kubernetes operations | Cadence, because it is a CNCF project under open governance with an official Helm chart in the cadence-charts repository and Apache-2.0 licensing. | Holds when open governance under the CNCF outweighs a single-vendor managed option. Confirm the current CNCF project status with the Cadence maintainers, and confirm which database (Cassandra, MySQL or PostgreSQL) and whether Kafka and Elasticsearch will be needed for your visibility requirements. |
How each platform's server and persistence are built
A self-hosted Temporal Service runs four internal services: Frontend, History, Matching and Worker. Each workflow's state lives in a complete, ordered event history, which the History service maintains and which Temporal replays to resume work after a failure. The services depend on a persistence store for that history and a separate visibility store for search. Temporal's tested persistence options are Cassandra, PostgreSQL and MySQL, and SQLite is limited to development and testing. For visibility, Temporal supports Elasticsearch 7 and 8, OpenSearch 2 or later, and MySQL, PostgreSQL and SQLite on the versions listed in its docs. Cassandra visibility was removed in version 1.24, so Cassandra deployments need a separate visibility store.
- Service split: Frontend, History, Matching and Worker can be deployed together or separately, depending on how you size the cluster.
- Persistence: Cassandra 3.11, 4.0 and 5.0.4 or later, PostgreSQL 13 to 16, and MySQL 5.7 and 8.0.19 or later are the tested stores.
- Visibility at scale: Temporal's docs recommend Elasticsearch or OpenSearch for anything beyond a few workflow executions.
- Deployment options: Docker Compose, Go binaries, Helm charts that run each service in its own Kubernetes pod, or a custom Go build.
- Chart compatibility: Helm chart versions below 0.73.1 do not work with server images 1.30 and later.
Confirm the current persistence and visibility matrix, and the upgrade order, in the Temporal self-hosted documentation before you size your cluster.
Cadence runs a multi-service backend backed by a database. The README lists Cassandra, MySQL or PostgreSQL as the database options, with Kafka and Elasticsearch as optional components. Workers host the workflow implementation, so the server side and the worker fleet are separate deployments. Cadence has an official Helm chart in the cadence-charts repository for Kubernetes deployment. The project's Google Kubernetes Engine codelab uses PostgreSQL, Kafka and OpenSearch for advanced visibility, which shows one supported combination rather than a required stack. Cadence also ships a CLI for managing workflows, task lists, domains and clusters, and a web UI for workflow histories and traces.
- Service mesh of components: The backend runs multiple services, so plan for each one to be monitored and upgraded.
- Database choice: Cassandra, MySQL or PostgreSQL hold workflow state.
- Optional Kafka and Elasticsearch: Advanced visibility and some messaging paths add these components, and each adds an operations burden.
- Kubernetes packaging: The official Helm chart is available from the cadence-charts repository.
- Operator tooling: The CLI and web UI cover workflow inspection and cluster management.
Confirm the supported database versions, visibility backends and Helm chart compatibility in the Cadence documentation before you commit to a stack.
Conductor OSS runs as a Java server, and the README states that it requires Java 21 or later. A Docker image bundles the server and the UI, which makes a single-container trial straightforward. Conductor supports five persistence backends according to its documentation, including PostgreSQL and Redis, and six message brokers. Elasticsearch or OpenSearch handle indexing for search and visibility. Workflow definitions are JSON graphs stored in the server, while workers in any supported language run the business logic. Orkes offers an enterprise platform built on Conductor OSS with full compatibility between the two, and hosted deployments across major cloud providers.
- Runtime requirement: A Java 21 or later runtime is needed to run the server outside the Docker image.
- Packaged deployment: The Docker image bundles the server and UI together.
- Persistence: Five backends are documented, including PostgreSQL and Redis, so confirm which one your team will certify.
- Messaging: Six message brokers are documented, and the broker choice affects queue behavior and operations.
- Search: Elasticsearch or OpenSearch provide indexing for workflow search.
Confirm the full persistence and broker matrix for your Conductor version in the Conductor OSS documentation, since the supported set changes between releases.
Programming model, SDKs, storage and governance side by side
This table compares the three durable execution engines on license, workflow definition, SDK languages, persistence, visibility, default authorization and governance. Read each row against your own language standards and data platform, and treat any cell marked as a verification item as an open question for the vendor or the repository.
| Capability | Temporal | Cadence | Conductor |
|---|---|---|---|
| License | MIT for Temporal Server (temporalio/temporal) | Apache-2.0 for the Cadence repository (cadence-workflow/cadence) | Apache-2.0 for conductor-oss/conductor; Netflix/conductor is archived |
| Workflow definition model | Workflows written as code in Go, Java, TypeScript and Python, replayed from an ordered event history | Workflows written as code in the SDK language; workers contain the workflow implementation | Workflows defined in JSON as versioned, inspectable graphs; workers in any language run the business logic |
| Official SDK languages | Go, Java, TypeScript and Python are the languages named in the Temporal documentation; confirm the full official list for your version | Official Go and Java SDKs; Python and Ruby SDKs are unofficial community projects | Official SDKs for Java, Python, JavaScript, Go and C#; Ruby SDK incubating |
| Persistence backends | Self-hosted tested options are Cassandra, PostgreSQL and MySQL; SQLite for development only | Cassandra, MySQL or PostgreSQL, optionally with Kafka and Elasticsearch | Documented support for 5 persistence backends including PostgreSQL and Redis; confirm the full list for your release |
| Visibility store | Separate advanced visibility on Elasticsearch 7 and 8, OpenSearch 2 or later, or MySQL, PostgreSQL and SQLite depending on server version; Cassandra visibility removed in 1.24 | Elasticsearch or OpenSearch for advanced visibility; the Google Kubernetes Engine codelab pairs PostgreSQL with OpenSearch | Elasticsearch or OpenSearch for indexing; confirm search coverage for your workload |
| Authorization default | Self-hosted default is noopAuthorizer, which allows every API request until you configure an Authorizer | Not covered by the supplied facts; verify the default access controls in your Cadence release | Not covered by the supplied facts; verify authentication and access controls in your deployment |
| Identity and transport options | mTLS with separate internode and frontend settings, a ClaimMapper for JWT or certificate claims, an Authorizer plugin and OIDC SSO for the Web UI | Not covered by the supplied facts; verify TLS and SSO options with the Cadence project | Not covered by the supplied facts; verify TLS and SSO options with Conductor documentation |
| Governance | Maintained by Temporal Technologies, which also sells Temporal Cloud | CNCF project under open governance of the Cloud Native Computing Foundation; named users include Uber, DoorDash and NetApp | Originated at Netflix; Netflix archived its OSS repository in favor of an internal fork, and Orkes and the community maintain conductor-oss |
| Commercial backing | Temporal Cloud managed service with a 99.9% SLA or 99.99% with high availability, and SAML SSO, per Temporal pricing | Managed options are not covered by the supplied facts; confirm with vendors before deciding | Orkes Conductor enterprise platform, fully compatible with Conductor OSS, with hosted deployments across major clouds |
How Temporal, Cadence and Conductor differ in writing workflows
Temporal and Cadence both ask engineers to write workflows as code, in a supported SDK language such as Go or Java (Temporal also offers TypeScript and Python). The workflow function is the source of truth, and the service records a complete ordered event history of each run. After a worker crash or a failed step, the engine replays that history against the workflow code to rebuild state and resume where it stopped. This model means the team that writes the business logic also owns its versioning, testing and upgrades, and the people maintaining a workflow need to read the code to know what it does.
That replay model makes determinism a hard requirement. Workflow code must produce the same decisions when replayed, so calls to the clock, random numbers, network I/O or non-deterministic library code belong in activities, not in the workflow function. Changing a workflow while runs are still in flight can break replay, so teams should check the versioning guidance in the SDK documentation before deploying. Cadence shares this constraint because its model is the same family, so a team moving between the two should review its workflow code against that rule rather than assume the port is mechanical.
Conductor takes the opposite approach. Workflows are JSON definitions that describe a graph of tasks, each stored as a versioned, inspectable artifact that operators can read without a developer. The actual business logic runs in workers, which can be written in any language, and Conductor provides official SDKs for Java, Python, JavaScript, Go and C#. This suits organizations where operations or analysts review flows, but the reader should confirm how their team would test branching logic and how far they can rely on the JSON definitions for audit and change control in their own environment.
What each license and commercial path means for your team
Temporal Server is MIT licensed, so you can run the open-source service in your own infrastructure without a license fee for the server itself. The cost question is operational: you run the Frontend, History, Matching and Worker services, plus a persistence store and, for advanced visibility, Elasticsearch or OpenSearch. Temporal Technologies also sells Temporal Cloud as a managed service, 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, per the Temporal pricing page.
- Server license: MIT, with no per-node or per-user fee in the open-source code.
- Managed option: Temporal Cloud is billed by usage, and its published SLA is 99.9%, or 99.99% with high availability.
- Identity features: Self-hosted SAML or OIDC settings, mTLS and custom codecs are part of the open-source server, but you configure them yourself.
- Support: Confirm in writing whether vendor support is included in any commercial agreement and what response times apply.
- Upgrades: Plan the minor-version upgrade path yourself if you self-host.
Before you sign, ask for a written quote that separates Temporal Cloud usage charges from any support fees, and confirm which features are included in each tier.
Cadence is licensed under Apache-2.0 and has been an open-source platform since 2017. It is a CNCF project under the open governance of the Cloud Native Computing Foundation, which means its roadmap and contributions are managed in a vendor-neutral foundation rather than by a single company. The project names Uber, DoorDash and NetApp as users, according to the Cadence website, which gives you public references to check but not a guarantee of how they run it.
- License: Apache-2.0 for the repository, with no open-core edition described in the supplied material.
- Governance: CNCF project under open governance, so changes follow the foundation process.
- Named users: Uber, DoorDash and NetApp, as listed on the project website.
- Commercial backing: The supplied material does not name a commercial vendor that sells Cadence support. Ask which companies offer paid support and in what terms.
- Official SDKs: Go and Java are official, while Python and Ruby SDKs are community projects, which affects who you can hire for support.
Confirm in writing who would support you if a production incident arose, and whether any managed or hosted Cadence offering exists for your region.
Conductor OSS is licensed under Apache-2.0 and is now maintained by Orkes and the community. It originated at Netflix, but Netflix discontinued maintenance of Conductor OSS on GitHub effective December 13, 2023, and archived the Netflix/conductor repository in favor of its internal fork. That date matters for due diligence because the open-source project you adopt today is stewarded by a different group than the one that started it.
- License and stewardship: Apache-2.0, maintained by Orkes and the community, with the Netflix repository archived.
- Enterprise build: Orkes Conductor is the enterprise platform built on Conductor OSS, with full compatibility between the two according to Conductor documentation.
- Hosted option: Orkes offers hosted deployments across major cloud providers, which is a paid path.
- Enterprise features: The supplied material does not list which features are reserved for Orkes Conductor, so ask for that list in writing.
- Roadmap risk: Confirm how security patches and upgrades are handled for the OSS line if you choose not to buy the enterprise build.
Ask Orkes for a written scope that states the license terms, the support model and the compatibility commitments, and ask the community maintainers how release decisions are made.
What drives the running cost of each engine
Running any of these engines costs more than the software license, which is free for all three. The cards below cover the components that carry recurring cost, who is paid for each one, and what to request in a written quote before you choose between self-hosting and a managed service.
Cluster and persistence operations
A self-hosted Temporal Service runs Frontend, History, Matching and Worker services on top of a persistence store, while Cadence runs its own set of services over Cassandra, MySQL or PostgreSQL, and Conductor runs its server over one of its supported persistence backends. Your team, or a partner you pay, carries the recurring work of patching, capacity planning, backups and failover testing. Ask any vendor or partner to state which persistence store they assume, who runs the upgrades, and how many hours per month the quote assumes for operations.
Visibility store and search indexing
Visibility is the query layer for workflow lists and search. For Temporal, Elasticsearch or OpenSearch is recommended once you run more than a few workflow executions, and Cassandra visibility was removed in version 1.24. Cadence can use Elasticsearch for advanced visibility, and Conductor uses Elasticsearch or OpenSearch for indexing. A search cluster is a separate system to size, patch and back up, so ask whether the quote includes it and what storage growth it assumes.
Message brokers and optional Kafka
Conductor supports six message brokers, and Cadence can add Kafka to its backend, so broker operations may become a second platform your team runs. Temporal does not require a broker for its core cluster, which keeps its footprint narrower. Confirm which brokers are in scope, who manages their retention and partitions, and whether broker licensing or hosting is part of the quote.
Java 21 runtime and upgrade effort
Running a Conductor server requires Java 21 or later, so the JVM, its patch cadence and its compatibility with your existing stack become recurring duties. Upgrades are one-time projects per major change, but the schema and server sequence is recurring work. Temporal asks operators to move one minor version at a time and to run schema upgrades before server upgrades when release notes call for them. Ask who owns each upgrade cycle and how many environments the quote covers.
Managed service fees
Temporal Cloud is priced on usage, 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 Temporal's pricing page. Orkes offers hosted Conductor across major cloud providers, but this research does not include its price. Cadence has no supplied managed offering in this comparison. Ask each provider for a sample bill based on your action volume, storage retention and the SLA tier you need.
Worker engineering time
In all three engines, workers hold the business logic, so the largest recurring cost is often the engineering time to write, test, version and redeploy them. Temporal workflows are code that must stay deterministic across replays, Cadence workers are written in Go or Java with official SDKs, and Conductor workers can be written in any language with a supported SDK. Ask a partner to estimate worker count, SDK language mix and the on-call rotation that owns them, and state in the quote which of these items are one-time build work and which are ongoing.
What a first deployment of each engine involves
This sequence shows what a team must set up before any workflow runs, from choosing a packaging method to proving the security baseline and a safe upgrade path. The output is a non-production cluster that a platform team can test against before any production decision.
Choose the packaging method for Temporal
The platform team picks one of four routes for a self-hosted Temporal Server: Docker Compose, Go binaries, Helm charts that run each Temporal service in its own Kubernetes pod, or importing the server package into a custom Go build. Helm chart versions below 0.73.1 do not work with server images 1.30 and later, so the chart version must be pinned to a compatible release. The decision is closed when the chosen route and the exact chart or image versions are written down and approved by the platform owner.
Provision persistence and visibility stores
The team provisions the persistence database, which Temporal tests on Cassandra 3.11, 4.0 and 5.0.4 or later, PostgreSQL 13 to 16, or MySQL 5.7 and 8.0.19 or later. SQLite is for development and testing only. Advanced visibility should use Elasticsearch 7 or 8, OpenSearch 2 or later, or a supported SQL store, and Elasticsearch or OpenSearch is recommended for anything beyond a few workflow executions. The step is complete when both stores are reachable from the Temporal services and the database versions match the tested list. Confirm the current support matrix with Temporal before purchasing hardware or managed services.
Deploy Cadence and Conductor components
For Cadence, the team deploys the multi-service backend with the official Helm chart from the cadence-charts repository, backed by Cassandra, MySQL or PostgreSQL, and decides whether Kafka and Elasticsearch are needed. For Conductor, the team runs the server on Java 21 or later, typically from the Docker image that bundles the server and UI, and connects a persistence backend and an indexing store. The step is done when each server starts, the CLI or UI can list namespaces or workflow definitions, and a test worker connects. Client decisions include which Cadence persistence engine and which Conductor persistence backend match existing database standards.
Apply the network isolation baseline
Temporal's deployment guidance says its services should run on hosts that are not reachable from the public internet, with access restricted to trusted internal networks. The network team places the Frontend, History, Matching and Worker services, and the persistence and visibility stores, in private segments and limits which clients can reach the frontend port. The check is a scan from outside the trusted network that finds no open Temporal endpoints. Cadence and Conductor require the same discipline, and the client should apply it through its own network controls and confirm the exposure model with the vendor documentation for each engine.
Configure mTLS and an Authorizer
Self-hosted Temporal supports mTLS with separate settings for internode and frontend traffic, so the security engineer configures both paths. Without a configured Authorizer, Temporal uses the default noopAuthorizer, which allows every API request with no authentication or access control, so an Authorizer plugin and a ClaimMapper that maps JWT or certificate claims to namespace roles must be set before any shared use. The step closes when an unauthenticated request is refused and a role-limited identity can only reach its own namespace. Ask Cadence and Conductor maintainers, or the team's own testing, to confirm the equivalent authentication and authorization options in their releases.
Enable OIDC sign-in for the web UI
The identity team connects the Temporal Web UI to the organization's identity provider using OIDC single sign-on, and tests that a user from an authorized group can log in while others cannot. Payload encryption through custom codecs and a codec server should be decided at this stage for any workflow data that is sensitive. The check is a successful login through the identity provider and a review of who holds which namespace role. For Cadence, the web UI and CLI access model and for Conductor, the UI access model must be confirmed against each project's current documentation before the same control is promised to users.
Adopt one minor version upgrade at a time
Temporal guarantees backward compatibility only between two successive minor versions, so the platform team upgrades one minor line at a time and moves to the latest patch of the current minor first. Where release notes call for schema changes, the schema upgrade runs before the server upgrade. The step produces a written upgrade runbook and a test environment that proves the sequence works on the chosen persistence store. Teams running Cadence or Conductor should record the release process of their chosen project, including the versions they will track, and assign an owner for each patch release.
Questions buyers ask before choosing a durable execution engine
What does running Temporal, Cadence or Conductor actually cost?
The software licenses are free for all three: Temporal Server is MIT licensed, Cadence is Apache-2.0, and Conductor OSS is Apache-2.0. The recurring cost is the infrastructure and the people who run it. A self-hosted Temporal Service needs Frontend, History, Matching and Worker services plus a persistence store and, for advanced visibility, Elasticsearch or OpenSearch. Cadence needs its services and a database, optionally Kafka and Elasticsearch. Conductor needs a Java 21 or later server and a backend store. Costs rise with event volume, retention, the number of clusters and the number of regions. For Temporal Cloud, the pay-as-you-go pricing page lists 50 US dollars per million actions, plus storage rates per GB-hour. Ask any quote to separate one-time implementation work from recurring hosting, upgrades and on-call support.
How long does a first self-hosted deployment take?
No supplied figure gives a reliable duration, so treat any number you hear as a claim to verify. The time depends on the persistence choice, whether you need advanced visibility, how many environments you run, whether you deploy with Docker Compose, Helm or Go binaries, and whether your Kubernetes platform and network rules are already in place. Temporal's deployment docs say its services should run on hosts not reachable from the public internet, which adds network work in most enterprises. Ask for a written scope that lists the environments, the persistence and visibility stores, the authentication design, backup and upgrade procedures, and the acceptance tests before agreeing to a timeline.
Can our own team run the engine without outside help?
Yes, if you have engineers who can operate distributed services and a database team that can support the chosen store. The harder part is security configuration. Temporal's default Authorizer, the noopAuthorizer, allows every API request until you configure one, so access control, mTLS, a ClaimMapper and OIDC for the Web UI must be set deliberately. Cadence and Conductor each have their own CLI, UI and operational model. Assess your team against the upgrade path: Temporal documents that you should upgrade one minor version at a time and run schema upgrades first when release notes call for it. Outside help is most useful for the first deployment, hardening and the upgrade runbook. DeployOpen supports self-hosted platforms in your own infrastructure through fixed-scope work and retainers, and it does not issue audit reports or certifications.
What do the workflows demand from our engineers and platform team?
Application engineers write workflow code in the SDK language, so determinism matters. Temporal workflows are code in Go, Java, TypeScript or Python and replay from an ordered event history, which means code changes to running workflows need versioning discipline. Cadence has official Go and Java SDKs, with Python and Ruby SDKs that are community maintained. Conductor defines workflows as JSON graphs, and workers in any language perform the business logic, which shifts design work to graph definitions. The platform team owns the clusters, persistence, metrics, upgrades and secrets. Check which SDKs your engineers already use, whether unofficial SDKs are acceptable for your support model, and who will own on-call for the workflow service.
How hard is it to move between these engines later?
There is no supplied migration tool or cost figure for moving between them, so confirm this in writing for your own workflows. The main switching cost is the workflow logic itself. Temporal and Cadence both use code-defined workflows with histories, so moving between them means rewriting definitions in the target SDK and planning how in-flight executions drain. Conductor uses JSON graph definitions and language-agnostic workers, so worker code may be easier to keep while the orchestration definitions change. Also plan for the persistence store and visibility data, which do not move automatically. Ask for a migration plan that covers running executions, versioning, observability and rollback.
Which managed options exist for each engine?
Temporal Technologies sells Temporal Cloud as a managed service, and its pricing page lists a 99.9% SLA, or 99.99% with high availability, plus SAML SSO. Conductor has an enterprise platform, Orkes Conductor, built on Conductor OSS with full compatibility between the two, and Orkes offers hosted deployments across major cloud providers. Cadence's supplied materials describe open governance under the CNCF and a Kubernetes Helm chart, but they do not name a managed service, so confirm any hosted offering with the maintainers before you assume one exists. Compare managed options on data residency, the region list, encryption of payloads, audit logs and what you still operate yourself.
How DeployOpen helps choose and implement a durable execution engine
DeployOpen is a Chainscore Labs company that plans, implements, customizes, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a durable execution decision between Temporal, Cadence and Conductor, we work from a written scope that covers the engine, its persistence and visibility stores, the workers and the operating model your teams will run.
How we scope
- We confirm which languages your workers use, since Temporal, Cadence and Conductor differ on SDK coverage and maturity.
- We record the persistence choice, such as Cassandra, PostgreSQL, MySQL or Redis, and who will operate it.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- We deploy the chosen engine in your cloud account, data center or air-gapped network, following the vendor's documented topology.
- We configure authentication, authorization, mTLS and payload encryption, and confirm the default settings are replaced before go-live.
- We build reference workflows and workers for your use cases and test retries, timeouts and failover against them.
How we hand over
- We document the cluster topology, upgrade order, schema steps and backup procedure specific to your deployment.
- We run a handover session with your platform and development teams and record the open items in writing.
- We prepare configuration, access and evidence artifacts that your compliance leads or independent auditors can review.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers, scoped in writing.
- We plan minor version upgrades one step at a time, applying the latest patch of the current line first.
- We ask for a quote built from your written scope, since DeployOpen does not publish a price list.
