When self-hosting Temporal beats Temporal Cloud, and when it does not
Choose Temporal Cloud if you want Temporal Technologies to operate the Temporal Service, including persistence, replication, version upgrades and availability, while your team sizes the compute for its own Workers. Choose a self-hosted Temporal Service if your rules require the orchestration service, its persistence and its event history to stay inside your own network. Most teams land on one side of that line once they know whether a regulator, customer contract or internal security policy decides where workflow state may live. Self-hosting makes sense when the constraint is data location or network control rather than staffing. A self-hosted cluster runs Frontend, History, Matching and Worker services plus a persistence store and, for visibility, a separate store, and the Temporal deployment docs say these services should run on hosts not reachable from the public internet. Self-hosting also gives you control over the security layer: if you configure mTLS, a ClaimMapper and an Authorizer, you decide who can do what. Remember that without an Authorizer, the default noopAuthorizer allows every API request. The cost is that your team owns upgrades (one minor version at a time), schema changes, backups and capacity, and that work recurs for as long as the cluster runs. Cloud gives up some control in exchange for operations you no longer run. Your workflow state sits in a service run by Temporal, and Cloud runs in 20 regions, 14 on AWS and 6 on Google Cloud, with new Namespace provisioning in all Google Cloud regions temporarily restricted from October 2026 except through a support ticket. Check that the region and cloud you need are available before you commit. Application code moves between the two models with connection changes: your code points at a Cloud Namespace, and Moving clients means changing the namespace and gRPC endpoint and adding a certificate and key or an API key. Confirm the Cloud controls you need with Temporal, and plan an ownership review for the Workers that stay in your environment either way.
How the two models compare on operations, data and features
This table sets Temporal Cloud beside a self-hosted Temporal Service across operations, data handling, access controls, licensing and pricing structure. Read each row as a question to answer for your own environment, and note that the Cloud prices shown are published list prices, not a quote for your workload.
| Factor | Temporal Cloud | Self-hosted Temporal Service |
|---|---|---|
| Who operates the Temporal Service | Temporal operates the service, including persistence, replication, version upgrades and availability. You size the compute for your own Workers. | Your team operates the Frontend, History, Matching and Worker services, the persistence and visibility stores, and every upgrade. |
| Persistence and visibility | Managed by Temporal. You do not choose or run a database for the service. | You choose and run the store. Tested options are Cassandra, PostgreSQL and MySQL, with SQLite for development only. |
| Regions | 20 regions: 14 on AWS and 6 on Google Cloud. New Namespace provisioning in all Google Cloud regions is temporarily restricted from October 2026, with exceptions by support ticket. | Wherever you deploy, including your own data centers or air-gapped networks, subject to your own infrastructure. |
| Authentication default | Access is managed through Cloud Namespaces, API keys or certificates. Confirm the exact setup with Temporal. | If no Authorizer is configured, the default noopAuthorizer allows every API request with no authentication or access control. |
| SSO and mTLS | SAML SSO is listed on the pricing page. Confirm which Cloud tier includes it and how Worker connections are secured. | mTLS with separate internode and frontend settings, a ClaimMapper for JWT or certificate claims, an Authorizer plugin and OIDC single sign-on for the Web UI. |
| Payload encryption | A Data Converter encrypts payloads on your Workers, so Temporal Cloud stores only ciphertext. | Payload encryption through custom codecs and a codec server that you build and operate. |
| Licensing | Temporal Cloud is a managed service sold by Temporal Technologies. Confirm terms in the contract. | Temporal Server is MIT licensed, so you can run it yourself without a license fee for the server code. |
| Pricing structure | Pay-as-you-go Cloud list prices start at 50 US dollars per million actions, with 0.042 dollars per GB-hour for active storage and 0.00105 dollars per GB-hour for retained storage. A 99.9% SLA, or 99.99% with high availability, is listed. | No Temporal fee for the server code. Costs are your compute, persistence, visibility, networking and the staff time to run and upgrade them. Ask your team and your vendors to estimate these. |
| Moving between models | Migrating execution history from self-hosted to Cloud is not currently supported. New Workflows start on Cloud, while running ones drain, are signaled or restart with their state. | Old history stays readable on the self-hosted cluster after a move, so plan the drain window before cutover. |
What data location and compliance mean in each model
Where workflow history lives and who secures it decides much of the compliance work in each model. Temporal Cloud moves operation of the service to Temporal, while a self-hosted Temporal Service leaves every control with your team. Confirm the scope of each claim against your own data and audit requirements before you rely on it.
Where workflow history lives
In Temporal Cloud, the Temporal Service runs in Temporal's regions, and your team cannot choose the persistence layer or the hosts. On a self-hosted cluster, workflow history sits in the persistence store you operate, on Cassandra, PostgreSQL or MySQL. Ask Temporal which Cloud regions match your data residency rules, and map which history, visibility and log data each option keeps.
Ciphertext through a Data Converter
A Data Converter can encrypt workflow payloads on your Workers before they leave your network, so Temporal Cloud stores only ciphertext. This keeps business data readable only to your code, but your team then owns key management, rotation and the codec server that the Web UI needs to show decoded payloads. Test decryption paths before go-live, because a lost key makes history unreadable.
Temporal's stated certifications
Temporal Technologies states that it maintains SOC 2 Type 2 certification and complies with GDPR and HIPAA. Those are vendor statements about its own service. Request the current SOC 2 Type 2 report under NDA, and have your auditors decide whether that scope covers the regions, services and data flows you use. DeployOpen does not issue audit reports, attestations or certifications.
Self-hosted default access is open
If no Authorizer is configured, a self-hosted Temporal Service uses the noopAuthorizer, which allows every API request with no authentication or access control. Treat this as a configuration gap to close before any production traffic, not as a safe default. Confirm that Temporal services sit on hosts unreachable from the public internet and that network access is limited to trusted internal networks.
Controls your team must configure
Self-hosted Temporal supports mTLS with separate settings for internode and frontend traffic, a ClaimMapper that maps JWT or certificate claims to namespace roles, an Authorizer plugin, and OIDC single sign-on for the Web UI. Each is a configuration task your team owns, from certificate issuance to role mapping. Document each setting and test it against your access review process.
Scope and proof to confirm
Regional coverage, certification scope and the evidence an assessor will accept are questions for Temporal and your auditors, not assumptions to carry into a design. Ask Temporal for its current assurance documents and the regions covered by them. On the self-hosted side, your own evidence of configuration, access logs and key handling is what an assessor will review. DeployOpen can prepare systems and evidence for that review, but the assessment itself belongs to independent auditors.
Why the Google Cloud restriction matters for region planning
The Google Cloud restriction only matters if your Workers or data residency rules point you at Google Cloud. Temporal Cloud runs in 20 regions, 14 on AWS and 6 on Google Cloud. From October 2026, new Namespace provisioning in all Google Cloud regions is temporarily restricted, and exceptions go through a support ticket. Before you commit, confirm with Temporal which regions are open for new Namespaces on the day you sign, because the restriction is described as temporary and its end date is not part of the supplied material. Check the current state on the Temporal Cloud regions documentation and get any exception request in writing.
A practical check for a team on Google Cloud is to map three things before the contract: the region your Workers and client applications run in, the region your regulators or customers require for workflow data, and the lead time you need if a Namespace must be created during a migration window. Ask whether an AWS region can host your Namespace while your compute stays on Google Cloud, and what cross-cloud latency and egress costs that adds, since those figures come from your own traffic model rather than from Temporal's documentation. Also ask who pays for the support-ticket path and how long it takes, because that is a planning dependency, not a formality.
A self-hosted Temporal Service in your own Google Cloud account avoids the provisioning question altogether, because you create the Namespace on infrastructure you already control. The trade-off is that you take on the Frontend, History, Matching and Worker services, the persistence store and the upgrade path yourself, as covered elsewhere on this page. If your timeline cannot tolerate a restricted provisioning window, or if you cannot get an exception, a self-hosted cluster is the fallback to cost out with your platform team. Note that the documented migration path does not move existing execution history from a self-hosted cluster into Temporal Cloud, so choose the hosting model before your first production Workflows start.
What your team runs in each model
Running the Temporal Service directly on Docker Compose or from Go binaries suits evaluation, development and smaller single-team footprints. Your team starts the Frontend, History, Matching and Worker services yourselves and connects them to a persistence store. Persistence is the decision that shapes everything else, so choose it deliberately. Temporal tests 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.
- Persistence: Pick PostgreSQL, MySQL or Cassandra for anything beyond a development box. Your team owns backups, failover and capacity for that store.
- Visibility store: Cassandra visibility was removed in 1.24, so a Cassandra deployment needs a separate visibility store. Elasticsearch or OpenSearch is recommended once you run more than a few workflow executions.
- Upgrades: Move one minor version at a time, starting with the latest patch of your current minor. Run schema upgrades before server upgrades when the release notes call for them.
- Network placement: Temporal's deployment docs say services should run on hosts not reachable from the public internet.
- Security defaults: Without a configured Authorizer, the default noopAuthorizer allows every API request, so you must configure authentication yourselves.
Confirm the persistence and visibility versions you plan to run against the current Temporal documentation before you size the store.
The Helm chart runs each Temporal Server service in its own Kubernetes pods, which is the usual route for teams already operating clusters. Your platform team owns the cluster, the ingress and the stateful dependencies, and Temporal's chart owns how the services are wired together. The chart version matters: Helm chart versions below 0.73.1 do not work with server images 1.30 and later, so pin the chart to a version that matches your server image.
- Chart floor: Use chart 0.73.1 or later with server images 1.30 and later. Check the compatibility notes for each upgrade.
- Stateful dependencies: Persistence and advanced visibility run outside the Temporal pods, so you still operate a PostgreSQL, MySQL or Cassandra cluster and an Elasticsearch or OpenSearch cluster if you use them.
- Identity and TLS: mTLS, the ClaimMapper, the Authorizer plugin and OIDC single sign-on for the Web UI are configured by your team.
- Upgrade sequencing: Run schema changes first, then roll the server one minor version at a time.
- Worker placement: Your application Workers run in your own namespaces or clusters, sized by your team.
Ask your platform team to confirm which chart version pins your current server image before any upgrade is scheduled.
In Temporal Cloud, Temporal operates the Temporal Service, including persistence, replication, version upgrades and availability. Your team runs only the Workers that execute your workflow and activity code, and sizes that compute for its own load. Applications built for a self-hosted Temporal Service run on Temporal Cloud without code changes, but the connection configuration must point at a Cloud Namespace. Temporal Cloud runs in 20 regions, 14 on AWS and 6 on Google Cloud, and new Namespace provisioning in all Google Cloud regions is temporarily restricted from October 2026, with exceptions through a support ticket.
- Operated by Temporal: Persistence, replication, version upgrades and availability.
- Operated by you: Worker compute, Worker deployments and the code they run.
- Connection changes: Namespace and gRPC endpoint move to the namespace_id.account_id.tmprl.cloud format, with an SSL certificate and key or an API key.
- Data protection: A Data Converter on your Workers can encrypt payloads so Temporal Cloud stores only ciphertext.
- Migration limit: Execution history cannot move from a self-hosted cluster to Cloud, so running Workflows must drain, be signaled or be restarted with their state.
Check the current Cloud region list and the Google Cloud restriction against your data residency needs before you commit.
How to move clients to Temporal Cloud without moving history
The documented sequence moves client connections to Temporal Cloud and lets new Workflows start there, while execution history stays on the self-hosted cluster that produced it.
Inventory namespaces, Workers and running Workflows
The platform team lists each self-hosted Namespace, the Workers that serve it, and the Workflow types that are still running. Include Workflows that wait on timers or signals, because those are the ones that need a deliberate decision. The step is done when every running Workflow is assigned to one of three outcomes: drain, signal or restart with its state. Confirm the inventory with the application owners before any cutover work starts.
Provision the Cloud Namespace and credentials
The cloud administrator creates the target Namespace in Temporal Cloud and issues the authentication material the clients will use, either an SSL certificate and key or an API key. Record which option each team will use and where the secrets are stored. The step is done when each client team can reach the new Namespace from a test Worker using its own credentials. Confirm with Temporal which authentication option fits your identity and secrets setup before issuing credentials.
Repoint client connections to the Cloud endpoint
Application teams change the Namespace name and gRPC endpoint in their connection configuration to the namespace_id.account_id.tmprl.cloud format and add the certificate and key or API key. Workflow code stays the same, since the documentation describes configuration changes only. The step is done when a test Workflow starts on the Cloud Namespace and completes using the new connection settings. Keep the self-hosted connection settings available for rollback until the cutover is accepted.
Start new Workflows on Temporal Cloud
From the cutover date, client applications start all new Workflow executions against the Cloud Namespace. Monitor the first executions in the Temporal Cloud interface and your own Worker logs to confirm that Workers are polling and that tasks complete. The step is done when new executions finish on Cloud and no new Workflows start on the self-hosted cluster. Compute for the Workers stays with your team, since Temporal operates the service but customers size their own Workers.
Let running Workflows drain on the self-hosted cluster
Workflows that can finish on their own keep running on the self-hosted Temporal Service until they complete. The self-hosted cluster and its Workers stay up for that period, so the platform team must keep the persistence and visibility stores healthy and patched. The step is done when the running-execution count for the self-hosted Namespace reaches zero, which you confirm with your own visibility queries before decommissioning anything.
Signal or restart the remaining Workflows with their state
Long-lived Workflows that cannot wait for a drain are either signaled so the application can move them through a defined path, or restarted on Cloud with the state they need, as described in Temporal's manual migration guide. The application owner records which Workflows were moved, how their state was carried over, and how outputs are reconciled. The step is done when every Workflow on the inventory has a documented outcome and a test confirms the new run behaves correctly. This work is application-specific, so it usually takes the most planning.
Keep self-hosted history readable and confirm the reverse path
Execution history is not migrated, so the self-hosted cluster keeps the old history readable for audits, support and investigations. Retain that cluster, its persistence store and its access controls under your retention policy. The reverse direction, moving history or running workloads from Cloud back to self-hosted, is a planning question to confirm with Temporal, since the documentation covers the forward path only. The step is done when the retention plan and the reverse-path answer are written into the decommissioning record.
Questions buyers ask before choosing a Temporal hosting model
What does self-hosting Temporal cost in staff and infrastructure?
Self-hosting cost is mostly people and compute, and neither is published by Temporal as a fixed figure. The recurring parts are the infrastructure for the Frontend, History, Matching and Worker services, the persistence store (Cassandra, PostgreSQL or MySQL), and a visibility store, which Temporal recommends as Elasticsearch or OpenSearch for anything beyond a few workflow executions. The staff cost covers upgrades, which Temporal says should move one minor version at a time, plus monitoring, backups, on-call and security configuration. What drives the total is the number of workflow executions, the retention period, how many regions you run in, and how many people already operate these stores. Ask for a written breakdown of which of these your team will carry and which a partner would carry under a fixed-scope agreement.
How long does a migration from self-hosted Temporal to Cloud take?
The duration depends on how many Workflows are running, how long they last, and how many clients must be repointed. Temporal's manual migration guide says new Workflows start on Cloud, while running ones must drain, be signaled or be restarted with their state, so long-running Workflows set the pace. Clients change their namespace and gRPC endpoint to the Cloud format and add either an SSL certificate and key or an API key. Temporal publishes no fixed timeline for this, so confirm the expected duration against your own Workflow inventory, including the longest-lived Workflow type and the number of services that connect to Temporal.
Can our team run a self-hosted Temporal cluster without outside help?
A team with Kubernetes or VM operations experience and database administration skills can run a cluster, but it has to own several moving parts. Temporal documents Docker Compose, Go binaries, Helm charts and custom Go builds as deployment paths, and it notes that Helm chart versions below 0.73.1 do not work with server images 1.30 and later. The default authorizer allows every API request unless you configure one, so the team must also own identity, mTLS and namespace roles. Assess whether you have people who can handle schema upgrades before server upgrades, patch cycles and failover testing. If not, a fixed-scope setup or runbook engagement is one option to evaluate.
What pricing components does Temporal Cloud publish?
Temporal's pricing page lists pay-as-you-go components: actions, active storage and retained storage. It states actions starting at 50 US dollars per million, active storage at 0.042 US dollars per GB-hour and retained storage at 0.00105 US dollars per GB-hour. It also lists a 99.9% SLA, or 99.99% with high availability, and SAML SSO. Your bill depends on action volume, the size of active and retained state, and the availability tier you select, so model these with your own execution counts and retention needs. Compute for your own Workers is a separate cost you size yourself, as Temporal's Cloud overview notes. Confirm current rates and any enterprise terms directly with Temporal before budgeting.
Can we move our existing execution history from self-hosted Temporal to Cloud?
No. Temporal's manual migration guide states that migrating execution history from a self-hosted Temporal Service to Temporal Cloud is not currently supported. New Workflows start on Cloud, running Workflows must drain, be signaled or be restarted with their state, and the old history stays readable on the self-hosted cluster. Plan to keep the self-hosted cluster available for read access for as long as you need that history, and confirm with Temporal whether your compliance retention requirements can be met that way.
What does Temporal Cloud change for our security and platform teams?
Temporal Cloud moves operation of the Temporal Service, including persistence, replication, version upgrades and availability, to Temporal, while your team still sizes and secures the Workers that run your code. Temporal states it maintains SOC 2 Type 2 certification and complies with GDPR and HIPAA, and a Data Converter running on your Workers can encrypt payloads so Cloud stores only ciphertext. Your team still owns Worker network access, key management for codecs, API key or certificate rotation and any Cloud region choice. Note that new Namespace provisioning in all Google Cloud regions is temporarily restricted from October 2026, with exceptions through a support ticket. Confirm which regions and attestations apply to your data residency and audit scope with Temporal and your auditor.
Does DeployOpen's fixed-scope work cover Temporal setup, hardening or migration planning?
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. Within that model, self-hosted Temporal setup, hardening of the authorizer, mTLS and payload encryption, and migration planning for moving Workers to Cloud can each be scoped separately. DeployOpen does not publish a price list, so a quote follows from the written scope. DeployOpen does not issue audit reports or certifications, so compliance evidence still comes from your independent auditor. Ongoing upgrades and testing are available as retainers.
What drives the cost of each model and what to ask for in a quote
In Temporal Cloud, Temporal bills for the service and you pay for your own Workers. The published pay-as-you-go list 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 Cloud pricing page. Actions and storage recur for as long as Workflows run and history is retained, so the main cost levers are the number of Workflow executions, how many activities and signals each one generates, and how long closed histories are kept. The Worker compute that executes your code is billed by your cloud provider or your own hosts in both models. Confirm current rates and any committed-use terms directly with Temporal, because the list price is only a starting point.
Self-hosting moves the bill from metered usage to infrastructure and people. A self-hosted Temporal Service needs compute for the Frontend, History, Matching and Worker services, a persistence database (Cassandra, PostgreSQL or MySQL), and an advanced visibility store such as Elasticsearch or OpenSearch once volume grows. Those are recurring costs, as are backups, monitoring, and staff time for upgrades. Upgrades are one-time work for each minor version, but they recur across the year because Temporal Server should move one minor version at a time. Ask your team to estimate operator hours per quarter, including on-call coverage and the time to perform schema upgrades before server upgrades.
A written scope from DeployOpen should name every cost owner and every deliverable. DeployOpen does not publish prices and does not estimate its own fees, so the quote follows from the agreed scope. Ask for the scope to state which environments are covered, which persistence and visibility stores are in scope, whether Worker hosting and the Helm or Docker Compose deployment are included, how mTLS, the Authorizer and OIDC for the Web UI are configured, and whether a codec server is part of the work. Separate one-time items (design, deployment, migration, hardening, documentation) from retainers for upgrades and support. Also ask what the client must provide, such as cloud accounts, database capacity and staff time, because those costs sit outside DeployOpen's fee.
Four decisions that settle the hosting model
Four decisions usually settle whether Temporal Cloud or a self-hosted Temporal Service fits. Each one can point in a different direction, so decide them in parallel and record which constraint is binding for your organization before comparing prices or features.
Data residency and region fit
Temporal Cloud runs in 20 regions, 14 on AWS and 6 on Google Cloud, and new Namespace provisioning in all Google Cloud regions is temporarily restricted from October 2026, with exceptions through a support ticket. If your data must stay in a specific country or cloud, a self-hosted cluster in your own accounts gives you full placement control. If a Cloud region matches your requirement, use a Data Converter so that Temporal stores only ciphertext. Confirm the current region list and Google Cloud status with Temporal, and confirm residency terms with your auditor.
Access controls and SSO requirements
A self-hosted Temporal Service uses the default noopAuthorizer unless you configure an Authorizer, so every API request is allowed until you add authentication. Self-hosting supports mTLS, a ClaimMapper for namespace roles, an Authorizer plugin and OIDC single sign-on for the Web UI, but your team builds and tests that chain. Temporal Cloud pricing lists SAML SSO. Map each control your assessor expects to a specific feature in each model and confirm how it is evidenced.
In-house capacity for persistence and upgrades
Self-hosting makes your team responsible for the Frontend, History, Matching and Worker services, the persistence store, and visibility storage. Upgrades move one minor version at a time, with schema changes applied before server upgrades when release notes call for them. In Temporal Cloud, Temporal operates the service, persistence, replication, version upgrades and availability, while you size the compute for your own Workers. If no one on your team can own on-call and upgrade cycles, the managed model lowers that operating load.
Tolerance for a history migration gap
Temporal's manual migration guide states that moving execution history from a self-hosted Temporal Service to Temporal Cloud is not currently supported. New Workflows start on Cloud, while running Workflows must drain, be signaled or be restarted with their state, and old history stays readable on the self-hosted cluster. If long-running Workflows cannot be restarted safely, plan a drain window and a parallel run period. Ask Temporal for the current migration options before you commit to a cutover date.
How to test the choice before committing
This sequence lets the team check regions, certifications, connection changes, Worker sizing and self-hosted operations against documented facts before any migration decision is made.
Confirm regions and certification requirements
The platform or compliance lead checks whether your data residency needs can be met by Temporal Cloud's 20 regions, which span 14 on AWS and 6 on Google Cloud. Note that new Namespace provisioning in all Google Cloud regions is temporarily restricted from October 2026, with exceptions available through a support ticket. Ask Temporal Technologies to confirm in writing its SOC 2 Type 2 scope, GDPR and HIPAA positions, and whether they cover your specific workloads. The step is done when the region shortlist and certification questions are written down and answered by the vendor.
Prototype the connection change on a Cloud Namespace
An engineer takes a non-production client application built for a self-hosted Temporal Service and points only its connection configuration at a Cloud Namespace. Moving the client means changing the namespace and gRPC endpoint to the namespace_id.account_id.tmprl.cloud format and adding either an SSL certificate and key or an API key. Record every code or configuration change needed, since the documentation says applications should run without code changes. The step is done when a test Workflow completes end to end and the list of changed settings is recorded.
Size Workers for your own workload
Because Temporal operates the service while customers size the compute for their own Workers, the platform team measures the Worker footprint the prototype needs. Run representative Workflows at the expected concurrency and record CPU, memory and task queue behavior. Ask Temporal to confirm how pay-as-you-go action volume and storage would map to the measured load, using its published rates for actions and storage as a starting reference. The step is done when a Worker sizing estimate is documented and checked against the vendor's pricing model.
Test a self-hosted deployment against the persistence matrix
The platform team stands up a self-hosted Temporal Service using Docker Compose or the Helm chart, with the Helm chart version at or above 0.73.1 for server images 1.30 and later. Choose a persistence store from the tested matrix: Cassandra, PostgreSQL 13 to 16, or MySQL, and confirm SQLite is used only for this development test. Add an Elasticsearch or OpenSearch visibility store if the expected execution volume is more than a few workflows, and enable the Authorizer, mTLS and OIDC settings, since the default noopAuthorizer allows every request. The step is done when the cluster runs with authentication configured and the security team has reviewed the network placement, which should not be reachable from the public internet.
Rehearse an upgrade path
The operations team practices an upgrade on the test cluster, moving one minor version at a time and to the latest patch of the current minor first. Run schema upgrades before server upgrades whenever the release notes call for it. Confirm that the team can operate this cycle on its own, since Temporal Cloud handles version upgrades for you while the self-hosted path does not. The step is done when a successful upgrade is logged with the steps followed and the rollback approach is written down.
Plan the migration of running Workflows
The engineering lead maps every running Workflow and decides whether each will drain, receive a signal, or restart with its state on Cloud. Confirm with Temporal that migrating execution history from a self-hosted cluster to Cloud is not currently supported, so new Workflows start on Cloud while old history remains readable on the self-hosted cluster. Plan how the old cluster will be kept available for reads and for how long, and state this to auditors. The step is done when a signed migration plan exists that names owners, Workflow categories and the retention of the self-hosted history.
How DeployOpen scopes and supports self-hosted Temporal
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Temporal, that means working through the choice between Temporal Cloud and a self-hosted Temporal Service against your data residency, identity and operating constraints before any build begins.
How we scope
- Written scope names the Temporal Namespaces, Workflow types and Worker fleets in use before any work starts
- Scope records which persistence store, visibility store and hosting target the self-hosted option would use
- Scope states which data, payloads and history must stay on your infrastructure and which may move to Cloud
How we build
- Deployment of the Frontend, History, Matching and Worker services in your cloud accounts, data centers or air-gapped networks
- Configuration of mTLS, the ClaimMapper, the Authorizer and OIDC single sign-on for the Web UI
- Payload encryption through a custom codec and codec server, with Worker-side testing of the encryption path
How we hand over
- Runbooks covering server upgrades one minor version at a time and schema upgrades ordered ahead of server upgrades
- Architecture and security documentation covering network placement, access control and the decisions recorded in scope
- Handover sessions with your platform and security teams, with written deliverables agreed in the scope
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Security testing of the Temporal deployment and its Worker applications can be scoped separately
- Compliance readiness material is prepared for your assessors, who issue any audit reports or certifications
