Cloud Run Deployment

Deploy a Python service to Cloud Run through an immutable image digest, private invocation, keyless CI, and a dedicated runtime identity. containerize owns the image; gcloud owns account, project, and region context.

Workflow

1. Resolve target and authority: verify the gcloud account, project, region, service, and Artifact Registry image repository; registry pushes, signing, IAM changes, deployment, and traffic changes each need authority for the named target.
2. Configure identities once: read bootstrap.md for APIs, registry, runtime service account, deployer service account, and Workload Identity Federation. Keep deployer and runtime identities distinct.
3. Validate locally: pin, lock, and install Trivy and Cosign before any image scan or registry push, then build the pinned non-root Python image and run its tests and check:image scan; follow deployment.md steps 1-2 and containerize.
4. Publish and prove provenance: after push authority is explicit, follow deployment.md: take one digest (the build action's output in CI, BuildKit metadata locally) and run the cosign release sequence on it before deployment.
5. Deploy privately: pass the digest reference and dedicated --service-account; keep --invoker-iam-check --no-allow-unauthenticated and verify both access controls after deployment. Use service.yaml when settings warrant a declarative service specification; a successful update does not prove private IAM.
6. Use infrastructure as code when needed: manage repeatable services, IAM, registries, and fleet-level infrastructure per infra-as-code; review the plan before apply.
7. Wire CD when requested: adopt deploy.yml and verify-private.py per the "Wire CD" and "Roll out through a candidate" steps of deployment.md.
8. Verify the live result: record the ready revision, deployed digest, pinned secret versions, runtime account, IAM policy, health result, and traffic split. Keep a known-good revision for rollback.

Gotchas

• Use one digest throughout: build, scan, signature, attestation, deployment, verification, and rollback must refer to the same @sha256: image.
• Private by default: grant roles/run.invoker only to intended callers or use an authenticating load balancer. For signed-in users without a load balancer, gcloud run deploy --iap enables IAP on the service.
• Promote an exact revision, never LATEST: CD deploys a no-traffic tagged candidate, verifies it on the tag URL, then routes 100% to that revision name and drops the tag, so a later revision never inherits traffic unverified.
• Size connection pools against the database limit: keep max_instances × (pool_size + max_overflow) below the database's max_connections minus admin headroom (SQLAlchemy defaults to 5 + 10 per process), and add a connection pooler instead of raising pool sizes when autoscaling exhausts it.
• Scale deliberately: keep minimum instances at zero unless measured first-request latency justifies idle cost. For a hard monthly cost ceiling, propose a Cloud Billing spend cap: once estimated costs exceed the budget, it pauses the project's Cloud Run usage, taking the service offline until the cap is lifted or the month ends; enforcement lags, and setting it needs billing authority.
• Align service and registry regions: keep the service and Artifact Registry repository in one region and project. Workload Identity Federation pools remain global.

Official Skills

Upstream: google/skills (skills/cloud), listed and installed through Google catalog. Select the Cloud Run skills the task needs; gcloud covers its CLI guardrail skill.

Documentation

• Cloud Run · Artifact Registry · Workload Identity Federation
• Releases: Cloud Run · Artifact Registry
• Companion skills: containerize, github-actions, gcloud, infra-as-code, and code-security.