Managed workflow orchestration where workers run in our VPC/on-prem (vendor doesn’t run our code) — what options exist?

Quick Answer: If you want a managed workflow orchestration service but insist that all workers stay in your VPC or on‑prem (so the vendor never runs your code), your realistic options narrow to platforms that clearly separate control plane from worker execution—Temporal Cloud is the canonical example, alongside a few “control-plane‑only” orchestration and eventing tools.

Frequently Asked Questions

What does “managed workflow orchestration where workers run in our VPC/on‑prem” actually mean?

Short Answer: It means the vendor manages the orchestration control plane, but all code that runs your business logic (workers) executes inside your own infrastructure—your VPC, Kubernetes clusters, or on‑prem servers—so the vendor never runs or sees your code.

Expanded Explanation:
Most “managed workflow orchestration” products collapse two concerns: they both store state and execute your code on their infrastructure. That’s often a non‑starter if you’re in a regulated environment, have strict data residency requirements, or simply don’t want your vendor executing your business logic.

The architecture you’re looking for is a clean split between control plane and data plane. The vendor runs a multi‑tenant or dedicated control plane (APIs, durable state, scheduling, coordination), while your workers—processes that actually execute the tasks and workflows—run inside your environment. They connect out to the vendor over secure, unidirectional channels, poll for work, and report results. Temporal is designed around exactly this separation: the Temporal Service (control plane) runs in Temporal Cloud or self‑hosted, while your Workers (data plane) always run where you deploy them. Either way, we never see your code.

Key Takeaways:

• You want the vendor to manage orchestration state and reliability, not your execution environment.
• The right architecture is “vendor‑managed control plane, customer‑run workers,” with unidirectional connections out from your VPC/on‑prem.

---

How does Temporal Cloud handle managed orchestration when workers stay in our VPC/on‑prem?

Short Answer: Temporal Cloud runs the durable orchestration control plane, while your Workflow and Activity Workers run entirely in your own environment, polling Temporal task queues over secure connections—so the orchestration is managed, but your code and runtime stay under your control.

Expanded Explanation:
With Temporal, your application logic is written as Workflows and Activities using native SDKs (Go, Java, TypeScript, Python, .NET). These are compiled into Worker processes that you deploy on your own infrastructure—Kubernetes in your VPC, bare‑metal, or on‑prem clusters. The vendor (Temporal) never runs your code.

Temporal Cloud hosts the Temporal Service: the part that stores durable Workflow histories, coordinates execution, tracks timers, and manages task queues. Workers in your environment open outbound connections to Temporal Cloud, poll task queues, execute Workflows/Activities, and then report results back. If a Worker crashes, the Temporal Service keeps the complete event history and hands the task to another Worker, which simply replays and resumes from the latest state.

Your data plane stays where you want it. The control plane is managed for you. Failures happen—Temporal makes them irrelevant for execution completeness.

Steps:

1. Define Workflows and Activities as code using a Temporal SDK in your preferred language.
2. Deploy Workers in your VPC/on‑prem using your existing CI/CD, Kubernetes, or VM tooling.
3. Connect Workers to Temporal Cloud via secure, outbound connections to poll task queues and execute tasks, while Temporal Cloud handles state, retries, timers, and visibility.

---

How does Temporal compare to other managed orchestrators for this model?

Short Answer: Many workflow engines require you to run code on the vendor’s infrastructure, while Temporal is explicitly designed for managed orchestration with workers running in your VPC/on‑prem, with strict separation between control plane and worker code.

Expanded Explanation:
Without Temporal, your options usually fall into two camps:

• Fully hosted orchestrators that insist on running your jobs in their runtime (serverless functions, containers, “steps”). They may expose a “connect your cluster” feature, but they still push significant execution logic into their environment.
• Self‑managed workflow engines or schedulers you have to host and operate end‑to‑end, including state stores, queues, and UIs.

Temporal takes a different path. Temporal Cloud handles the orchestration primitives and durable execution history. You run the workers. The Temporal Service doesn’t execute your code; it just coordinates Workflows and Activities via task queues and event histories. This gives you a managed experience while still satisfying strict boundaries on code execution and data plane control.

Comparison Snapshot:

• Option A: Fully hosted runtime orchestrators (vendor runs your code):
  Easy to start, but vendor controls runtime, may see code/data, and often can’t run in your private networks.
• Option B: Temporal Cloud (vendor runs control plane, you run workers):
  Managed coordination, durable state, and visibility; your code and workers remain in your VPC/on‑prem with outbound‑only connectivity.
• Best for:
  Teams that want managed, highly reliable orchestration and durable workflows, but must keep execution and sensitive integrations inside their own infrastructure.

---

How do we actually implement Temporal with workers in our VPC or on‑prem?

Short Answer: You write Workflows and Activities as regular code, deploy Worker services into your VPC/on‑prem, and configure them to connect securely to Temporal Cloud; from there, Temporal’s task queues, retries, and timers take care of durable execution.

Expanded Explanation:
Implementing Temporal in a “workers in our VPC/on‑prem” model looks like a normal application rollout, not a special orchestration deployment. You integrate the Temporal SDK into your service, define Workflows (orchestrating logic) and Activities (the actual I/O and side effects), and then package and deploy Workers just like any other microservice.

Temporal Cloud runs the Temporal Service in multiple regions. Your Workers open outbound TLS connections to the service endpoints, poll their task queues, and execute tasks. Because each Workflow’s complete event history is stored durably by Temporal Cloud, Workers can crash, restart, or move without losing progress—the workflow is replayed deterministically from its history until it catches up to the last event.

What You Need:

• Worker runtime in your environment: Kubernetes cluster, VMs, or on‑prem servers where you can run long‑lived Worker processes.
• Secure, outbound network access to Temporal Cloud: TLS‑protected connectivity from your VPC/on‑prem to Temporal Cloud endpoints, plus any required IAM or key management to authenticate namespaces and clients.

---

Strategically, why choose this architecture instead of self‑hosting or fully hosted orchestrators?

Short Answer: Running workers in your VPC/on‑prem while using a managed orchestration control plane lets you offload durability and coordination, preserve strict boundaries around code and data, and dramatically reduce the time you spend building and maintaining custom state machines and recovery logic.

Expanded Explanation:
Distributed systems fail. APIs fail, networks flake, services crash, and users abandon sessions. You can keep writing custom retry loops, compensation logic, and ad‑hoc state machines scattered across microservices—or you can make reliable execution a primitive of your platform.

With Temporal in this model, you stop building and operating your own orchestration layer. Temporal Cloud gives you durable Workflow histories, replay‑based recovery, policy‑driven retries, long‑running timers, schedules, and a Web UI that lets you inspect, replay, and rewind every Workflow execution. Meanwhile, you keep strict control over what matters most: your code, your secrets, your data plane, and your regulatory posture, because all of that lives in your VPC or on‑prem.

This isn’t about abstract “enterprise‑grade robustness.” It’s about fewer orphaned processes, fewer 2 a.m. runbooks, and the ability to say, “We can move money, fulfill orders, or roll back deployments reliably, even when everything around us is failing.”

Why It Matters:

• Reduced operational toil and risk: Stop maintaining bespoke orchestration infrastructure and manual recovery; let durable execution and replay handle failures by design.
• Security and compliance alignment: Keep code execution and sensitive integrations inside your own boundaries while still using a proven, managed control plane that never runs or sees your code.

---

Quick Recap

If you’re looking for managed workflow orchestration where workers run in your VPC or on‑prem, you’re really asking for a control‑plane‑only service that never executes your code. Temporal is designed for this: Temporal Cloud runs the durable orchestration service; your Workers—running in your VPC or data center—connect out, poll task queues, execute Workflows and Activities, and report results. You get durable execution, policy‑driven retries, long‑running timers, and deep visibility, without handing your runtime over to a vendor or rebuilding state machines by hand.

Next Step

Get Started