Skip to main content
A Global Virtual Cloud is a cloud you define: pick locations from any mix of provider regions, clusters you registered, and your own hardware, and Control Plane makes them behave as one. It is the ground every workload is created on: the workload runs in all of the GVC’s locations at once, and moving it somewhere new is an edit to the GVC, not a redeploy. An org can carry many GVCs, each spanning its own set.

​
How It Fits

What a region does with its availability zones, a GVC does with whole regions: several places become one place to deploy, with the routing and failover between them built in. The shape you know: a provider region, us-east-1, marked with the AWS logo, contains availability zones us-east-1a, us-east-1b, and us-east-1c. The same shape, one level up, drawn larger: a GVC, my-gvc, contains five locations across the world: aws-us-east-1 with the AWS logo, gcp-southamerica-east1 with the Google Cloud logo, azure-westeurope with the Azure logo, oci-il-jerusalem-1 with the Oracle logo, and my-hardware, your own machines, marked with a server tower. The difference: a region's zones are fixed, while you choose and change what a GVC spans. An availability zone protects you from a datacenter dying. A GVC protects you from the failures above that: a whole region going down, a provider outage, or every user being far from the one region you picked. Workloads are created in the GVC, and the GVC spans the locations. A workload, my-app, is created in the GVC my-gvc; identities and volume sets live in the GVC too. The GVC provides shared env vars, pull secrets, geo routing, and tracing. Arrows labeled spans fan out from the GVC to two locations, aws-eu-central-1 with the AWS logo and gcp-us-east1 with the Google Cloud logo: any mix of regions, clusters, and your own hardware. You create a workload once. Control Plane runs it in every location the GVC spans.

​
Key Behaviors

  • The location set is the deployment target. Adding a location provisions it for every workload in the GVC; removing one drains its replicas and shifts traffic to the locations that remain. Neither touches a workload definition.
  • Traffic finds the nearest healthy location. That is every endpoint’s default; location routing options reshape it with a priority tier per location, a latency nudge up or down, and a latency threshold past which a location is treated as unavailable. The same location can behave differently in two GVCs.
  • The GVC name is part of every endpoint. It becomes the namespace that keeps two workloads of the same name apart: my-app.my-gvc.cpln.local internally, and my-app-$gvcAlias.cpln.app for the public canonical endpoint, whose shape endpointNamingFormat controls.
  • Shared configuration lives on the GVC. Pull secrets linked once let every workload inside pull from private registries, environment variables set here reach only the containers that opt in with inheritEnv, and tracing configured on the GVC overrides the org’s for everything inside.
  • KEDA is a per-GVC switch. It stays off until you enable it, and it is what makes event-driven autoscaling and scale-to-zero available to the standard and stateful workloads inside.

​
Gotchas

  • A GVC holding a volume set cannot be deleted. The request is rejected with GVC my-gvc cannot be deleted because it contains at least one volume set. Delete the volume sets first, accepting that their data goes with them.
  • Deletion cascades to everything else. Workloads and identities in the GVC go with it, and any child tagged cpln/protected=true blocks the delete until the tag is removed. See resource protection.
  • The name cannot be changed. Renaming means creating a new GVC and moving its workloads, which changes every endpoint they publish.
  • A dedicated load balancer is billed per location. Enabling the dedicated load balancer unlocks custom ports, protocols, and wildcard hostnames, and creates one load balancer in each location the GVC spans.
  • Quotas cap both the GVCs and what is inside them. An org has a quota of GVCs, and each GVC has quotas of workloads, identities, and volume sets. Splitting an application across two GVCs doubles the room but also doubles the locations, routing, and pull secrets you maintain; the quota catalog lists the defaults.

​
Learn More

GVC reference

Every field: placement, routing, pull secrets, tracing, load balancing, and KEDA.

Create a GVC

Pick locations and get your first GVC running.

Locations

The provider regions, BYOK clusters, and own-hardware locations a GVC can span.

Deploy your first workload

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