Durable Workflow Orchestration
How do we connect our workers to Temporal Cloud from a private network/VPC (networking and firewall requirements)?
7 min read
Most teams want the reliability benefits of Temporal Cloud without ever exposing their private networks. The good news is that Workers connect out to Temporal Cloud over standard, encrypted HTTPS—no inbound ports, no opened firewalls, no VPN backdoors. You keep your code and data in your own VPC; Temporal Cloud just coordinates execution.
Quick Answer: Connect your Workers to Temporal Cloud by allowing outbound, TLS-encrypted traffic from your private network/VPC to Temporal Cloud endpoints (typically over port 443). Connections are unidirectional, so you don’t need to open your firewall to inbound traffic or expose your Workers publicly.
Frequently Asked Questions
What are the basic networking and firewall requirements to connect Workers to Temporal Cloud?
Short Answer: Your Workers need outbound HTTPS (TLS) access from your VPC/private network to Temporal Cloud endpoints, usually on port 443. No inbound firewall rules or public exposure of your Workers are required.
Expanded Explanation:
Temporal’s model is simple: your Workflow and Activity code runs in your infrastructure, and Temporal Cloud acts as a durable coordination service. Workers initiate the connection to Temporal Cloud over TLS. The Temporal Service never dials back into your network.
In practice, this means you configure your VPC or data center firewall to allow egress traffic from your app/Worker subnets to Temporal Cloud’s endpoints. All communication is encrypted-in-transit, and you can further encrypt payloads at the application layer with your own keys. Because all connections are unidirectional—from your app to the Service—you don’t need to open inbound ports or poke holes in your firewall.
Key Takeaways:
- Allow outbound HTTPS (TCP 443) from your Workers to Temporal Cloud endpoints.
- No inbound firewall rules, VPNs, or direct connectivity from Temporal Cloud into your VPC are required.
How do we actually connect Workers from a private VPC to Temporal Cloud?
Short Answer: Configure your Workers with the Temporal Cloud address and credentials, and allow outbound HTTPS from your VPC. The Worker SDK handles connection management; your network just has to let that traffic out.
Expanded Explanation:
Connecting from a private VPC looks just like connecting from any other environment, with one additional step: making sure your security group, NACLs, or on-prem firewall allow egress to Temporal Cloud. In Kubernetes or VM-based deployments, that usually means enabling outbound 443 to the relevant Temporal Cloud domains.
On the application side, you configure the Temporal SDK (Go, Java, TypeScript, Python, .NET) with your Temporal Cloud namespace and TLS settings (certs/keys or other auth method provided by Temporal Cloud). The SDK opens a secure, long-lived connection to the Temporal Service over gRPC and uses that for task polling, heartbeats, and result reporting. Since Workers are clients, they can live entirely within your private network.
Steps:
- Confirm outbound egress: Ensure your VPC or data center allows outbound TCP 443 to Temporal Cloud endpoints (check your Temporal Cloud account for exact domains/regions).
- Configure TLS/auth in your Workers: Set up the Temporal SDK with your Temporal Cloud namespace, address, and TLS credentials.
- Deploy Workers in your private network: Run Workflow/Activity Workers inside your VPC/private subnets; they initiate secure connections to Temporal Cloud and start polling task queues.
How is Temporal Cloud connectivity different from traditional inbound API or VPN-based models?
Short Answer: Temporal Cloud uses unidirectional, outbound-only connections from your Workers, unlike traditional systems that require inbound access, VPNs, or peering for callbacks.
Expanded Explanation:
Most “managed workflow” or orchestration tools eventually want inbound access to your systems: webhooks, callbacks, or direct DB/API access. That usually means opening ports, configuring inbound rules, or setting up complex VPN/peering. Every new integration becomes a security and networking negotiation.
With Temporal, the flow is reversed. Workflows run as code inside your Workers. Temporal Cloud never calls your services or databases directly; it only queues tasks and records event histories. Your Workers poll those queues over an outbound TLS connection, run Activities in your VPC, then push results back. There is no need for Temporal Cloud to reach into your network.
Comparison Snapshot:
- Traditional inbound model: Managed service calls back into your APIs or infrastructure; requires inbound firewall rules, webhooks, VPNs, or peering.
- Temporal Cloud model: Workers in your VPC call out to Temporal Cloud over HTTPS; no inbound connectivity from Temporal Cloud into your network.
- Best for: Teams that want durable, long-running workflows with strong security boundaries and minimal firewall exposure.
What does a secure Worker-to-Temporal Cloud setup look like in practice?
Short Answer: A secure setup runs Workers inside your VPC, uses outbound TLS-encrypted connections to Temporal Cloud, and optionally encrypts payloads with your own keys so Temporal never sees clear-text data.
Expanded Explanation:
Temporal is secure by design. Workflow and Activity code ships as part of your application, deployed on your infrastructure. All communication to Temporal Cloud is encrypted, and only event history plus opaque payloads are stored on the service side. Sensitive fields can be encrypted in your app before they leave your VPC; the Temporal Service stores only ciphertext.
Because Workers are the ones initiating connections, you can keep them on private subnets with no public IPs, fronted by NAT or outbound-only proxies. This pattern is common for financial services, healthcare, and other regulated environments that already lock down egress tightly.
What You Need:
- Outbound-only network path: NAT gateway, proxy, or equivalent that allows TCP 443 from Worker nodes to Temporal Cloud.
- TLS + optional app-level encryption: Temporal Cloud TLS configuration plus any data encryption you apply with your own libraries and keys (Temporal Cloud never needs your keys or clear-text data).
How should we think about this from a security and architecture strategy perspective?
Short Answer: Treat Temporal Cloud as a durable, external coordination layer while keeping execution and data inside your VPC. Outbound-only connectivity gives you reliability primitives without expanding your attack surface.
Expanded Explanation:
Without Temporal, you tend to build reliability by scattering state machines, custom retries, and reconciliation jobs across microservices. Each one talks to others over networks that fail, with logs as your only source of truth. To harden this, you add VPNs, complex ACLs, and ever more brittle glue.
With Temporal Cloud, you centralize coordination in a managed Durable Execution Service that never runs your code and never needs to call you back. Your security boundary stays clean: Workers live in your private network, talk out to Temporal over TLS, and enforce whatever internal security policies you already have (IAM, service meshes, zero trust, etc.). Temporal gives you durable workflows, automatic retries, and full visibility via the Web UI without forcing you to expose new ingress paths.
Why It Matters:
- Reduced attack surface: No inbound holes in your firewall, no external service calling into your private APIs, and no need to grant Temporal Cloud direct network access to your systems.
- Durable reliability as a primitive: You get long-running, fault-tolerant workflows—“no lost progress, no orphaned processes”—while keeping code and data under your control in your VPC.
Quick Recap
Connecting Workers to Temporal Cloud from a private network or VPC is an outbound-only, TLS-encrypted pattern: Workers run inside your infrastructure, initiate secure connections over port 443 to Temporal Cloud, and never accept inbound traffic from the service. You don’t open your firewall; you just allow egress. Temporal Cloud coordinates execution and stores event history, while your code and sensitive data stay in your environment, optionally encrypted end-to-end with your own keys.