Temporal high availability guide

How Temporal high availability works when you run the server yourself

If your durable workflows must survive node, zone and database failures, the availability of your Temporal Service depends on every layer you run, including the server processes. The Temporal Service is several server roles: the frontend, which receives API calls from clients and workers; the history service, which holds and advances workflow state; the matching service, which delivers tasks to workers; and the worker service, which runs internal system workflows. Each role can be scaled and placed separately. Beneath them sit the persistence store, which holds workflow state, and optionally an advanced visibility store for search. Your decision is whether your own platform team builds and runs this stack, or whether a partner plans and implements it with your team in your infrastructure.

High availability is harder than it looks because the stateful layers carry most of the risk. Running workflows keep their state in the persistence store, so a store outage or slow failover can stall executions even when every server process is healthy. Workers and clients must reach the frontend through load balancers, DNS and certificates that are also part of the availability path. A failover that is misconfigured, or that has never been exercised, can leave some services pointing at a database that no longer accepts writes. Visibility is a separate dependency: a failure there affects search and operator queries, and you should confirm with the release notes for your server version how it interacts with execution in your setup.

Temporal Cloud publishes a service level agreement of 99.9%, or 99.99% with high availability, according to Temporal's pricing page. A self-hosted cluster carries no such figure from Temporal or DeployOpen. The availability you achieve is the one your team designs, operates, monitors and tests, including the on-call rota for the store. Before you choose a topology, confirm your availability target in writing: which failure domains must be tolerated, how availability is measured, how long a stalled execution is acceptable, and whether a single cluster is enough or a second cluster is needed. Those answers determine the number of frontend, history and matching replicas, the store topology and the failover runbook.

Start with a short set of decisions that the rest of the design depends on. List the failure scenarios your business expects to survive, including loss of a node, an availability zone, or the primary database. Ask your team which store you will operate, and who owns its replication, backups and failover. Then confirm how your workers will reach the frontend in each scenario. Finally, schedule a failover test in a non-production environment that measures how long executions take to resume. Results from that test, not the design diagram, are the evidence you will need before you commit to an availability target.

Which Temporal components carry availability

A self-hosted Temporal Service depends on several components, and an outage in any one of them can stop workflows from progressing even while the others are healthy. The four Temporal services need redundancy, the persistence and visibility stores determine how much state survives and how queries keep working, and the load balancer is the entry point every client uses. Review each one before you size the cluster.

Frontend, history and matching services

The frontend accepts every client and worker request, checks it, and passes it on. The history service holds the state of each running workflow and records its events, so a workflow can resume after a failure. The matching service queues the tasks that workers poll for. Each of these needs more than one instance so that losing a single pod or host does not stop requests. Check how many replicas each runs and that each can be restarted without taking the others down.

Internal worker service

The internal worker service runs background system workflows that the server uses for its own maintenance. It is separate from the customer workers that run your business code. If it stops, cluster-level background work stops even while client requests still succeed. Run more than one instance so this work continues during an upgrade or a host failure. Confirm which internal workflows your server version schedules and how you will monitor them.

Persistence store

The persistence store holds workflow state, event history and task queues, so it decides whether the cluster can recover from an outage. Supported engines are Cassandra 3.11, 4.0 or 5.0.4 or later, PostgreSQL 13 to 16, and MySQL 5.7 or 8.0.19 or later. SQLite is supported only for development and testing. Confirm the engine version against your server release, and plan backups and failover for the database itself.

Advanced visibility store

The visibility store answers list and search queries about workflow executions, such as finding workflows by status or type. Supported options are Elasticsearch 7 or 8, OpenSearch 2 or later from server 1.30.1, MySQL 8.0.17 or later, PostgreSQL 12 or later, and SQLite from server 1.20. Cassandra visibility was removed in 1.24. Elasticsearch or OpenSearch is recommended beyond a few workflow executions, so size, secure and monitor that cluster as its own failure point.

Load balancer in front of frontend

The load balancer spreads SDK and worker traffic across the frontend instances, so losing one instance does not interrupt callers. Choose a health check that confirms the frontend itself responds to requests. Keep Temporal services on hosts that are reachable only from trusted internal networks, with the load balancer as the controlled entry point. Confirm with the Temporal deployment documentation which protocol and ports your clients use.

Which HA design fits your availability target and team

This table compares the main high availability designs for a self-hosted Temporal Service and Temporal Cloud, with the on-call effort, database administration and latency each one adds. Read each row against the persistence store your team can operate and back up, because that choice shapes every other decision. Confirm that store first, then choose the cluster layout and visibility design around it.

Design	When it fits	Operational cost
Single cluster across failure domains	Zone-level resilience in one region and a team that wants the fewest moving parts	Smallest on-call surface; cross-zone latency between services and store; confirm store zone support
Self-hosted cluster on a managed database service	Team already runs managed PostgreSQL or MySQL and wants the provider to handle replication and backups	Less database administration; your team still runs Temporal services; confirm provider HA and backup options
Self-run database cluster with its own replication	Team has deep database operations skills and needs control over topology or Cassandra	Highest database load: failover, upgrades, backups and restore drills; check replica latency
Elasticsearch or OpenSearch visibility	Large execution volumes and advanced search; Elasticsearch 7 and 8 or OpenSearch 2 or later	Second stateful system to back up, upgrade and monitor; index sizing needs ongoing review
SQL visibility store	Fewer workflow executions and a team that wants one database engine; Temporal recommends search engines beyond a few executions	No extra search cluster; visibility load shares the persistence database, so size them together
Second cluster for disaster recovery	Regional loss must be survivable and the team can run and rehearse two clusters	Doubles infrastructure and on-call scope; cross-region latency; needs a tested failover runbook
Temporal Cloud	Team wants Temporal to operate the service under a stated uptime commitment	Less on-call and database work; usage and support fees recur; pricing page lists 99.9% SLA or 99.99% with high availability

How to build a highly available Temporal Service step by step

This sequence takes a self-hosted Temporal Service from an agreed availability target to a cluster that keeps accepting and running workflows when a node, zone or replica fails. Each step ends with a check you can run to confirm the layer behaves as designed.

Confirm the availability target and failure domains
Before any infrastructure is provisioned, the platform owner and the business owner of the workflows agree on the availability target, the acceptable recovery behavior and the failure domains the cluster must survive, such as a single node, a single availability zone or a whole region. Ask the vendor or partner to confirm the Temporal server version you intend to deploy, since the current server line is v1.32.1 and the patch releases are v1.31.4 and v1.30.8 for earlier minor lines. Done when the target and failure domains are written down, each one maps to a specific layer in the steps that follow, and the server version is recorded. Check that the sign-off names the owner of each decision.
Provision a replicated persistence store with backups
Choose a supported persistence store (Cassandra, PostgreSQL or MySQL, within the versions Temporal tests against) and deploy it with replication across the failure domains you agreed. The database is the one component where losing a node must not lose workflow state, so confirm replication factor, automated failover and point-in-time or snapshot backups with a tested restore procedure. SQLite is for development and testing only and cannot be used here. Done when a restore has been rehearsed into a separate environment and the team can show where each replica lives. Check it by stopping one database node and confirming the store still accepts reads and writes.
Deploy at least two replicas of each stateless service
Run the Temporal services (frontend, history, matching and worker) as separate deployments, with at least two replicas of each stateless service spread across availability zones. The deployment method you choose, whether Docker Compose, binaries or Kubernetes, changes how placement is enforced, so keep the Kubernetes specifics in the Kubernetes deployment topic. Configure anti-affinity or equivalent placement so two replicas of the same service do not share a host or zone. Done when every service shows at least two healthy replicas. Check it by listing replica placement and confirming no two replicas of one service share a zone, then deleting one history replica and confirming the workflow tasks continue.
Place the frontend behind a load balancer with health checks
Put the frontend service behind a load balancer that spreads gRPC traffic across all healthy frontend replicas and removes failed ones from rotation. Services and workers should reach the cluster through this single stable endpoint rather than individual pod or host addresses. Confirm the health check reflects whether the frontend can serve requests, and that the endpoint is reachable only from trusted internal networks, since Temporal services should not be exposed to the public internet. Done when the load balancer lists all frontend replicas as healthy. Check it by stopping one frontend replica and confirming that client calls through the endpoint succeed without a configuration change.
Set up advanced visibility on a clustered store
Configure advanced visibility on a clustered search or SQL store, such as Elasticsearch or OpenSearch (supported from Temporal Server 1.30.1 for OpenSearch 2 or later), or a supported SQL store. Elasticsearch or OpenSearch is the recommended choice for anything beyond a few workflow executions, so size the cluster for the query load your operators and search features will generate. Deploy it with replicas across the same failure domains as the persistence store. Note that Cassandra visibility was removed in 1.24, so do not plan around it. Done when visibility queries return results for newly started workflows. Check it by stopping one search node and confirming that list queries still succeed and that new executions appear in visibility.
Connect workers to the frontend endpoint
Point every worker process at the load-balanced frontend endpoint and run workers in at least two zones so that losing one zone does not stop task processing. Workers should not depend on any single frontend replica, and their connection settings should be identical across zones. Keep worker code and SDK upgrade decisions in the workflow design and upgrade topics. Done when workers in each zone are polling their task queues. Check it by starting a sample workflow, stopping the zone that hosts half the workers, and confirming the workflow still completes on the remaining workers.
Decide on a second cluster or namespace replication
Add a second cluster or configure namespace replication only if your availability target requires surviving the loss of a whole region or cluster. This is the most expensive layer, because it doubles the infrastructure to run, requires a clear decision on which cluster owns each namespace during failover, and needs its own failover testing. Confirm with the business owner whether a single-cluster design across zones already meets the target from step one. Done when the decision is recorded with its reason, and, if replication is chosen, a planned failover has been rehearsed. Check it by promoting the standby namespace in a test window and confirming that workflows start and complete there.

What drives the effort and cost of Temporal high availability

This table lists the factors that raise or lower the effort and cost of a highly available self-hosted Temporal Service, with ways to keep each one manageable. Read each row as a question to answer during scoping, because the same design can cost very different amounts depending on these inputs. The main takeaway is that persistence choice, visibility needs and the number of regions shape most of the bill, and most of it recurs.

Driver	How it raises or lowers effort and cost	How to keep it down
Workflow and event volume	Higher action and history volume needs more frontend, history and matching capacity and more database throughput, and it lengthens load testing before go-live.	Confirm peak and average action rates with the team, size from measured load, and load test the expected peak before committing to a topology.
Number of namespaces	Each namespace adds retention settings, search attributes, access roles and monitoring to operate, and shared clusters need capacity planning across tenants.	Group workloads with similar retention and access needs into fewer namespaces, and document the naming and ownership rules before onboarding teams.
Number of zones or regions	Each additional zone adds replicated database and search nodes, cross-zone network testing and failover drills, which mostly recur as infrastructure and testing cost.	Start with one region with zone-level redundancy, and plan a second cluster as a later phase once the design and runbooks are proven.
Persistence engine the team already operates	An engine with a mature, staffed platform team lowers build and on-call effort. A new engine adds specialist skills, backup tooling and monitoring to learn.	Reuse an existing managed database service the platform team already supports, provided the supported versions listed in the Temporal persistence docs are met.
Visibility query needs	Advanced search over many custom search attributes needs Elasticsearch or OpenSearch clusters, which add capacity, index management and upgrade work on top of the persistence store.	Limit visibility to the search fields that operators and workflows truly need, and confirm the supported visibility store versions before choosing one.
Availability target	A stricter recovery objective requires more replicas, automated failover, tested runbooks and more frequent failover exercises, all of which raise cost and on-call load.	Agree the recovery objectives in writing with the business owner first, then design only the redundancy that meets them.
Number of environments	Each environment such as development, test, staging and production repeats the cluster, databases and search stores, so infrastructure and upgrade effort multiply.	Use smaller non-production topologies that match production configuration, and reserve full high availability for production and the closest staging copy.
Compliance requirements for data residency and backup	Residency rules limit where replicas and backups may sit, and backup, restore and retention evidence add build work and recurring test cycles.	Confirm residency and retention rules with the compliance owner early, then design backup and restore once for every region that holds data.
Security and access controls	Self-hosted Temporal allows every request when no Authorizer is configured, so mTLS, claim mapping and network isolation add design and testing work before go-live.	Include these controls in the initial design rather than retrofitting them, and reuse the identity provider already in use for Web UI access.

How HA differs across single-node, Kubernetes, VM and air-gapped deployments

A single-node Temporal Service runs every service and the persistence store on one host. It suits development, testing and learning the SDK, but it offers no redundancy. If that host fails, workflow progress stops and any state held only on that host is at risk. The persistence documentation limits SQLite to development and testing, so this is the only tab where SQLite belongs in the plan.

Redundancy: none beyond restarting the process. Back up the development store if the team relies on its contents.
Failure domains to map: the single host, its disk, and the network path between workers and the frontend.
Confirm: no production traffic, customer data or compliance evidence is written to this environment.
Confirm: the team knows how the environment will move to a multi-host layout, including which persistence store carries over.
Confirm: the runbook labels the environment as non-production, and no production workers point at it.

Check that the labeling and worker endpoints are written down, so the environment is not promoted by accident.

Keeping high availability paths from becoming attack paths

A second cluster, a load balancer or a standby database adds availability, and each one also adds a place where an attacker or a misconfiguration can reach workflow state. The cards below cover the controls that have to exist on every HA path before it takes traffic. Transport encryption and payload codecs are covered in the security hardening topic.

Keep services off public networks

Temporal services should run on hosts that are not reachable from the public internet, with network access restricted to trusted internal networks. Load balancers, frontend endpoints and replicas in a failover cluster all need this boundary. Check that no standby frontend, health endpoint or load balancer listener is created with a public address during a failover build.

Authorize before any HA endpoint serves traffic

Self-hosted Temporal uses the default noopAuthorizer, which allows every API request without authentication or access control. Any second cluster or load balancer added for high availability must have an Authorizer configured before it receives traffic, otherwise it becomes an open entry point. Plan this together with the security hardening and SSO and authorization topics.

Scope database credentials per replica

Each Temporal service replica and each standby cluster needs database credentials for the persistence store it connects to. Store these in a secrets manager, issue separate identities where the store supports them, and avoid copying one shared administrative password into every configuration file. Confirm how credentials are rotated in both the active and standby clusters without a service outage.

Protect the standby cluster secrets

A standby cluster is often built from the same configuration as the primary, so its secrets are easy to overlook. Confirm which secrets it holds, where they are stored, and who can read them before the standby is connected. Remove or disable them when a standby is retired, and review them on the same schedule as production secrets.

Restrict access to backups

Backups of the persistence store contain workflow histories, which can include business data and sensitive payloads unless encrypted with a codec. Limit read and restore permissions to named roles, keep backup storage in the same trust zone as the database, and log restore operations. Test a restore under the same access controls the production team would use during an incident.

Review failover access paths

During a regional or database failover, operators often open temporary routes, widen firewall rules or grant broader roles to get the service back. Record each temporary change with an owner and an expiry, and remove it once the primary is restored. Include these paths in access reviews so that a failover does not leave permanent exposure behind.

What fails first when a node, zone or database goes down

Most single-replica losses in a self-hosted Temporal Service are absorbed by the cluster, but each failure looks different to the people who depend on it, so the response should be planned for each component. Start with the frontend service, which accepts API calls from SDK clients and workers. When one frontend replica is lost, requests in flight to it fail, and clients retry against the frontend addresses that remain, provided the load balancer or DNS entry in front of the frontends drops the dead endpoint. Workers may log connection errors for a short period. Running workflows continue, because their state lives in persistence. Confirm that health checks remove the lost replica and that alerts fire on frontend error rates, not only on process restarts.

A lost history replica matters more because history hosts own shards, the units that hold workflow mutable state and event history. Temporal reassigns those shards to surviving history hosts. Workflows on the affected shards pause while ownership moves, then resume from persisted state. Matching hosts own task queue partitions. If one is lost, tasks on its partitions wait until the partitions are reassigned, so workers on those queues see growing schedule-to-start latency and nothing fails outright. Running workflows continue. The team must check that the surviving history and matching replicas can carry peak load without saturating, and confirm the history shard count chosen at cluster creation. Check the Temporal documentation on whether that count can change later, and plan as if it cannot.

A zone loss tests whether replicas were spread the way the design assumed. If frontend, history and matching replicas and the persistence nodes were distributed across zones, one zone failure removes a share of each service instead of all of one. The cluster keeps serving only if the persistence store retains a quorum or a usable primary, and the surviving history and matching hosts have capacity for the shards and partitions that moved. Workers in the lost zone disappear, and their in-progress tasks are retried by workers elsewhere after timeouts expire, which makes activity idempotency and sensible timeouts important. Ask the platform team to show the actual placement of each replica, and confirm that the worker fleet can scale in the surviving zones.

Losing the persistence primary is the failure most likely to stop writes. Temporal records every workflow state change in its persistence store, so while the primary is unavailable, history updates fail and workflows make no progress until a replica is promoted and the Temporal services reconnect. Running workflows survive if the promoted replica holds the committed data, but the outcome depends on the database's replication mode and the lag at the moment of failure. Confirm this with the database owner, then rehearse the promotion end to end, including how Temporal reconnects, because documentation alone rarely settles it. Visibility degradation is a different problem. If the Elasticsearch or OpenSearch cluster is degraded, workflows still execute and history is still written to persistence, but list and search queries in the Web UI and CLI fail or return stale results. Workflow code should not depend on visibility queries for correctness, and alerts should track visibility health separately from workflow execution health.

A full region loss removes every service and the persistence store in one place, and in-cluster replica placement does not help. Running workflows are unavailable until the team restores into another region from backups or a replicated store, or until a second cluster in another region takes over. Confirm which of these the design actually provides, because a single-region self-hosted cluster has no built-in region failover. The team should agree in advance who declares a region failover and on what criteria, document the cutover steps for clients and workers, and rehearse them against a restored copy of persistence. Visibility needs its own restore or rebuild, so search should not be relied on in the recovered region until its index is current.

What to monitor, back up, upgrade and document after go-live

A highly available Temporal Service stays that way only if someone watches it, restores it, upgrades it and writes down how it is built. The four areas below cover the signals, data protection, version discipline and records that keep the cluster recoverable after the project team leaves.

Service health and replica counts

Track health and replica counts for the frontend, history, matching and worker services separately, because each scales and fails on its own. Alert when a service drops below the replica count you designed for, not only when it stops responding. Confirm which metrics your chosen Temporal deployment method exposes and where they are collected before go-live.

Persistence latency and replication lag

The persistence store is the usual limit on a Temporal cluster, so watch latency and, for replicated Cassandra, PostgreSQL or MySQL setups, replication lag between nodes. Lag that grows during peak workflow volume can turn a single node failure into lost progress or slow failover. Set thresholds with the database team and agree who responds at night.

Load balancer health

The load balancer in front of the frontend service decides whether clients reach a healthy node at all. Check that unhealthy frontend instances are removed from rotation and that the health check tests real service readiness, not only that a port is open. Review the balancer configuration after every Helm or deployment change.

Visibility indexing and query errors

Advanced visibility runs on Elasticsearch, OpenSearch, MySQL or PostgreSQL depending on your design, and a lagging or failing visibility store makes workflow search return stale or no results. Monitor indexing delay and query errors separately from workflow execution health, since workflows can run normally while search breaks. Confirm the visibility backend version is in the supported list for your Temporal Server release.

Worker connectivity

Workers connect to the frontend and poll task queues, so a network change or certificate expiry can stop processing without any server alarm. Track worker counts per task queue and the age of the oldest unprocessed task. Test worker reconnection after a frontend failover as part of the failover drill.

Backups and restore testing

Back up the persistence store and the visibility data on schedules that match your recovery goals, and treat the two as separate restore targets. A backup that has never been restored is unverified, so run a restore into a non-production environment on a set schedule and confirm workflows resume. Agree the recovery point and recovery time targets with the business owners before choosing the backup method.

Upgrades one minor version at a time

Upgrade one minor version at a time, moving to the latest patch of the current minor first, because backward compatibility is guaranteed only between successive minor versions. Where release notes require it, run schema upgrades before server upgrades. Upgrade guidance is part of keeping HA intact, and the full process is covered in the sibling upgrade topic.

Topology, failover runbook and owners

Document the cluster topology, including services, replica counts, databases, visibility backend, network zones and the multi-cluster design if you use one. Write a failover runbook with the steps, decision makers and rollback points, and name an owner for each component. Review the document after every upgrade or topology change, because an out-of-date runbook fails during an incident.

How to test that Temporal high availability works and fails safely

A high availability design for Temporal is only proven once the team has broken it on purpose. Before go-live, write a test plan that covers four things: how the services are placed across failure domains, what happens when each critical component fails under load, whether workers and visibility recover correctly, and whether the failover runbook works when someone other than its author follows it. Start with placement. Confirm which zones the frontend, history, matching and worker services run in, where the persistence replicas sit, and where the visibility store nodes are. Ask your platform team and database owners for the topology the scheduler and database tools report, and compare it with the design document. Any gap found here is cheaper to fix than one found during an outage.

Next, run controlled failure drills while test workflows run continuously. Use a non-production environment with the same server version, persistence and visibility stores, and service counts as production. Run four drills: stop one frontend replica, stop one history node, fail over the persistence primary, and take down the visibility store. Keep the load running throughout and record the time of each fault, the errors that clients and workers report, and the time normal processing resumes. After each drill, check that every test workflow completed, that event histories are complete with no gaps, and that no activity was silently skipped. Retried activities are expected during a failover, so agree with the workflow owners in advance which side effects they must be able to tolerate.

Two further tests cover recovery paths that drills alone miss. First, after a frontend failover, confirm that SDK workers reconnect to the surviving frontend endpoints without manual restarts and that tasks are polled again. Second, restart the visibility store and confirm that list queries and search attribute filters return the same results as before, which may require a reindex or a rebuild depending on the store you chose. Then test backup restore into a clean environment. Restore the persistence and visibility backups, start the same server version, and verify that open workflows resume and that completed workflows can be queried. A backup that has never been restored is an assumption, not a control, so record how long the restore took and which steps needed judgment.

The last test is a timed check of the failover runbook. Ask an on-call engineer who did not write the runbook to follow it during a scheduled drill, time each step, and note every instruction that needed interpretation. Update the runbook from those notes and repeat the check after the change. Define pass criteria in writing before any drill starts: the maximum acceptable error window, the maximum time to restore workflow processing, the requirement that no history is lost, and the alerts that must fire. Confirm each threshold with your own operations, security and business owners, because this page does not supply numeric targets and the right values depend on your service commitments. Keep the drill records as evidence for internal review and for any compliance assessment your organization is preparing for.

What buyers ask about Temporal high availability before hiring help

How much does highly available Temporal cost to run compared with Temporal Cloud?

Self-hosted cost is mostly infrastructure and people, while Temporal Cloud is metered. Temporal Cloud 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. Its SLA is 99.9%, or 99.99% with high availability (Temporal pricing page). A self-hosted cluster instead carries compute for the frontend, history, matching and worker services, a highly available database (Cassandra, PostgreSQL or MySQL), an advanced visibility store such as Elasticsearch or OpenSearch, backups, monitoring, and on-call engineers. The build is largely one-time, while infrastructure and staffing recur every month. Ask any partner for a quote that lists each component separately. The cost of ownership topic walks through a full comparison.

How long does it take to design and build a highly available Temporal cluster?

The duration depends on the drivers, not on a fixed template. The main drivers are the database and visibility store you choose, whether your team already runs that store with failover, the number of environments, how deeply Temporal connects to your identity provider and network controls, and how much failover and load testing you require. An existing, well-tested database platform shortens the work. A new Cassandra ring or a new Elasticsearch cluster adds build and tuning time. Your written scope should list milestones, the decisions each one needs, and who signs off. Use that scope, not a general estimate, to compare offers and to plan your internal calendar.

What must our team provide before a highly available Temporal project starts?

Four inputs decide whether the work can start on schedule. First, database access: admin accounts for test and production, backup configuration, and maintenance windows. Second, network design: subnets, load balancers, firewall rules and private connectivity, because the Temporal deployment docs say services should run on hosts that are not reachable from the public internet. Third, named on-call owners for the Temporal services, the database and the visibility store, with escalation paths. Fourth, a written availability target, such as the uptime level and recovery time your business accepts. Also provide your identity provider details, the environments in scope, and a decision on whether one cluster or several is in scope.

Can an internal team run highly available Temporal without outside help?

Yes, if the team operates the store you choose and can rehearse failover. The team needs working experience with the database or visibility store, including replication, backup and restore, and node loss. It also needs to follow Temporal's server upgrade steps and to run drills that stop a node, lose a zone and restore from backup, then record what happened. If those skills are missing, a partner can help with the design review, load testing, runbooks and the first failover drills, and then hand the cluster over. Check the team's experience with the chosen store before deciding, because a plan that nobody has rehearsed is not a working high availability design.

Do we always need a multi-cluster Temporal setup for high availability?

No. The answer depends on the availability target and the failure scenarios you need to survive. A single cluster with a highly available database and several instances of each Temporal service spread across availability zones may meet an internal target. A multi-cluster design adds replication, failover logic, extra infrastructure and more runbooks, so it makes sense when you must survive a regional outage or when recovery time targets are strict. Write down the failure scenarios first, then choose the topology. Confirm the current multi-cluster replication behavior for your server version in the Temporal documentation before you commit to it in the design.

Which Temporal server versions should we plan for in a new highly available build?

Plan around the latest supported lines, and confirm the exact versions on the day you build. The Temporal GitHub releases list Temporal Server v1.32.1, published October 8, 2026, and patch releases v1.31.4 and v1.30.8, published October 12, 2026. New patches can appear before your build starts, so check the releases page again. Upgrade one minor version at a time, moving to the latest patch of the current minor first, because backward compatibility is guaranteed only between successive minor versions. Run schema upgrades before server upgrades when the release notes call for it. Helm chart versions below 0.73.1 do not work with server images 1.30 and later, so match the chart to the server image.

Which database should back a highly available self-hosted Temporal Service?

Choose the store your team can operate with failover, from the options Temporal tests. Temporal persistence is tested on 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. SQLite is meant only for development and testing. For advanced visibility, Temporal supports Elasticsearch 7 and 8, and OpenSearch 2 or later from Temporal Server 1.30.1. Cassandra visibility was removed in 1.24, and Elasticsearch or OpenSearch is recommended for anything beyond a few workflow executions. Compare each option on replication, failover behavior, backup and restore, and the skills on your on-call team. Confirm supported combinations against the persistence and visibility documentation for your target version.

How DeployOpen scopes, builds and hands over Temporal high availability

DeployOpen plans and implements self-hosted open-source platforms inside the client's own infrastructure, including high availability for the Temporal Service. Work starts from a written, fixed scope that names the services, data stores and failure cases to be covered before any build begins.

How we scope

Inventory which Temporal services run per cluster and how frontend, history and matching capacity will be sized and separated
Confirm the persistence store choice (Cassandra, PostgreSQL or MySQL) and its replication and failover model in your environment
Decide the visibility store and whether Elasticsearch or OpenSearch is in scope, and document the multi-cluster requirement

How we build

Deploy the Temporal Service with Docker Compose, Go binaries or Helm on your own platform, with each service scaled independently
Configure highly available external databases and visibility stores, and check that Temporal services run on hosts not reachable from the public internet
Test failover of individual nodes, services and data stores, and record the observed behavior against the agreed scope

How we hand over

Deliver architecture, topology and runbooks covering scaling, failover, backup, restore and the server upgrade sequence
Walk your platform and on-call teams through the deployment, monitoring signals and the failover test results
Provide configuration and evidence in a form your auditors or internal reviewers can inspect, without claiming any certification

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the build
Support can cover minor-version upgrades one step at a time, including schema changes and Helm chart compatibility checks
Confirm with DeployOpen during scoping which support hours, response expectations and escalation paths the retainer includes