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 six buckets. It then creates a deployment-specific Google service
account and its direct Secret Manager, bucket, and signed-URL permissions. A single-project install can also provision
its private Artifact Registry; an installation with a shared registry supplies that registry's project in its operator
configuration. 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 nineteen secret-free stages, including the project and exact resource name:
gcp setup [ROW] 01/19 enable required APIs
gcp setup [ROW] 04/19 Cloud Router and NAT setup
gcp setup [ROW] 05/19 create private assets bucket
gcp setup [ROW] 09/19 create private applications bucket
gcp setup [ROW] 12/19 configure runtime identities and IAM bindings
gcp setup [ROW] 13/19 configure container registry access
gcp setup [ROW] 14/19 create GKE Autopilot cluster
gcp setup [ROW] 15/19 configure workload identity and cluster integrations
gcp setup [example-project] 16/19 KMS key provisioned from the selected row
gcp setup [ROW] 17/19 log retention on the logs bucket and Cloud Logging _Default
gcp setup [ROW] 18/19 release ship identity (not configured; skipped)
gcp setup [ROW] 19/19 navigator-postgres-backup-target ConfigMap in navigator
gcp setup [ROW] COMPLETE
Stage 18 runs only when --ship-deployment, --ship-repository, and --ship-environment name the row, repository, and
GitHub Environment the release workflow ships from; see docs/release-automation.md.
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; retrying network setup (1/25)
gcp operation [Compute] operation-123: compute.googleapis.com activation is still propagating; retrying poll