Skip to main content
The control plane is the coordination layer for everything that runs in Kubiya. It owns routing, shared configuration, and policy enforcement. Anything you create: agents, teams, environments, workflows, and worker queues, lives inside the currently selected control plane. Control Plane You can use the Kubiya Hosted control plane (fully managed) or deploy Self-Hosted control planes in your own infrastructure.

​
What it does

  • Orchestration & routing – Receives tasks from the Composer and sends them to the right worker queue.
  • Configuration hub – Central place for:
    • Tool definitions and Skills
    • MCP server connections
    • LLM gateways / model routing
    • Organization policies and guardrails
    • Integrations and credentials (attached through Environments)
  • Context registry – Surfaces your Projects, Teams, Environments, and Policies so agents run with the right context.
  • Observability & audit – Streams status/logs and keeps a complete execution history per plane.

​
Hosted vs. Self-Hosted

  • Kubiya Hosted (Managed) – Fastest way to start and evaluate. Best for internet-reachable workloads. Zero ops burden.
  • Self-Hosted Control Plane – Use when you need VPC-only access, compliance boundaries, or custom integrations. Full access to private resources; you operate and scale it.
Most orgs mix both: begin on Hosted and add one or more Self-Hosted planes for sensitive or high-throughput work.

​
Scope & isolation

  • The selected control plane is the active scope for the UI. New objects are created in that plane.
  • Objects and executions do not cross planes. Switching planes does not move tasks or data.
  • Common patterns: one hosted plane for experimentation; dedicated self-hosted planes per region/business unit.

​
What you’ll configure

When creating a self-hosted plane, you’ll choose:
  • Deployment platform
    • Enterprise: Kubernetes Operator (recommended), OpenShift Operator
    • Serverless (zero infra mgmt): Vercel, GCP Cloud Run, AWS Lambda, Cloudflare Workers
  • Resource profile – Minimal (dev), Standard (prod), or High Performance
  • Security & RBAC – Cluster-wide access (optional), network policies, run-as-non-root
  • Storage – Enable persistent storage and pick a storage class
  • Components – Workflow Engine, Dagger Runtime (container tool execution), Image Updater
  • Monitoring & telemetry – Prometheus metrics and OpenTelemetry tracing

​
Create a control plane

  1. Open: In the left nav, go to Infrastructure > Control Planes and click Create Control Plane (or use the control-plane switcher at the top-left and choose Create Self-Hosted Control Plane).
  2. Choose your deployment platform:
    • Kubernetes/OpenShift for full control and observability.
    • Serverless options for zero-ops evaluation or lightweight workloads.
  3. Basic setup:
    • Name – Unique, lowercase; shown across the UI.
    • Deployment target – Pre-selected by the platform you chose.
    • Resource profile – Minimal / Standard / High Performance.
    • Options – Toggle Persistent storage (recommended for prod), Monitoring & telemetry, and Cluster-wide access (only if tools require cross-namespace access).
  4. Advanced configuration (optional):
    • Security & RBAC – Network policies; run as non-root; scope cluster-wide access if needed.
    • Storage – StorageClass and retention.
    • Components – Enable/disable Workflow Engine, Dagger Runtime, Image Updater.
    • Telemetry – Prometheus + OpenTelemetry; scrape interval.
  5. Generate install assets: Click Create Control Plane. The UI produces a platform-specific config (e.g., a values.yaml) and an install command.
    • Kubernetes/OpenShift: run the shown command (Helm/Operator) with permissions to create namespaces, deployments, services, PVCs, and (if enabled) cluster-wide roles.
    • Serverless: follow the shown deploy command/link for your provider.
  6. Verify readiness: After deployment, the plane appears in Control Planes with a Ready status. From here you can:
    • Register LLM Gateways and MCP Servers
    • Create Skills
    • Set Policies
    • Proceed to Environments, Agents, Teams, Projects, and Worker Queues

​
Good defaults

  • Start on Kubiya Hosted; add self-hosted planes as needs grow.
  • Enable Persistent storage for anything beyond quick trials.
  • Keep Cluster-wide access off unless a tool genuinely needs it; prefer namespace-scoped access.
  • Turn on OpenTelemetry to integrate traces with your observability stack.

​
Notes & migration

  • Execution capacity comes from Worker Queues attached to the plane.
  • Executions are deterministic and step-isolated; failures are contained to the failing step and visible in audit logs.
  • To move assets between planes, export/import workflows and recreate dependent objects (environments, Skills, policies) on the target plane.