Answers you can trust, from Codeables
Every page on Codeables is structured and verified — built so people and the AI agents they rely on can trust it. Explore more from the source behind this answer.
Explore Codeables
Orkes Cloud customer-hosted on Azure or GCP: how does deployment and networking work?
For teams running Orkes Cloud in a customer-hosted model on Azure or GCP, the core idea is simple: Orkes manages the Conductor control plane and cluster as a managed service, but all compute and data live inside your own cloud accounts, under your security and networking policies. You get the same production-grade orchestration platform, while keeping traffic, state, and integrations inside your existing Azure or GCP footprint.
Quick Answer: In a customer-hosted deployment on Azure or GCP, Orkes provisions and manages dedicated Orkes Conductor clusters inside your cloud environment, typically in a private VNet/VPC, connected to your services via private links or peering. You control the network perimeter, IAM, and data residency, while Orkes handles cluster lifecycle, scaling, security patches, and operational SLAs.
Frequently Asked Questions
How does customer-hosted Orkes Cloud on Azure or GCP work in practice?
Short Answer: Orkes runs a fully managed Conductor cluster in your Azure subscription or GCP project, using your networks and regions, while providing the same orchestration features, APIs, and SLAs as Orkes-hosted deployments.
Expanded Explanation:
In the customer-hosted model, Orkes deploys Orkes Conductor into your Azure or GCP environment as a dedicated, non-shared cluster. That cluster lives in your virtual network (Azure VNet or GCP VPC) alongside your microservices, databases, queues, and LLM endpoints. Network isolation is enforced using dedicated virtual networks and private connectivity (e.g., Private Link on Azure, private service connect or VPC peering on GCP) so internal traffic never traverses the public internet.
From a developer’s perspective, nothing changes: you define workflows through the Orkes UI/JSON/SDKs, implement workers in your services (Java, Python, Go, C#, JS/TS), and invoke workflows via Orkes APIs or client SDKs. Under the hood, Orkes operates and monitors the cluster, manages upgrades, enforces RBAC and audit logging, and ensures availability up to 99.99%—but your cloud account is the execution environment.
Key Takeaways:
- The Conductor cluster runs in your Azure subscription or GCP project, not in a shared Orkes multi-tenant environment.
- You maintain full control over network topology and data residency, while Orkes assumes responsibility for platform operations and reliability.
What does the deployment process look like on Azure or GCP?
Short Answer: Deployment is a joint process: you provision the required cloud primitives (subscription/project, VNets/VPCs, IAM), and Orkes deploys and configures the Conductor cluster, networking, and observability surfaces to match your environment and compliance posture.
Expanded Explanation:
A customer-hosted rollout typically starts with an architecture and requirements review—regions, SLAs, security controls, and expected workload patterns (e.g., volume of workflows, latency needs for AI agents, event-driven workloads). Based on that, Orkes defines a deployment plan tailored to your Azure or GCP environment.
On Azure, this involves creating resource groups, VNets, subnets, private endpoints, and possibly ExpressRoute integration if you’re tying in on-prem. On GCP, you’ll provision projects, VPCs, subnets, and private connectivity (e.g., VPC peering or Private Service Connect) as needed. Orkes then deploys dedicated Orkes Conductor clusters into these environments, configures scaling behavior and non-shared address space clusters for growth, and sets up observability hooks (e.g., metrics export to Prometheus/Grafana/Datadog) and access control (RBAC, SSO/IdP integration).
You end up with one or more dedicated clusters aligned to your environments (dev/stage/prod), backed by Orkes’s managed cloud offerings but fully isolated within your cloud.
Steps:
-
Architecture & Requirements Alignment
- Choose cloud (Azure or GCP), regions, and availability targets.
- Define environments (dev/stage/prod), data residency constraints, and compliance needs (e.g., SOC 2 alignment, internal policies).
-
Cloud & Network Provisioning
- On Azure: set up subscriptions/resource groups, VNets/subnets, and Private Link/ExpressRoute as required.
- On GCP: set up projects, VPCs/subnets, peering or Private Service Connect to your service networks.
- Define network isolation boundaries and connectivity to your services, data stores, and identity providers.
-
Cluster Deployment & Integration
- Orkes deploys dedicated Orkes Conductor clusters into your Azure/GCP networks.
- Configure cluster expansion policies, metrics and logging sinks, SSO/RBAC, secrets management, and Git-like workflow versioning.
- Validate connectivity from workers and services, then roll out workflows and agentic automations.
How is networking and isolation different from Orkes-hosted deployments?
Short Answer: With customer-hosted, the cluster runs inside your VNet/VPC with private connectivity to your services; with Orkes-hosted, the cluster runs in Orkes’s cloud accounts and connects to you via secure public or private endpoints.
Expanded Explanation:
In an Orkes-hosted setup, your services integrate with an Orkes-managed cluster running in Orkes’s cloud environment. Connectivity is typically via secure, internet-exposed endpoints, optionally tightened with private connectivity options depending on the plan.
In a customer-hosted deployment, the cluster is moved into your network. You get dedicated virtual networks and non-shared address space clusters for clean isolation. All communication between Orkes Conductor and your services can stay within private IP space using private links or VPC/VNet peering. This minimizes your public attack surface, simplifies compliance narratives (everything stays “inside the tenant or project”), and avoids routing sensitive traffic over the public internet.
From a security and networking team’s POV, this is the difference between consuming Orkes as an external SaaS versus operating it as a managed platform inside your existing zero-trust, firewall, and routing policies.
Comparison Snapshot:
-
Option A: Orkes-Hosted
- Cluster runs in Orkes’s cloud accounts.
- Connectivity via Orkes endpoints (optionally restricted).
- Good when you want minimal infrastructure ownership.
-
Option B: Customer-Hosted on Azure or GCP
- Cluster runs inside your Azure subscription or GCP project.
- Dedicated VNets/VPCs, network isolation, private connectivity.
- Ideal when data residency, private networking, or strict compliance requirements drive architecture.
-
Best for:
- Regulated industries, strict security teams, or organizations that require workloads and data to remain inside their Azure/GCP footprint while delegating platform operations to Orkes.
What do I need to implement a customer-hosted Orkes Cloud deployment?
Short Answer: You need an Azure or GCP environment prepared with the right networking and IAM constructs, plus a clear view of how your services, events, and AI/LLM endpoints will connect to Orkes Conductor.
Expanded Explanation:
Before deployment, align your cloud operations and security teams around where the clusters will live and how they’ll connect to existing systems. Decide which regions/availability zones, how many environments, and what growth you expect (Orkes supports cluster expansion with non-shared address space as workflow volume scales). Ensure your policies allow Orkes to provision and manage the required resources inside your tenant/project—subject to your security guardrails.
From the application side, you’ll map out which services will run workers, which APIs and queues Orkes workflows will call (HTTP/gRPC, Kafka, etc.), and how you want to expose workflows (as internal APIs, as MCP tools for agents, or both). This is also when you plan integration with your monitoring stack and SSO/IdP.
What You Need:
-
Cloud & Security Prerequisites
- Azure subscriptions or GCP projects dedicated or scoped for Orkes clusters.
- VNets/VPCs, subnets, routing, and private connectivity options selected (Private Link / Private Service Connect / peering).
- IAM roles/permissions and organizational policies that allow Orkes to deploy and manage resources within defined boundaries.
-
Platform & Application Readiness
- Identified services that will act as workers (languages such as Java, Python, Go, C#, JavaScript/TypeScript).
- Monitoring/logging endpoints (e.g., Prometheus/Grafana/Datadog) and SSO/IdP details for RBAC.
- A plan for which workflows should be exposed as APIs or MCP tools and any human-in-the-loop requirements (Human Tasks).
Why choose customer-hosted Orkes Cloud instead of running Conductor yourself?
Short Answer: Customer-hosted Orkes gives you the control and isolation of “run it in my cloud” with the operational maturity, SLAs, and governance of a managed platform, so you avoid on-call drag and reliability gaps while keeping everything in your Azure or GCP environment.
Expanded Explanation:
Running Conductor OSS yourself on Azure or GCP sounds attractive until you’re debugging cluster outages at 3 a.m., trying to retrofit RBAC and audit logs, or coordinating upgrades across product teams. You end up building your own “mini Orkes” without the benefit of battle-tested operational patterns, metrics, and guardrails.
Customer-hosted Orkes is designed to close that gap. You get a platform that already supports 1B+ workflows executed daily across 1,200+ companies, with enterprise features like Git-like workflow versioning and rollback, fine-grained RBAC, audit logs, secrets storage, and 99.99% availability SLAs—deployed into your Azure or GCP accounts. Network isolation and private connectivity keep all communication inside private IP space, while Orkes manages cluster health, scaling, and upgrades.
For agentic systems in particular, this is the missing production layer: you can run LLM Tasks, orchestrate AI agents + humans + services, expose workflows as MCP tools with access control, and keep every run traceable and replayable—without handing over your data plane to an external multi-tenant SaaS.
Why It Matters:
-
Reduced Operational Risk & On-Call Load
- Orkes handles scaling, patching, failure recovery, and cluster expansion, backed by SLAs.
- Your teams focus on workflows and workers, not on running distributed-systems infrastructure.
-
Security, Compliance, and Governance at Enterprise Scale
- Compute and data stay in your Azure/GCP environment, aligned with your security and compliance posture.
- Network isolation, RBAC, audit logs, and secrets storage help you meet internal and external governance requirements while still moving from POC agents to production automations.
Quick Recap
In a customer-hosted Orkes Cloud deployment on Azure or GCP, Orkes provisions dedicated Conductor clusters directly inside your cloud environment, using your VNets/VPCs, regions, and connectivity patterns. All traffic between Orkes and your services can remain in private IP space via private links or VPC/VNet peering, and you retain full control over IAM, data residency, and compliance boundaries. Orkes brings the managed platform layer—scaling, upgrades, observability, RBAC, audit logs, and SLAs—so you can safely run high-volume workflows and production-grade AI agents without running your own orchestration stack.