A VPC is a private network that your applications, services and add-ons join to reach each other by name. Nothing outside it can reach them, and unlike the default per-resource isolation, a VPC spans every resource in a region — so an application on one resource can talk to a database on another.
The VPC itself is included on paid plans. Reaching it from outside — WireGuard, Tailscale, Cloudflare WARP or a site-to-site tunnel — is the VPN add-on, priced separately. See VPN access.

​
When you need one

You do not need a VPC to let two applications on the same resource talk to each other — that already works over the private network. Reach for a VPC when:
  • A database should stop being reachable from anything except the applications you name.
  • Applications on different resources need to reach each other.
  • Somebody needs to connect from outside the platform — a laptop, an office, another cloud.
  • Egress should leave through your own gateway rather than the platform’s.

​
One region, one router

A VPC belongs to one region and cannot span regions. The platform’s network objects are cluster-scoped, so a workspace working in two regions gets one VPC in each. They are separate routers and never see each other. Only workloads running on a resource in that region can attach. Attaching one from elsewhere is refused, rather than half-working.

​
Addressing

The range defaults to 10.224.0.0/16. If you choose your own it must be:
  • RFC1918 — 10/8, 172.16/12 or 192.168/16
  • /22 or larger — smaller leaves no room for the system addresses and a usable subnet
  • Clear of the platform’s own networks — the pod, service, join, load-balancer and node ranges
A range that breaks one of these is refused when you create it, naming the exact conflict, rather than failing later.
Two workspaces may sit on the same range without trouble — VPCs are separate routers and never see each other. The consequence is that two VPCs on the same range can never be peered. If you expect to connect this VPC to another network later, pick a range that will not collide with it.
Inside the range, the platform reserves a small block for itself — the router, the DNS resolver, and one address per VPN terminator — and reserves a pool for VPN clients. Everything else is yours to carve into subnets.

​
Creating one

1

Open Networking

Every workspace can hold several VPCs, one default per region.
2

Pick a region and a range

The region has to match the resources whose workloads will attach. Leave the range at the default unless you have a reason not to.
3

Wait for it to come up

A new VPC is pending for a moment while the platform builds the router and derives the addresses it did not ask you for — the IPv6 range, the resolver address and the VPN pool. They appear when it turns active.
4

Use the subnet it already has

A new VPC arrives with a subnet named default. It is not the first /24 of the range — the platform keeps the start of the range for the router, the resolver and the VPN terminators — so on a 10.224.0.0/16 VPC the default subnet is 10.224.1.0/24. Most setups never need a second one.

​
The resolver

Every VPC runs its own DNS resolver, shown on the overview once the VPC is active. Attached workloads use it automatically. Point your own resolver at it to resolve migetapp.internal names from your office or from a machine on the VPN.

​
What comes next

Subnets and attachments

Carve the range up, and connect applications, services and add-ons to it.

VPN access

Reach the VPC from a laptop, a tailnet or Cloudflare Zero Trust.

Site-to-site

Join a whole remote network, such as an AWS VPC, over IPsec.

API reference

Everything here is on the API, including the VPN.