Everything on Control Plane starts with a Global Virtual Cloud (GVC), the set of locations your applications run in, and a workload, one application that Control Plane runs in every one of those locations. This part creates a GVC that spans an AWS region and a GCP region, and one workload that runs in both, with a replica in each location. The workload’s endpoint terminates TLS, sends each request to the nearest healthy location, and routes around a location that fails, so one workload definition gives you a multi-cloud deployment that survives the loss of a region or a provider.What you’ll build:
A GVC spanning AWS and GCP locations.
A public workload serving the NGINX welcome page from both locations.
A TLS-secured global endpoint that routes each request to the nearest healthy location.
An org to deploy into. If you don’t have one yet, sign up for Control Plane: the Console walks you through creating a billing account and your first org.
A GVC defines where your workloads run across cloud providers and regions.
1
Open the Create GVC form
Click the Create dropdown in the upper right corner and select GVC.
2
Name the GVC
Enter quickstart-gvc as the name.
3
Select locations
Click Locations, then click Add Location. Select aws-us-west-2 and gcp-us-east1 to deploy across both AWS and GCP, then click OK.
4
Create the GVC
Click Create. When the Console asks Set as Current Context?, click Yes, Set Context to browse this GVC’s workloads, identities, and volume sets from the sidebar.
The workload health shows Ready once the first deployment completes.
2
Open the canonical endpoint
In the summary, under Endpoints, click the link next to Canonical Endpoint (Global). The NGINX welcome page opens in a new window, served from the location nearest to you.
3
View individual deployments
Click Deployments in the left pane. Each location lists its own endpoint; click the link icon next to it to open that specific deployment.
An org to deploy into. If you don’t have one yet, sign up for Control Plane: the Console walks you through creating a billing account and your first org.
The CLI prints a login URL and a six-digit confirmation code, then waits. Open the URL in a browser on any device, sign in, and enter the code. After the CLI confirms the login, set your default org (replace my-org with your org name):
An org to deploy into. If you don’t have one yet, sign up for Control Plane: the Console walks you through creating a billing account and your first org.
This creates a profile named default with your credentials, which the provider configuration references.
For CI/CD pipelines or environments without the CLI, create a service account token:
1
Create the service account
In the Console, click Service Accounts in the left menu, then New. Enter a name, select superusers from the Assign to Group dropdown, and click Create.
2
Create a key
Click Keys, add a description, and click Add. Copy the generated key; it is not shown again.
An org to deploy into. If you don’t have one yet, sign up for Control Plane: the Console walks you through creating a billing account and your first org.
This creates a profile named default with your credentials, which the provider configuration references.
For CI/CD pipelines or environments without the CLI, create a service account token:
1
Create the service account
In the Console, click Service Accounts in the left menu, then New. Enter a name, select superusers from the Assign to Group dropdown, and click Create.
2
Create a key
Click Keys, add a description, and click Add. Copy the generated key; it is not shown again.
Open the canonical endpoint URL in your browser. To print it again:
pulumi stack output
If the canonical endpoint doesn’t appear, the workload was created before Control Plane published it. Run pulumi refresh to read the current status, then pulumi up to re-evaluate the output. A second pulumi up on its own finds nothing to change and leaves the output empty.
An org to deploy into. If you don’t have one yet, sign up for Control Plane: the Console walks you through creating a billing account and your first org.
An AI agent that supports MCP servers, whether a chat app such as Claude Desktop, an IDE such as Cursor, or a terminal agent such as Claude Code. Every compatible tool has a setup page.
Your AI agent operates Control Plane through the MCP server, whether it runs in a chat app, an IDE, or a terminal. Pick the path for your tool:
MCP Server
Works with every MCP client, such as Claude Desktop, Claude Web, Cursor, VS Code, Antigravity IDE, Amp, or OpenCode. Point it at the endpoint and sign in.
AI Plugin
If your tool is Claude Code, Codex, or Antigravity CLI, install the plugin instead. It bundles the MCP server and adds Control Plane skills, agents, slash commands, and guardrails.
Your tool opens Control Plane in the browser: sign in, pick the orgs the agent may access, including the org you deploy into, and click Authorize. Then continue with Step 2.
Every prompt below runs in the same conversation, so name your org once (replace my-org with your org name):
Use org "my-org" for this conversation and list its GVCs.
The agent lists the org’s GVCs, or reports that there are none yet. If it answers that it has no Control Plane tools or is not signed in, finish the setup page for your tool first.
Create a public workload called "web" in that GVC from theimage nginx:alpine on port 80, with one replica per locationand the container named "web". Keep everything else at itsdefault.
The agent creates the workload, follows its deployments until both locations report ready, and reports the canonical endpoint.
Ask for the endpoint of each location. The prompt also returns the canonical endpoint, in case the agent stopped before reporting it:
Once it is ready in both locations, give me the endpoint ofeach location and its canonical endpoint.
Open the canonical endpoint in your browser. The NGINX welcome page opens, served from the location nearest to you. Then open each location’s endpoint to confirm the workload responds from AWS and from GCP.
Whichever interface you used: once the workload reports Ready, its canonical endpoint serves the NGINX welcome page:
Welcome to nginx!If you see this page, the nginx web server is successfully installed and working.
Each location also serves its own endpoint: open both from the Deployments page in the Console (or the cpln workload get-deployments web output) to confirm the workload responds from AWS and GCP.
Your workload runs on AWS and GCP behind one TLS-secured endpoint, geo-routed to the nearest healthy location.
One definition, every location: a workload runs in each location of its GVC, and a location added to the GVC later runs it too.
Availability by placement: two locations on two providers, with the endpoint routing around an unhealthy one, is what keeps the application reachable when a region or a provider fails.
The endpoint comes with the workload: TLS termination, the certificate, and geo-routing are part of every public workload.
Five interfaces, one result: the Console, the CLI, Terraform, Pulumi, and an AI agent create the same GVC and workload.
Open quickstart-gvc, click Actions, then Delete. Type the GVC name to confirm and click Delete. Deleting the GVC removes its workloads with it.
cpln gvc delete quickstart-gvc
terraform destroy
pulumi destroy
Delete the GVC "quickstart-gvc".
The agent reads the GVC, tells you that deleting it removes the workload web with it, and asks you to confirm. Your AI tool may also ask you to approve the call. Answer yes, and the GVC and its workload are gone.
Assistant
Responses are generated using AI and may contain mistakes.