How do we connect our workers to Temporal Cloud from a private network/VPC (networking and firewall requirements)?

Quick Answer: Connect your Workers to Temporal Cloud over outbound-only, TLS-encrypted HTTPS from your private network or VPC. You never expose inbound ports; all connections are unidirectional egress to Temporal Cloud endpoints, typically over port 443, using your preferred secure routing (NAT gateway, proxy, or private connectivity).

Frequently Asked Questions

What are the basic networking and firewall requirements to connect Workers to Temporal Cloud from a private VPC?

Short Answer: Your Workers need outbound-only HTTPS (TLS) connectivity to Temporal Cloud endpoints; no inbound access from Temporal Cloud into your VPC is required.

Expanded Explanation:
Temporal’s architecture is intentionally one-way. Your code (Workers and client processes) runs inside your environment; the Temporal Service runs in Temporal Cloud. Workers initiate and maintain outbound connections to Temporal Cloud task queues over TLS. Temporal Cloud never dials back into your network, never executes your code, and never requires you to open inbound ports in your firewall.

From a networking perspective, that means the minimum requirement is: allow egress from your VPC/private network to the Temporal Cloud endpoint(s) on port 443, with standard TLS. You can route this egress through a NAT gateway, HTTP(S) proxy, or private connectivity solution, as long as HTTP/2 or gRPC over TLS is supported and the Workers can resolve and reach the Temporal Cloud hostname.

Key Takeaways:

• Only outbound connections from your VPC to Temporal Cloud are required; no inbound firewall rules.
• Traffic is encrypted in transit with TLS; your app can also encrypt payloads before they leave your network.

---

How do I connect Temporal Workers to Temporal Cloud step by step from a locked-down VPC?

Short Answer: Deploy your Workers inside the VPC, configure egress to Temporal Cloud over TLS, then point the Temporal SDK in your Worker code at your Temporal Cloud namespace and endpoint.

Expanded Explanation:
You don’t move your business logic into Temporal Cloud. You keep Workers in your own compute environment (Kubernetes, VMs, serverless containers) and configure them to call Temporal Cloud. The Temporal SDK in your language (Go, Java, TypeScript, Python, .NET) uses that outbound connection to poll task queues, execute Workflows/Activities, and report progress.

The typical pattern in a restricted VPC is: Workers in private subnets, a NAT gateway or egress proxy to the internet, and security groups that allow outbound TCP/443 to Temporal Cloud. Once that’s in place, you configure the SDK with your Temporal Cloud namespace, endpoint, and credentials, and the Worker will start polling for tasks.

Steps:

1. Run Workers in your private environment

   • Deploy Worker services (Kubernetes Deployment, ECS/Fargate task, VM, etc.) inside your VPC or private network.
   • Install the appropriate Temporal SDK (Go, Java, TypeScript, Python, .NET).

2. Enable outbound TLS egress to Temporal Cloud

   • Configure security groups / firewall rules to allow outbound TCP/443 to the Temporal Cloud hostname(s) for your region.
   • Route traffic via NAT gateway, egress proxy, or private link solution as required by your network policy.
   • Ensure DNS resolution for the Temporal Cloud domain is available from your VPC.

3. Configure SDK clients and verify connectivity

   • In your Worker code, configure the Temporal client with:
     • Temporal Cloud endpoint (host:port).
     • Namespace (provisioned in Temporal Cloud).
     • TLS configuration / credentials as provided in your Temporal Cloud account.
   • Start the Worker; use Temporal Web UI to verify your Worker is polling and executing Workflows.

---

How is this different from connecting to a self-hosted Temporal cluster in my own network?

Short Answer: With self-hosted Temporal, your Workers often connect to a local cluster inside your network; with Temporal Cloud, they connect outbound over the internet (or private connectivity) to Temporal’s managed Service, but the connection pattern is still unidirectional and TLS-encrypted.

Expanded Explanation:
The core Worker-Service interaction is identical: Workers poll a task queue, execute Workflows and Activities, and report results back. The key difference is where the Temporal Service runs and how you route traffic to it.

With self-hosted Temporal, your Service usually lives inside the same VPC or data center as your Workers, often on private IPs. You manage the cluster, networking, certificates, and scaling. With Temporal Cloud, the Temporal Service runs in Temporal’s managed infrastructure across 11+ regions. Your Workers connect to a public or privately-routed endpoint, but you still keep all Worker code and data processing in your environment. Either way, Temporal never runs your code, and all communication is outbound from your apps to the Service.

Comparison Snapshot:

• Self-hosted Temporal:

  • Temporal Service in your VPC/data center.
  • Workers talk to private addresses you control.
  • You manage cluster lifecycle, upgrades, and scaling.

• Temporal Cloud:

  • Temporal Service in Temporal’s managed infrastructure in your chosen region.
  • Workers make outbound TLS connections to Temporal-managed endpoints.
  • Temporal manages scaling, upgrades, and durability for the Service.

• Best for:

  • Self-hosted: organizations requiring full in-house control of every component and willing to operate the cluster.
  • Temporal Cloud: teams that want Durable Execution as a service with minimal operational burden, while keeping Workers and data processing inside their own network.

---

What do I need to implement secure connectivity to Temporal Cloud from a private network?

Short Answer: You need outbound TLS egress to Temporal Cloud, valid credentials/TLS configuration from your Temporal Cloud account, and Worker deployments that can reach the endpoint from inside your VPC.

Expanded Explanation:
Temporal is secure by design: Workflows and Activities are part of your application, running on your infrastructure. All communication from your Workers to Temporal Cloud is encrypted; you can also encrypt payloads with your own keys before they leave your environment. The Temporal Service never needs to access your data in clear text and never sees your code.

Implementation is mostly about standard cloud networking hygiene: secure egress, DNS resolution, and minimal-privilege firewall rules. From there, the Temporal SDK handles connection management, retries, and heartbeats. You concentrate on writing Workflow and Activity code; Temporal guarantees that long-running execution survives crashes, timeouts, and outages.

What You Need:

• Network plumbing:

  • Outbound TCP/443 from Worker subnets to Temporal Cloud endpoints (via NAT, proxy, or private link).
  • DNS resolution for Temporal Cloud hostnames from your private network.

• Security and configuration:

  • Temporal Cloud namespace, credentials, and TLS configuration.
  • Worker processes configured with the correct endpoint and namespace.
  • Optional: application-level encryption of payloads using your own library and keys.

---

How should we think about networking strategy for Temporal Cloud in a larger architecture?

Short Answer: Treat Temporal Cloud as a trusted, outbound-only control plane for Durable Execution: route Workers’ traffic over your standard secure egress path, keep all sensitive processing in your VPC, and avoid opening inbound holes in your firewall.

Expanded Explanation:
Distributed systems break. APIs fail, networks flake, and services crash. Temporal’s job is to make those failures irrelevant to your business logic by persisting event histories and replaying Workflows to recover state. When you use Temporal Cloud, you’re outsourcing the durability, scheduling, and orchestration engine—but you’re not giving up network control or data locality.

Strategically, that means you model Temporal Cloud as a SaaS control plane with strict egress-only connectivity. You run Workers close to the systems they talk to (databases, payment gateways, message buses) inside your VPC. Workers communicate with Temporal Cloud over encrypted connections, while all sensitive data processing and system access stay within your private network. This gives you reliability primitives (retries, timers, signals, schedules, visibility) without expanding your attack surface with new inbound paths.

Why It Matters:

• Security posture stays tight:

  • No inbound connections from Temporal Cloud into your network; firewalls remain mostly outbound-only.
  • All communications are encrypted; the Service never needs your data in clear text and never runs your code.

• Reliability becomes a primitive, not a patchwork:

  • You stop building bespoke state machines and recovery runbooks around flaky networks.
  • Temporal Cloud provides durable histories, automatic retries, and replay, while your Workers remain safely inside your VPC.

---

Quick Recap

Connecting Workers to Temporal Cloud from a private network or VPC is straightforward: run your Workers where they are today, allow outbound TLS egress to the Temporal Cloud endpoint(s) on port 443, configure the SDK with your namespace and credentials, and keep all sensitive processing inside your environment. The connection pattern is unidirectional, encrypted, and designed so you never have to open your firewall for inbound access, while still gaining Durable Execution, automatic retries, and full visibility into every Workflow.

Next Step

Get Started