gcloud has no universal dry-run equivalent, so we built one — it prints the plan without sending traffic or touching
your gcloud session. You will see the plan in order: REST calls that enable APIs, create the VPC and subnet, create a
regional Cloud Router and Cloud NAT, and create five buckets. It then creates a deployment-specific Google service
account and its direct Secret Manager, bucket, and signed-URL permissions. A single-project install also provisions its
private Artifact Registry; our three deployments instead point at the shared ghcr hub. The last stages grant registry
access, reserve the gateway IP and create the cluster, then attach Kubernetes Workload Identity and the cluster
integrations. Read the project, region, and every resource prefix, then drop --dry-run to execute. Every step is
idempotent, so a re-run after a partial failure never produces duplicates.
The CLI waits for each control-plane write at that API's own operation endpoint before starting its dependent step.
Compute VPC operations are global; subnet, Router, and NAT operations are regional. Their REST resources report
completion with a DONE status. Service Usage and Artifact Registry use Google long-running operations and report a
true done flag. A newly enabled Compute API can still return SERVICE_DISABLED for a short propagation window after
its Service Usage operation completes. The VPC step recognizes only that exact compute.googleapis.com response, prints
the bounded retry count, and retries the idempotent insert for up to two minutes. Other 403 responses fail immediately
because they may be real IAM or organization-policy problems. If a terminal or network interruption stops setup after
GCP accepted a write, run the exact same deployment command again. Existing resources return idempotent conflicts. The
pipeline generates no credential of its own, so a run — first or tenth — prints no secret for you to record. The store
is SurrealDB, and its endpoint and root credentials come from your store provider.
Live setup prints sixteen secret-free stages, including the project and exact resource name:
gcp setup [neon-law-stg] 01/16 enable required APIs
gcp setup [neon-law-stg] 04/16 Cloud Router neon-law-stg-router and NAT neon-law-stg-nat
gcp setup [neon-law-stg] 05/16 private assets bucket neon-law-stg-assets
gcp setup [neon-law-stg] 09/16 private applications bucket neon-law-stg-applications
gcp setup [neon-law-stg] 12/16 runtime identities and IAM bindings (neon-law-stg-web)
gcp setup [neon-law-stg] 13/16 container registry access
gcp setup [neon-law-stg] 14/16 GKE Autopilot cluster neon-law-stg
gcp setup [neon-law-stg] 15/16 Kubernetes workload identity and cluster integrations
gcp setup [neon-law-stg] 16/16 projects/neon-law-stg/locations/us-west4/keyRings/navigator-secrets/cryptoKeys/deployment-config
gcp setup [neon-law-stg] COMPLETE
Long-running REST writes print the service, operation ID, scoped polling path, and DONE. Output never includes the
store URL, access token, service-account key, or any other secret value, and the pipeline generates no credential that
would need printing.
On a newly activated project, one of these additional lines can appear between stages 1 and 2, depending on whether the
activation window meets the VPC insert or its operation poll:
gcp api [compute.googleapis.com] activation is still propagating for neon-law-stg; retrying VPC neon-law-stg-vpc (1/25)
gcp operation [Compute] operation-123: compute.googleapis.com activation is still propagating; retrying poll