> ## Documentation Index
> Fetch the complete documentation index at: https://controlplanecorporation-majid-docs-content-expansion.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# What is Control Plane?

> One platform for running workloads on any cloud, any cluster, and your own hardware.

## Overview

Control Plane is a cloud virtualization platform that lets you compose any combination of cloud infrastructure, bare metal, VMs, Kubernetes, AWS, GCP, Azure, and OCI, into one or more AI-native virtual clouds. Organizations use it to cut infrastructure costs by [30% to 50%](https://controlplane.com/customers/minga), eliminate vendor lock-in, and securely deploy [workloads](/concepts/workload), [VMs](/reference/workload/vm), and [AI agents](/guides/sandbox/getting-started) across single-cloud, multi-cloud, hybrid, and on-prem environments from a single AI-enabled interface.

Workloads run simultaneously across any combination of infrastructure and [connect to any cloud service without embedded credentials](/concepts/identity). The platform handles identity propagation and authorization uniformly, applying least-privilege principles consistently across environments. [SOC 2 Type II, PCI DSS Level 1, HIPAA, and GDPR compliant](/compliance).

## Why run on Control Plane?

Rather than restricting you to a single cloud, Control Plane lets you build a resilient, unified multi-cloud environment.

Some of the attributes that set Control Plane apart include:

* **Multi-Region and Multicloud Compute**: With Control Plane, your workloads run across any combination of geographic regions and cloud providers, including AWS, Azure, GCP, OCI, and other public or private clouds, and on Kubernetes clusters of your own, in any cloud or on your own hardware, whether you run them yourself through [CPLN BYOK](/byok/overview) or have Control Plane run them for you through [Managed Kubernetes](/mk8s/overview). Adding a provider or moving between them is an edit to the [locations](/concepts/location) your virtual cloud spans, and every workload in it follows automatically.

* **Any Cloud Backing Service**: Microservices running on Control Plane have native access to services across clouds, such as BigQuery on GCP, Microsoft Entra ID on Azure, and SQS on AWS, without embedding credentials by using [Universal Cloud Identity](/reference/identity#cloud-provider-access). This enables you to mix and match services from multiple clouds by unifying networking, identity, and authorization policies across supported clouds. Control Plane's [Cloud Wormhole](/reference/identity#private-network-access) functionality enables your microservices to access native AWS, Azure, and GCP services within and across VPCs. Using Cloud Wormhole, workloads can also access endpoints behind firewalls on-premises and on a developer's laptop during development.

* **Efficient Cloud Cost Optimization**: Cloud consumption is optimized on Control Plane to use only the resources required, enabling serverless-like benefits without rearchitecting your microservices. Whether your app has a Dockerfile or was originally designed for serverless, the platform runs your microservice with elastic scalability, from zero to any scale you specify.

* **Unified Interface**: Cloud platforms differ significantly in their APIs, CLIs, and UIs. Each has a specialized, often convoluted interface, with its unique and steep learning curve. Control Plane provides a symmetrical [Console](https://console.cpln.io/signup), [API](/api-reference/api), [CLI](/cli-reference/overview), [Terraform](/iac/terraform) and [Pulumi](/iac/pulumi) providers, an [MCP server](/ai/mcp), and a [Kubernetes operator](/core/kubernetes-operator) that enable developers to deploy and run workloads in **any** cloud. It allows developers to deploy and manage workloads uniformly across multiple clouds simultaneously, from a single, consistent interface, making workload deployment and day-2 operations easy to manage.

* **Uniform Access Control**: One [access control](/concepts/access-control) system governs Control Plane itself and your workloads alike. A [policy](/reference/policy) grants a [principal](/concepts/access-control#principals), whether a user, a group, a service account, or a workload's identity, permissions on a whole resource kind, on named resources, or on whatever a query matches, so simple and complex access patterns are written the same way.

* **Built-In Audit Trail**: Control Plane provides a tamper-proof [audit trail](/core/audittrail) facility for both platform actions and custom workloads. Your code writes to a configured localhost port, and audit events are captured and secured automatically. Audit data is indexed and can be efficiently searched programmatically or via the user interface.

* **Best-of-Breed DevOps Stack**: Control Plane integrates the best of the cloud-native operations stack for metrics, logging, secrets management, software-defined VPN, geo-intelligent DNS, and more. You can also easily integrate the tools of your choice.

**The result: your application costs less to run, runs wherever you choose, and stays fast and available for the end user.**

Control Plane uses advanced, redundant health monitoring and geographically distributed DNS infrastructure. The platform automatically reroutes traffic to healthy regions and clusters. It removes unhealthy and unreachable nodes from rotation, improving availability and reducing latency for end users. A user from one part of the world experiences ultra-low-latency responses, while a user on the other side of the planet experiences similar 20 to 30 ms latency.

Control Plane enables you to use the full range of services and the computing power your application requires across multiple clouds while delivering uniform and predictable performance to your users.

## The building blocks

An [org](/concepts/org) is a self-contained environment. It holds the users, groups, and service accounts you grant access to, the policies and [quotas](/concepts/quota) that govern them, the [cloud accounts](/reference/cloudaccount) and [wormhole agents](/reference/agent) that connect it to your clouds and private networks, the locations it can deploy to, the [secrets](/reference/secret), [images](/reference/image), and [domains](/reference/domain) its workloads use, and its Global Virtual Clouds ([GVCs](/concepts/gvc)). No policy or internal route crosses from one org into another, which is why one org for staging and another for production keeps the two apart while a single [billing account](/concepts/billing) pays for both.

Inside an org you create one or more GVCs. Each GVC picks the locations its workloads run in. You create a workload once, in a GVC. A workload is your application packaged as one or more containers that deploy, scale, and stop together, and Control Plane runs it in every location the GVC spans, one [deployment](/concepts/deployment) per location, running as many [replicas](/concepts/replica) as you set, with no per-location step. Edit that one definition and every location follows.

<img src="https://mintcdn.com/controlplanecorporation-majid-docs-content-expansion/rUryc3z9dDsnWr_V/images/concepts/platform-model.svg?fit=max&auto=format&n=rUryc3z9dDsnWr_V&q=85&s=930321561fb51ee53c41726f19bfec4f" alt="An org, staging, holds a GVC, my-gvc, drawn as a panel containing the workload my-app. Arrows labeled spans fan out from the GVC to three locations: aws-us-east-1 with the AWS logo, gcp-us-central1 with the Google Cloud logo, and my-hardware with the Kubernetes logo. Each location holds one deployment of my-app, drawn as two replica chips, replica 01 and replica 02. You create the workload once, inside the GVC, and Control Plane runs it in every location the GVC spans, at the replica count you set. One org, one GVC, one workload, three locations, and two replicas in each." style={{maxWidth:'720px',width:'100%',margin:'1.75rem auto',display:'block'}} width="720" height="484" data-path="images/concepts/platform-model.svg" />

Add a location to the GVC and every workload in it rolls out there automatically; remove one and they withdraw. Per-location differences, a larger scale in one region or suspending it in another, are overrides on the workload, not separate workloads.

## Where your workloads run

A location is what a GVC selects to run its workloads in. Control Plane supplies a catalog of them across AWS, GCP, Azure, and OCI regions, and CPLN BYOK adds locations backed by Kubernetes clusters of your own, in any cloud or on your own hardware, which you run yourself or have Control Plane run for you through Managed Kubernetes.

| Shape             | What a GVC spans                                    | Where to start                      |
| ----------------- | --------------------------------------------------- | ----------------------------------- |
| Single cloud      | Regions of one provider                             | [Locations](/reference/location)    |
| Multi-cloud       | Regions of several providers at once                | [GVC](/reference/gvc)               |
| Hybrid            | Provider regions alongside clusters you already run | [CPLN BYOK](/byok/overview)         |
| Your own hardware | Bare metal or VMs you run, joined as cluster nodes  | [Managed Kubernetes](/mk8s/generic) |

## Based on Kubernetes

While Kubernetes orchestrates workloads within a single cluster, Control Plane orchestrates an unlimited number of hardened, security-isolated Kubernetes clusters across all regions in major cloud providers. You can also add Kubernetes clusters from any cloud as custom CPLN BYOK regions. You can use Control Plane without in-depth knowledge of Kubernetes, but if you already deploy your own clusters, the platform augments and extends your current Kubernetes infrastructure.

<img src="https://mintcdn.com/controlplanecorporation-majid-docs-content-expansion/Ry1Mkgc7uPHC-gur/images/concepts/kubernetes-layers.svg?fit=max&auto=format&n=Ry1Mkgc7uPHC-gur&q=85&s=e8c56c131166fbf5c20502451ef8d60f" alt="Control Plane sits above many Kubernetes clusters. Clusters reach it three ways: built-in Control Plane regions, Managed Kubernetes clusters Control Plane provisions on your infrastructure, and CPLN BYOK clusters you already run. Each becomes a location a GVC can span." style={{maxWidth:'720px',width:'100%',margin:'1.75rem auto',display:'block'}} width="720" height="306" data-path="images/concepts/kubernetes-layers.svg" />

CPLN BYOK registers a cluster you already run and keep running. With Managed Kubernetes, Control Plane provisions and operates the cluster for you, on any supported infrastructure provider or on Linux servers you supply.

## Workload types

Every workload has a type, chosen at creation, that decides how it scales and what it can expose.

| Type         | What it is                                                                                   | Scale to zero |
| ------------ | -------------------------------------------------------------------------------------------- | ------------- |
| `serverless` | A request-driven application on exactly one port, over HTTP, HTTP2, gRPC, or TCP             | Yes           |
| `standard`   | A long-running service, exposing no port, one port, or several                               | Only via KEDA |
| `stateful`   | Stable per-replica identity and persistent storage, for databases and queues                 | Only via KEDA |
| `cron`       | A background task that runs on a schedule and then exits                                     | No            |
| `vm`         | A KubeVirt-backed [virtual machine](/reference/workload/vm) with its own guest OS and kernel | No            |

Every type runs one or more containers, up to eight, and a container can reserve an [Nvidia GPU](/reference/workload/containers#gpu). The `vm` type is the exception. It boots a full guest OS, Linux or Windows, inside the same service mesh, identity, and [firewall](/reference/workload/firewall) rules as the rest of your workloads.

[Sandboxes](/guides/sandbox/getting-started) give AI coding agents an isolated environment with persistent storage, reachable from a browser IDE and terminal, or from VS Code, Cursor, or SSH through [`cpln sandbox connect`](/cli-reference/commands/sandbox#sandbox-connect).

## Getting software running

Every org has a free [private container registry](/reference/image#private-registry). Push an image there and your workloads pull it with nothing to configure, or pull from Docker Hub, ECR, GCR, or any registry you already use. From there:

* **Manifests.** [`cpln apply`](/guides/cpln-apply) creates or updates any resource from YAML or JSON, so a GVC and everything in it lives in Git. [`cpln helm`](/guides/cpln-helm) does the same through Helm charts, installed as versioned releases you can roll back.
* **CI/CD.** Working pipelines for [GitHub Actions, GitLab CI, Bitbucket Pipelines, and CircleCI](/guides/gitops).
* **Promotion.** With [an org per environment](/guides/environment-promotion), the same manifests apply to each one, and an image built for dev deploys to production without a rebuild.
* **Migration.** [`cpln convert`](/guides/cli/cpln-convert) turns Kubernetes Deployments, StatefulSets, CronJobs, ConfigMaps, Secrets, and Ingresses into Control Plane resources. [`cpln stack`](/guides/compose-deploy) deploys a `docker-compose.yml` as it stands, converting its services, volumes, secrets, and networks.

For software you would rather not write, the [Template Catalog](/template-catalog/overview) installs over 80 open-source projects, PostgreSQL, Redis, Kafka, and more, into a GVC as versioned releases you can upgrade or roll back.

## How workloads connect

Everything a workload sends, to another workload or to Control Plane itself, travels over [mutual TLS with a certificate unique to that workload](/core/security#internal-certificates), and no certificate management is required. Nothing reaches the workload that you have not allowed.

<img src="https://mintcdn.com/controlplanecorporation-majid-docs-content-expansion/rUryc3z9dDsnWr_V/images/concepts/workload-connectivity.svg?fit=max&auto=format&n=rUryc3z9dDsnWr_V&q=85&s=f4dccbc2f16616d094603abd54d84915" alt="A workload connects in four directions: to other workloads, to the Internet, to private networks through a wormhole agent, and to cloud services with no stored credentials. Inbound access is denied by default in every direction." style={{maxWidth:'720px',width:'100%',margin:'1.75rem auto',display:'block'}} width="720" height="320" data-path="images/concepts/workload-connectivity.svg" />

Firewall rules decide what reaches a workload from other workloads and from the Internet, and where it may connect out. The identity attached to the workload carries its access to private networks, cloud provider services, and secrets. A wormhole agent runs inside a private network and holds a connection out to Control Plane. Name a host behind it on the identity, and the workload reaches that host's TCP and UDP ports without the network opening anything inbound. [Native networking](/guides/native-networking/native-networking-setup) does the same for services that never leave a VPC, over AWS PrivateLink or GCP Private Service Connect, listed on the identity the same way. Cloud provider services are reached through Universal Cloud Identity, which hands the workload short-lived credentials at runtime instead of storing any in it.

## What every workload gets

* **Every location its GVC selects.** One definition deploys to all of them, and a [location-specific override](/reference/workload/general#location-specific-options) changes scaling or resources in just one.
* **Autoscaling.** Replicas scale on [concurrency, requests, CPU, memory, or latency](/reference/workload/autoscaling), with [KEDA](/reference/workload/autoscaling#keda) available for event-driven triggers.
* **Right-sizing.** [Capacity AI](/reference/workload/capacity) sizes each container's CPU and memory from its historical usage, between the minimum and maximum you set.
* **Persistent storage on demand.** A [volume set](/reference/volumeset) gives each replica of a stateful workload its own volume, with snapshots and expansion, or a shared filesystem many workloads mount at once.
* **Health probes.** [Readiness and liveness probes](/reference/workload/containers#probes) decide when a replica takes traffic and when it is replaced.

## Who can do what

Access control is one system. The policy model that decides who may edit a GVC is the same one that decides which secrets a running workload may read.

<img src="https://mintcdn.com/controlplanecorporation-majid-docs-content-expansion/rUryc3z9dDsnWr_V/images/concepts/access-control.svg?fit=max&auto=format&n=rUryc3z9dDsnWr_V&q=85&s=86b3aca0f9ce5db3b996952743080797" alt="Four principal types, users, groups, service accounts, and identities, are bound by a policy to permissions on target resources. A workload reads a secret through the identity attached to it." style={{maxWidth:'720px',width:'100%',margin:'1.75rem auto',display:'block'}} width="720" height="240" data-path="images/concepts/access-control.svg" />

The fourth principal is the one a running application depends on. An identity is what you attach to a workload to give it credentials, and it is the single grant point for everything the workload needs a credential or a private path for, whether a secret, a cloud provider service, a host in a private network, or a VPC-only service over PrivateLink. A policy grants the identity the permission, and the platform supplies the credential at runtime. A workload with no identity attached holds no credentials at all, so it can reach none of these.

## Logs, metrics, traces, and audit

<Card title="Logs" href="/core/logs" icon="https://mintcdn.com/controlplanecorporation-majid-docs-content-expansion/rUryc3z9dDsnWr_V/icons/logs.svg?fit=max&auto=format&n=rUryc3z9dDsnWr_V&q=85&s=4b9284c653ef1539f73941bf080a3980" horizontal width="512" height="512" data-path="icons/logs.svg">
  Every replica, location, and provider lands in one view, queried with LogQL from the Console, the CLI, the API, Grafana, or an AI agent, and kept for 30 days by default.
</Card>

<Card title="Metrics" href="/guides/default-metrics" icon="chart-line" horizontal>
  The org, each workload, each replica, and each volume are covered before you instrument anything, with custom metrics and Grafana alerting on top.
</Card>

<Card title="Traces" href="/reference/gvc#tracing" icon="route" horizontal>
  One request followed across every workload it passes through, kept by Control Plane or sent to your own OpenTelemetry collector.
</Card>

<Card title="Audit Trail" href="/core/audittrail" icon="magnifying-glass" horizontal>
  Who changed what and when, whichever interface made the change, readable in the Console, with the CLI, through the audit API, or from an AI agent.
</Card>

<Card title="External logging" href="/external-logging/overview" icon="https://mintcdn.com/controlplanecorporation-majid-docs-content-expansion/Ry1Mkgc7uPHC-gur/icons/quota.svg?fit=max&auto=format&n=Ry1Mkgc7uPHC-gur&q=85&s=78788774c6264b247f70a81eb623a78f" horizontal width="512" height="512" data-path="icons/quota.svg">
  Org logs forwarded to S3, CloudWatch, Datadog, Coralogix, Loki, syslog, and other providers.
</Card>

## Availability and routing

Every workload gets a global [canonical endpoint](/reference/workload/general#canonical-endpoint-global), one HTTPS URL that sends each request to the nearest healthy location, and one [endpoint per location](/reference/workload/general#location-specific-endpoint) behind it. Custom domains route to a workload the same way, TLS-terminated and geo-routed, with [certificates issued and renewed for you](/core/security#external-certificates), and [location routing options](/reference/gvc#location-routing-options) set priority-based failover and the latency threshold past which a location counts as unavailable.

That routing is what the 99.999% availability SLA rests on. It applies to a workload running at least two replicas across at least two locations.

When shared routing is not enough, an [IP set](/reference/ipset) reserves a static public address per location, a [direct load balancer](/reference/workload/load-balancing) exposes workload ports through a cloud load balancer, a [CDN](/guides/configure-cdn) sits in front, and [rate limiting](/guides/rate-limiting) throttles requests before they reach your application.

## Interfaces

<CardGroup cols={3}>
  <Card title="Console" href="https://console.cpln.io/signup" icon="display">
    Point and click: explore, change one thing, read logs and metrics.
  </Card>

  <Card title="CLI" href="/cli-reference/overview" icon="terminal">
    `cpln` for scripts, CI, and getting a shell into a running replica.
  </Card>

  <Card title="REST API" href="/api-reference/api" icon="https://mintcdn.com/controlplanecorporation-majid-docs-content-expansion/Ry1Mkgc7uPHC-gur/icons/api.svg?fit=max&auto=format&n=Ry1Mkgc7uPHC-gur&q=85&s=e81574062fbfe1a5139ea91f5084e62e" width="512" height="512" data-path="icons/api.svg">
    HTTP at `api.cpln.io` when you are integrating another system.
  </Card>

  <Card title="Terraform" href="/iac/terraform" icon="https://mintcdn.com/controlplanecorporation-majid-docs-content-expansion/Ry1Mkgc7uPHC-gur/icons/terraform.svg?fit=max&auto=format&n=Ry1Mkgc7uPHC-gur&q=85&s=19deabd5e978d39905a6c83ea1f7904d" width="256" height="291" data-path="icons/terraform.svg">
    Manage every resource kind as code with the official provider.
  </Card>

  <Card title="Pulumi" href="/iac/pulumi" icon="https://mintcdn.com/controlplanecorporation-majid-docs-content-expansion/Ry1Mkgc7uPHC-gur/icons/pulumi.svg?fit=max&auto=format&n=Ry1Mkgc7uPHC-gur&q=85&s=7a7f4b9390dfa8fecf6223c88c658dcd" width="256" height="271" data-path="icons/pulumi.svg">
    The same, in TypeScript, Python, Go, or C#.
  </Card>

  <Card title="MCP Server" href="/ai/mcp" icon="https://mintcdn.com/controlplanecorporation-majid-docs-content-expansion/rKGH-n6tu4yQ_WHQ/icons/mcp.svg?fit=max&auto=format&n=rKGH-n6tu4yQ_WHQ&q=85&s=56240710075f155f61d45cb6d03295a2" width="24" height="24" data-path="icons/mcp.svg">
    Let an AI agent, from a chat app to a coding agent, operate your org.
  </Card>
</CardGroup>

<Card title="Kubernetes Operator" href="/core/kubernetes-operator" icon="https://mintcdn.com/controlplanecorporation-majid-docs-content-expansion/Ry1Mkgc7uPHC-gur/icons/kubernetes.svg?fit=max&auto=format&n=Ry1Mkgc7uPHC-gur&q=85&s=87d1a7db99bf4ccb443e11e064e45a9b" horizontal width="230" height="223" data-path="icons/kubernetes.svg">
  If you already run Kubernetes, the operator maps Control Plane resources onto CRDs, so `kubectl` and ArgoCD manage them the same way they manage everything else in the cluster.
</Card>

## Pricing

Pricing is usage-based, with no contracts or minimums. You pay for the compute, storage, and bandwidth your workloads use.

The platform features described on this page are free. The private registry, TLS certificates, DNS and geo-routing, secret storage, the service mesh, shared load balancing, autoscaling, the audit trail, log storage, and the first 50 million metric samples are all included at no charge.

See [controlplane.com/pricing](https://controlplane.com/pricing) for current rates. Invoices and the monthly spend alert live on your billing account.

## Learn more

<CardGroup cols={2}>
  <Card title="Deploy your first workload" href="/quickstart/deploy-workload" icon="rocket">
    A GVC, a running application, and a global TLS endpoint.
  </Card>

  <Card title="Core concepts" href="/concepts/org" icon="lightbulb">
    One page per building block, from org and GVC to workload, replica, deployment, identity, and access control.
  </Card>

  <Card title="How-to guides" href="/guides/overview" icon="list-ol">
    Step-by-step for domains, secrets, images, networking, and deployment.
  </Card>

  <Card title="Resource reference" href="/reference/overview" icon="book-open">
    Fields, defaults, limits, and permissions for every resource kind.
  </Card>
</CardGroup>
