Deploy Production-Ready Serverless Apps on GCP

Provides patterns and hard-won gotchas for building production-ready serverless applications on GCP Cloud Run - covering containerized Cloud Run services, event-driven Cloud Run Functions, cold-start optimization, concurrency tuning, Pub/Sub integration, Cloud SQL connectivity, and Secret Manager usage. Core principles: use Cloud Run for containers and Functions for simple event handlers, optimize cold starts with startup CPU boost and minimum instances, set concurrency based on workload (start at 8 and adjust), remember /tmp counts against memory, use a VPC Connector only when needed since it adds latency, and keep containers fast-starting, stateless, and signal-aware for clean shutdown.

Use this skill when building web applications/APIs needing any runtime (Cloud Run services), simple event handlers for Pub/Sub messages, Cloud Storage triggers, or HTTP webhooks (Cloud Run Functions), or when tuning cold starts, concurrency, or database connectivity for an existing Cloud Run deployment. The skill itself defines delegation triggers for adjacent needs: hand off to aws-serverless for AWS Lambda/API Gateway/SAM, azure-functions for Azure Container Apps, postgres-wizard for Cloud SQL/AlloyDB database design, auth-specialist for Firebase Auth/Identity Platform, llm-architect for Vertex AI integration, and workflow-automation for Cloud Workflows/Eventarc.

Deployment pattern example:

gcloud run deploy my-service \
  --source . \
  --region us-central1 \
  --allow-unauthenticated \
  --memory 512Mi \
  --cpu 1 \
  --min-instances 1 \
  --max-instances 100 \
  --concurrency 80 \
  --cpu-boost

Covers Dockerfile multi-stage builds, cloudbuild.yaml CI/CD, and Cloud Run Functions for HTTP, Pub/Sub, and Cloud Storage triggers. Concurrency guidance: 1 only for CPU-bound/unsafe code, 8-20 for memory-intensive workloads, 80 as the default for I/O-bound apps, up to 250 for very lightweight handlers. Pub/Sub integration covers push subscriptions to Cloud Run endpoints, message publishing, and dead-letter queue configuration. Cloud SQL connections use Unix-socket pooling (/cloudsql/INSTANCE_CONNECTION_NAME) with a recommended pool size of 5-10 per instance. Secrets are mounted as environment variables or file volumes via Secret Manager rather than hardcoded.

Seven documented sharp edges with severity and fixes: /tmp filesystem writes count against container memory (stream instead of buffering, or use Cloud Storage directly); concurrency=1 causes scaling bottlenecks under traffic spikes (use async I/O with concurrency 80+ instead); CPU is throttled to near-zero between requests by default (use --cpu-throttling=false or move background work to Cloud Tasks/Pub/Sub); VPC Connector has a 10-minute idle timeout (use connection pooling with keep-alive and pre-ping validation); container startup must complete within 4 minutes (lazy-init heavy dependencies, start listening immediately, run migrations separately); second-generation execution environment (gVisor sandbox) changes network and filesystem behavior, including no automatic HTTPS redirect; and request timeout configuration must align across request/client/downstream/load-balancer layers (max 3600s for HTTP).

Validation checks flag hardcoded GCP credentials or API keys, committed credentials JSON files, root-user containers, hardcoded ports instead of the PORT env variable, large /tmp writes, synchronous file operations in async apps, global mutable state, and thread-unsafe singletons under concurrency > 1.

Covers the surrounding GCP toolchain directly: Cloud Build (cloudbuild.yaml), Cloud Pub/Sub, Cloud SQL (via Unix socket or the Cloud SQL Python Connector), Secret Manager, Cloud Tasks, and both gen1 and gen2 execution environments (gen2 required for GPU access via --gpu).

Backend and platform engineers deploying or hardening production workloads on Cloud Run who need concrete deployment commands, concurrency/cold-start tuning guidance, and the specific sharp edges (memory, CPU throttling, timeouts, VPC idle disconnects) that are easy to hit but hard to diagnose in production.