--- title: "Private Networks (VPC)" description: "Give your applications, databases and services a private network of their own." --- 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](/networking/private-networks/vpn). ## 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](/networking/private-networking). 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 Every workspace can hold several VPCs, one default per region. The region has to match the resources whose workloads will attach. Leave the range at the default unless you have a reason not to. 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**. 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 Carve the range up, and connect applications, services and add-ons to it. Reach the VPC from a laptop, a tailnet or Cloudflare Zero Trust. Join a whole remote network, such as an AWS VPC, over IPsec. Everything here is on the API, including the VPN.