Skip to main content

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%, eliminate vendor lock-in, and securely deploy workloads, VMs, and AI agents 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. 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.

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 or have Control Plane run them for you through Managed Kubernetes. Adding a provider or moving between them is an edit to the locations 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. 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 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, API, CLI, Terraform and Pulumi providers, an MCP server, and a 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 system governs Control Plane itself and your workloads alike. A policy grants a principal, 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 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 is a self-contained environment. It holds the users, groups, and service accounts you grant access to, the policies and quotas that govern them, the cloud accounts and wormhole agents that connect it to your clouds and private networks, the locations it can deploy to, the secrets, images, and domains its workloads use, and its Global Virtual Clouds (GVCs). 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 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 per location, running as many replicas as you set, with no per-location step. Edit that one definition and every location follows. 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. 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.

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. 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. 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. Every type runs one or more containers, up to eight, and a container can reserve an Nvidia GPU. The vm type is the exception. It boots a full guest OS, Linux or Windows, inside the same service mesh, identity, and firewall rules as the rest of your workloads. Sandboxes 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.

Getting software running

Every org has a free private container 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 creates or updates any resource from YAML or JSON, so a GVC and everything in it lives in Git. 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.
  • Promotion. With an org per environment, the same manifests apply to each one, and an image built for dev deploys to production without a rebuild.
  • Migration. cpln convert turns Kubernetes Deployments, StatefulSets, CronJobs, ConfigMaps, Secrets, and Ingresses into Control Plane resources. cpln stack 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 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, and no certificate management is required. Nothing reaches the workload that you have not allowed. 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. 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 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 changes scaling or resources in just one.
  • Autoscaling. Replicas scale on concurrency, requests, CPU, memory, or latency, with KEDA available for event-driven triggers.
  • Right-sizing. Capacity AI 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 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 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. 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. 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

Logs

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.

Metrics

The org, each workload, each replica, and each volume are covered before you instrument anything, with custom metrics and Grafana alerting on top.

Traces

One request followed across every workload it passes through, kept by Control Plane or sent to your own OpenTelemetry collector.

Audit Trail

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.

External logging

Org logs forwarded to S3, CloudWatch, Datadog, Coralogix, Loki, syslog, and other providers.

Availability and routing

Every workload gets a global canonical endpoint, one HTTPS URL that sends each request to the nearest healthy location, and one endpoint per location behind it. Custom domains route to a workload the same way, TLS-terminated and geo-routed, with certificates issued and renewed for you, and 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 reserves a static public address per location, a direct load balancer exposes workload ports through a cloud load balancer, a CDN sits in front, and rate limiting throttles requests before they reach your application.

Interfaces

Console

Point and click: explore, change one thing, read logs and metrics.

CLI

cpln for scripts, CI, and getting a shell into a running replica.

REST API

HTTP at api.cpln.io when you are integrating another system.

Terraform

Manage every resource kind as code with the official provider.

Pulumi

The same, in TypeScript, Python, Go, or C#.

MCP Server

Let an AI agent, from a chat app to a coding agent, operate your org.

Kubernetes Operator

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.

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 for current rates. Invoices and the monthly spend alert live on your billing account.

Learn more

Deploy your first workload

A GVC, a running application, and a global TLS endpoint.

Core concepts

One page per building block, from org and GVC to workload, replica, deployment, identity, and access control.

How-to guides

Step-by-step for domains, secrets, images, networking, and deployment.

Resource reference

Fields, defaults, limits, and permissions for every resource kind.