Cloud Run Configuration
Service Deployment
Each service is deployed as an independent Cloud Run service.
Deployment Process
- Build container image via Cloud Build
- Push to Artifact Registry
- Deploy new revision to Cloud Run
- Verify health endpoint responds
- Shift traffic to new revision
Revision Management
Cloud Run maintains multiple revisions. After deploying a new revision, traffic must be shifted explicitly. Progressive rollouts are supported by splitting traffic between revisions (e.g., 10% new / 90% old).
Container Configuration
| Parameter | Value |
|---|---|
| Max instances | Per-service configuration |
| Min instances | 0 (scale to zero when idle) |
| Request timeout | 300 seconds (default) |
| Concurrency | Per-service configuration |
| CPU allocation | Always allocated during request processing |
| Memory | Per-service configuration |
Security
- All services run as non-root users inside containers
- Secrets are injected from GCP Secret Manager as environment variables
- Service-to-service authentication via HMAC
- Containers do not store secrets in the image layer
Frontend Services
Admin UI and Marketing Site are served via Nginx on Cloud Run:
- Static files compiled at build time (Vite)
- Nginx configured for SPA routing (all paths fallback to
index.html) - Health endpoint served directly by Nginx
- Runtime environment variables are injected at container startup
The Admin UI Nginx configuration reverse-proxies API and GraphQL requests to the backend API Gateway.
Admin Jobs
The Admin Jobs service runs as a Cloud Run Job (not a service). It executes administrative operations and is triggered via Cloud Build or manual invocation.
Implemented across per-service Dockerfiles at commit 4b572c2.