|
2 | 2 | id: overview |
3 | 3 | title: Overview - Temporal Cloud |
4 | 4 | sidebar_label: Overview |
5 | | -description: Temporal Cloud is a SaaS platform managing the durability of your Temporal Applications, implemented using Temporal SDK. It supervises workflow histories and supports multiple isolated namespaces. |
| 5 | +description: Temporal Cloud is a fully managed, globally distributed durable execution platform built on cell-based architecture. Available on AWS and GCP with consumption-based pricing and zero-downtime migration from self-hosted deployments. |
6 | 6 | slug: /cloud/overview |
7 | 7 | toc_max_heading_level: 4 |
8 | 8 | keywords: |
9 | | - - explanation |
10 | | - - term |
| 9 | + - temporal cloud |
| 10 | + - managed service |
| 11 | + - durable execution |
| 12 | + - cell-based architecture |
| 13 | + - multi-cloud |
| 14 | + - high availability |
11 | 15 | tags: |
12 | 16 | - Temporal Cloud |
13 | 17 | --- |
14 | 18 |
|
15 | 19 | import { CaptionedImage } from '@site/src/components'; |
16 | 20 |
|
17 | | -When it comes to running Temporal in production, you have two main options: |
| 21 | +Temporal Cloud is a fully managed durable execution platform. |
| 22 | +It handles the complexity of running Temporal at scale—persistence, replication, upgrades, and availability—so you can focus on building applications. |
18 | 23 |
|
19 | | -**Temporal self-hosted:** |
20 | | -This option involves setting up and managing your own instance of the Temporal Server. |
21 | | -Your Workers and Temporal Application connect directly to this self-hosted instance. |
22 | | -With the self-hosted approach, you have full control over the infrastructure and are responsible for managing the persistence layer, scalability, and availability of the Temporal system. |
| 24 | +Your code runs in your environment. |
| 25 | +Temporal Cloud never sees your application logic or sensitive data. |
| 26 | +The platform stores encrypted Workflow state and orchestrates execution, while your Workers execute business logic wherever you deploy them. |
23 | 27 |
|
24 | | -**Temporal Cloud:** |
25 | | -Temporal Cloud is a fully managed service provided by Temporal. |
26 | | -It offers a hassle-free way to run your Temporal Applications without the need to manage the underlying infrastructure. |
27 | | -Your Workers and Temporal Applications connect to the Temporal Cloud service, which takes care of the persistence layer, scalability, and availability for you. |
| 28 | +## How Temporal Cloud works |
28 | 29 |
|
29 | | -Temporal Cloud and self-hosted Temporal Services have some similarities, as both require your Temporal Clients and Workers to establish a connection to the Temporal Service. |
30 | | -Additionally, in both cases, you are responsible for managing and hosting your application code and running your Workers. |
31 | | -The choice between self-hosted and Temporal Cloud depends on your specific requirements, resources, and expertise. |
| 30 | +<CaptionedImage |
| 31 | + src="/img/cloud/cloud-overview.png" |
| 32 | + title="High-level system topology" |
| 33 | +/> |
32 | 34 |
|
33 | | -### High level system topology of the Temporal Service |
| 35 | +Temporal Cloud operates as the control plane for your distributed applications: |
34 | 36 |
|
35 | | -There are two major parts of the Temporal Service that work together to create the fully functioning system. |
36 | | -Temporal Cloud is an offering of the Temporal Service. |
| 37 | +1. **Your environment**: You run Workers that execute your Workflow and Activity code. These can be deployed anywhere—Kubernetes, VMs, serverless, on-premises. |
| 38 | +2. **Temporal Cloud**: Manages Workflow state, Event History, task queuing, and scheduling. All data is encrypted in transit and at rest. |
| 39 | +3. **Temporal SDKs**: Your applications use the SDK to communicate with Temporal Cloud over secure gRPC connections. |
37 | 40 |
|
38 | | -1. Temporal SDK: The Temporal software development kit (SDK) is available in various languages and can be integrated as a dependency into your new or existing application. |
39 | | - It offers developers a comprehensive development framework and APIs, facilitating the creation and management of applications. |
40 | | -2. Temporal Cloud: Operating independently from the execution environment, Temporal Cloud oversees the execution process by preserving the source of truth for your Workflow Execution Event Histories. |
41 | | - This independent supervision ensures the durable execution of your distributed applications and services. |
| 41 | +This separation means Temporal Cloud scales independently of your application. |
| 42 | +You control compute resources for your Workers; Temporal handles the orchestration layer. |
42 | 43 |
|
43 | | -<CaptionedImage |
44 | | - src="/diagrams/high-level-system-topology.svg" |
45 | | - title="High-level system topology" |
46 | | -/> |
| 44 | +## Architecture |
| 45 | + |
| 46 | +### Cell-based infrastructure |
| 47 | + |
| 48 | +Temporal Cloud uses a cell-based architecture to achieve isolation and scalability. |
| 49 | +Each cell is a self-contained deployment unit with its own: |
| 50 | + |
| 51 | +- Dedicated cloud account and VPC |
| 52 | +- Kubernetes cluster running Temporal services |
| 53 | +- Primary database with synchronous replication across three availability zones |
| 54 | +- Elasticsearch for Workflow visibility and search |
| 55 | +- Load balancers and ingress management |
| 56 | +- Observability and certificate infrastructure |
| 57 | + |
| 58 | +Cells act as failure domains. |
| 59 | +If infrastructure within a cell experiences issues, only Namespaces in that cell are affected. |
| 60 | +This design limits blast radius and enables independent scaling. |
| 61 | + |
| 62 | +### Data plane and control plane |
| 63 | + |
| 64 | +**Data plane**: Where your Workflows execute. Each cell processes Workflow operations, persists state, and manages task queues. The data plane is optimized for low latency and high throughput. |
| 65 | + |
| 66 | +**Control plane**: Manages provisioning, configuration, and lifecycle operations. When you create a Namespace, the control plane: |
| 67 | +1. Selects an appropriate cell in your chosen region |
| 68 | +2. Provisions database resources and roles |
| 69 | +3. Generates and deploys mTLS certificates |
| 70 | +4. Configures ingress routes and validates connectivity |
| 71 | + |
| 72 | +The control plane uses Temporal itself (durable execution) to orchestrate these operations reliably. |
| 73 | + |
| 74 | +### Multi-cloud availability |
| 75 | + |
| 76 | +Temporal Cloud runs on both AWS and GCP: |
| 77 | + |
| 78 | +- **14 AWS regions** spanning North America, Europe, Asia Pacific, and South America |
| 79 | +- **5 GCP regions** in North America, Europe, and Asia Pacific |
| 80 | + |
| 81 | +You can create Namespaces in any supported region. |
| 82 | +For disaster recovery, you can replicate across regions within a cloud provider or across cloud providers entirely. |
| 83 | + |
| 84 | +See [Service regions](/cloud/regions) for the complete list of available regions. |
| 85 | + |
| 86 | +## Built-in reliability |
| 87 | + |
| 88 | +Every Temporal Cloud Namespace includes baseline high availability: |
| 89 | + |
| 90 | +- **Three-zone replication**: Workflow state synchronously replicates across three availability zones before acknowledging writes |
| 91 | +- **Automatic failover**: If one zone becomes unavailable, operations continue on the remaining zones |
| 92 | +- **99.9% SLA**: Contractual uptime guarantee for standard Namespaces |
| 93 | + |
| 94 | +### High Availability features |
| 95 | + |
| 96 | +For workloads requiring stronger guarantees, Temporal Cloud offers three replication options: |
| 97 | + |
| 98 | +| Deployment | Description | Use case | |
| 99 | +|------------|-------------|----------| |
| 100 | +| **Same-region** | Replicate across isolated cells within one region | Single-region applications needing cell-level isolation | |
| 101 | +| **Multi-region** | Replicate across regions within one cloud provider | Geographic redundancy and compliance requirements | |
| 102 | +| **Multi-cloud** | Replicate across cloud providers (AWS ↔ GCP) | Maximum resilience against provider-level outages | |
| 103 | + |
| 104 | +High Availability Namespaces include: |
| 105 | +- **99.99% SLA**: Four-nines contractual uptime guarantee |
| 106 | +- **Sub-1-minute RPO**: Recovery Point Objective for data loss |
| 107 | +- **20-minute RTO**: Recovery Time Objective for failover completion |
| 108 | +- **Automatic or manual failover**: Choose your preferred failover strategy |
| 109 | + |
| 110 | +See [High Availability](/cloud/high-availability) for configuration details. |
| 111 | + |
| 112 | +## Security model |
| 113 | + |
| 114 | +Temporal Cloud implements defense-in-depth security: |
| 115 | + |
| 116 | +### Your code stays with you |
| 117 | + |
| 118 | +Temporal Cloud never executes your application code. |
| 119 | +Workers run in your environment, connecting to Temporal Cloud over encrypted channels. |
| 120 | +You control access to your compute resources and secrets. |
| 121 | + |
| 122 | +### Client-side encryption |
| 123 | + |
| 124 | +The [Data Converter](/dataconversion) lets you encrypt payloads before they leave your Workers. |
| 125 | +Temporal Cloud stores ciphertext—if the service were compromised, your data remains encrypted. |
| 126 | +Deploy a [Codec Server](/production-deployment/data-encryption) to decrypt data in the Web UI without sharing keys. |
| 127 | + |
| 128 | +### Network isolation |
| 129 | + |
| 130 | +- **mTLS authentication**: Per-Namespace certificate-based authentication for gRPC endpoints |
| 131 | +- **API key authentication**: Alternative to certificates for simpler key management |
| 132 | +- **Private connectivity**: AWS PrivateLink and GCP Private Service Connect for traffic that never traverses the public internet |
| 133 | + |
| 134 | +### Compliance |
| 135 | + |
| 136 | +Temporal Technologies maintains SOC 2 Type 2 certification and complies with GDPR and HIPAA regulations. |
| 137 | +Audit logs capture all API operations and can be exported to your security monitoring systems. |
| 138 | + |
| 139 | +See [Security model](/cloud/security) for complete details. |
| 140 | + |
| 141 | +## Consumption-based pricing |
| 142 | + |
| 143 | +Temporal Cloud charges based on what you use: |
| 144 | + |
| 145 | +### Actions |
| 146 | + |
| 147 | +The primary billing unit. |
| 148 | +Actions are billable operations like starting Workflows, sending Signals, recording Heartbeats, and completing Activities. |
| 149 | +Pricing starts at $50 per million Actions with volume discounts as you scale. |
| 150 | + |
| 151 | +### Storage |
| 152 | + |
| 153 | +- **Active Storage**: Event History for running Workflows |
| 154 | +- **Retained Storage**: Event History for completed Workflows (configurable retention period up to 90 days) |
| 155 | + |
| 156 | +### Plans |
| 157 | + |
| 158 | +Four tiers—Essentials, Business, Enterprise, and Mission Critical—with increasing support levels, included Actions/Storage, and features like SAML and SCIM. |
| 159 | +The Essentials plan starts at $100/month. |
| 160 | + |
| 161 | +Self-serve signup and plan management available at [cloud.temporal.io](https://cloud.temporal.io). |
| 162 | + |
| 163 | +See [Pricing](/cloud/pricing) for detailed rates and examples. |
| 164 | + |
| 165 | +## Portability |
| 166 | + |
| 167 | +Temporal Cloud runs the same Temporal Server as the open-source distribution. |
| 168 | +This means: |
| 169 | + |
| 170 | +### Zero code changes |
| 171 | + |
| 172 | +Applications built for self-hosted Temporal work on Temporal Cloud without modification. |
| 173 | +Update your connection configuration to point at your Cloud Namespace—that's it. |
| 174 | + |
| 175 | +### Zero-downtime migration |
| 176 | + |
| 177 | +[Automated migration](/cloud/migrate/automated) uses Workflow replication to move running Workflows from self-hosted to Cloud (or between Cloud regions) without interruption. |
| 178 | +No Workflow restarts, no data loss, no downtime. |
| 179 | + |
| 180 | +[Manual migration](/cloud/migrate/manual) works by updating Clients and Workers to use new Namespace endpoints while existing Workflows complete naturally. |
| 181 | + |
| 182 | +### Bidirectional |
| 183 | + |
| 184 | +Move workloads from self-hosted to Cloud, Cloud to self-hosted, or between Cloud regions and providers. |
| 185 | +The same migration tooling works in any direction. |
| 186 | + |
| 187 | +## Self-serve operations |
| 188 | + |
| 189 | +Temporal Cloud is designed for self-service: |
| 190 | + |
| 191 | +- **Web UI**: Create Namespaces, manage users, configure settings at [cloud.temporal.io](https://cloud.temporal.io) |
| 192 | +- **CLI (`tcld`)**: Automate operations from the command line |
| 193 | +- **Terraform provider**: Infrastructure-as-code for Namespaces, users, and configuration |
| 194 | +- **Cloud Ops API**: Programmatic access for custom tooling and automation |
| 195 | + |
| 196 | +No support tickets required for standard operations. |
| 197 | + |
| 198 | +## Getting started |
47 | 199 |
|
48 | | -Temporal Cloud is based off of the open source [Temporal Server](/temporal-service/temporal-server) software and offers a comparable set of features but with out the overhead of setting up and deploying a production level Temporal Service (Temporal Server + all of the auxillary services it depends on). |
| 200 | +1. [Sign up for Temporal Cloud](https://temporal.io/get-cloud) |
| 201 | +2. [Create your first Namespace](/cloud/namespaces) |
| 202 | +3. [Connect your Workers](/cloud/get-started#set-up-your-clients-and-workers) |
| 203 | +4. [Run your first Workflow](/cloud/get-started#run-your-first-workflow) |
49 | 204 |
|
50 | | -Temporal Cloud is offered in units of isolation known as [Namespaces](/namespaces). |
51 | | -You can provision and use one or more Cloud Namespaces. |
52 | | -A typical use case is to use separate Namespaces as development, testing, integration, staging, and production environments for an application. |
| 205 | +For existing Temporal users, see [Migration](/cloud/migrate) to move self-hosted workloads to Cloud. |
0 commit comments