Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.kubiya.ai/llms.txt

Use this file to discover all available pages before exploring further.

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 task 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 task 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 Task 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 Task 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.