Deploy to GCP¶

Choose this target when you want a managed cloud deployment on Google Cloud instead of a self-managed single host.

This page is the high-level entry point for GCP deployments. For the deeper Cloud Run runbook, see Google Cloud Deployment.

When to choose this target¶

Choose GCP if you want:

managed application hosting on Cloud Run
managed PostgreSQL with Cloud SQL
Secret Manager, Artifact Registry, and Cloud Scheduler integration
a cleaner fit for teams already standardised on Google Cloud

Choose Deploy with Docker Compose instead if you want the simplest self-hosted production path on infrastructure you control directly.

What this target runs¶

The GCP deployment uses:

Cloud Run for the web service
Cloud Run for the worker service
Cloud SQL for PostgreSQL
Cloud Storage for file storage
Secret Manager for runtime configuration
Artifact Registry for container images
Cloud Scheduler for recurring jobs

Advanced validators are deployed separately from the main web and worker services.

Environment model¶

The GCP setup is designed around three stages:

Stage	Purpose	Typical use
`dev`	development testing	deploy new changes first
`staging`	pre-production verification	optional but useful for larger changes
`prod`	production	customer-facing environment

Each stage gets its own Cloud Run services, Cloud SQL instance, secrets, and queueing resources.

Signed credentials on GCP¶

GCP deployments should use Google Cloud KMS rather than a local PEM file. Set the credential-signing key in your stage .django env file:

GCP_KMS_SIGNING_KEY=projects/your-project/locations/your-region/keyRings/your-app-name-keys/cryptoKeys/credential-signing
CREDENTIAL_ISSUER_URL=https://validibot.example.com

The Cloud Run service account also needs permission to sign with that key. At minimum, grant the runtime service account:

roles/cloudkms.viewer
roles/cloudkms.signerVerifier

Use a different KMS key per stage so dev, staging, and prod credentials do not share the same issuer key material.

Typical first-time flow¶

Most first-time GCP setups follow this order:

source .envs/.production/.google-cloud/.just

just gcp init-stage dev
just gcp secrets dev
just gcp deploy-all dev
just gcp migrate dev
just gcp setup-data dev
just gcp validators-deploy-all dev
just gcp scheduler-setup dev

After that, verify the environment, then repeat the same process for staging or prod as needed.

Routine deployment flow¶

For normal updates:

source .envs/.production/.google-cloud/.just

just gcp deploy-all dev
just gcp migrate dev

Promote to production only after the lower stage looks healthy.

Domain and networking¶

There are two normal ways to expose a GCP deployment publicly:

Cloud Run domain mappings for the simpler path in supported regions
a global HTTP(S) load balancer for the more production-oriented path

If you need a custom domain, SSL, or a single public entrypoint, see the domain section in Google Cloud Deployment.

Good fits for this target¶

GCP is a good fit when:

you already use Google Cloud
you want managed infrastructure rather than running a VM yourself
you need a cleaner path to multi-environment deployments