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 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 three 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 and subnet 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 fifteen secret-free stages, including the project and exact resource name:
gcp setup [neon-law-stg] 01/15 enable required APIs
gcp setup [neon-law-stg] 04/15 private assets bucket neon-law-stg-assets
gcp setup [neon-law-stg] 08/15 private applications bucket neon-law-stg-applications
gcp setup [neon-law-stg] 11/15 runtime identities and IAM bindings (neon-law-stg-web)
gcp setup [neon-law-stg] 12/15 container registry access
gcp setup [neon-law-stg] 13/15 GKE Autopilot cluster neon-law-stg
gcp setup [neon-law-stg] 14/15 Kubernetes workload identity and cluster integrations
gcp setup [neon-law-stg] 15/15 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-prod; retrying VPC neon-law-prod-vpc (1/25)
gcp operation [Compute] operation-123: compute.googleapis.com activation is still propagating; retrying poll