# VPC & Project Bootstrap

> zop.dev bootstraps a GCP project in one step: VPC network, subnetwork, firewall, Cloud NAT router, and private services access for Cloud SQL and Memorystore peering, plus enablement of 11 APIs and 7 project IAM role grants. The vpc_config input is a map of private_subnets_cidr.

Source: https://zop.dev/integrations/provision/gcp/vpc-project-bootstrap
Updated: 2026-08-19

---

On Google Cloud, a project needs its network, APIs, and IAM groundwork before anything else can run. zop.dev bootstraps all three in one step: the VPC, the service APIs your stack depends on, and the project-level roles.

## Network, NAT, and private services access

VPC network, subnetwork, firewall, Cloud NAT router, and private services access (global address plus service networking connection) for Cloud SQL and Memorystore peering. Enables 11 APIs (cloudresourcemanager, compute, container, cloud_sql, secretmanager, redis, sqladmin, dns, servicenetworking, certificatemanager, serviceusage) and grants 7 project IAM roles.

## vpc_config carries the private subnet CIDRs

```text
vpc_config as a map of { private_subnets_cidr }.
```

## How Cloud SQL and Memorystore peer privately

Private services access is what lets Cloud SQL and Memorystore peer privately with the VPC.

## Private services access is the subtle one

Most of the bootstrap list is legible at a glance: network, subnet, firewall, NAT. The item
that repays attention is private services access: a reserved global address range plus a
service networking connection, which is the plumbing that lets Cloud SQL and Memorystore
attach to the VPC over private peering. Without it, managed databases face a choice between
public IPs and connection proxies; with it, they get private addresses inside the VPC's
reach. Nearly every later "database is unreachable" mystery on GCP traces back to this
peering, which is exactly why it is created here rather than left as an exercise.

## The reserved range is hard to change later

That peering range is carved out of the address plan and effectively permanent. Resizing or
moving it after databases populate it is a disruptive, connection-breaking operation.
Together with `private_subnets_cidr`, this is the bootstrap's one truly long-lived decision:
subnets can grow, firewall rules can churn, but the address plan set here is the one future
peerings and future databases must live inside. Allocate generously and from an
organization-wide scheme, for the same reason as every other network in this directory.
Overlap discovered later has no cheap fix.

## What starts billing at creation

The bootstrap is almost free-standing: VPC, subnets, firewall rules, API enablement, and IAM
grants all cost nothing to exist. The exception is the Cloud NAT router, which starts its
hourly meter immediately and adds per-GB processing as private workloads generate egress. A
bootstrapped-but-idle project therefore carries a small, steady NAT charge (the honest
price of being ready), while the 11 enabled APIs and 7 project role grants set the
capability and authority ceilings everything later operates under.