Google Cloud Run - Throw a Container at Google, Get Back a URL

After spending three years fighting with Kubernetes deployments that randomly failed and YAML files that made me question my life choices, Cloud Run felt like discovering fire. You literally just point it at a container and get back a working HTTPS URL. No ingress controllers, no service meshes, no debugging why your pod is stuck in CrashLoopBackOff for the 500th time.

The Container Runtime Contract (AKA The Only Rules That Matter)

Cloud Run has exactly two requirements: listen on the PORT environment variable and don't crash. That's it. Your container gets an HTTP request, it responds, everyone's happy. Compare that to Kubernetes where you need to understand 12 different resource types just to run a simple web app.

I've deployed Node.js apps, Python Flask services, Go APIs, even weird Java apps that take 30 seconds to start (don't ask). As long as your container speaks HTTP and doesn't eat shit on startup, Cloud Run will run it.

The buildpack detection works most of the time, but keep a Dockerfile handy - sometimes it picks the wrong Node.js version and you'll spend 2 hours debugging why your app won't start. Learned that one the hard way.

Three Deployment Options (Pick Your Poison)

Services are for HTTP stuff - web apps, APIs, microservices. They scale from zero to however many you need, handle load balancing, and give you monitoring that actually works. I've got services running that get 10 requests a month and others that handle thousands per minute. Same config, different scale.

Jobs run once and die, perfect for batch processing or data migrations. Way better than running cron jobs on random servers that disappear when someone forgets to pay the hosting bill.

Worker Pools are new but handle background work that doesn't come from HTTP requests. Think Kafka consumers or queue processors that need to stay alive.

Cloud Run Functions got a major overhaul in 2024 - it's now built on top of Cloud Run under the hood. Same performance, same scaling, but with the simpler function-as-a-service model for simple use cases.

The Good Parts (There Are Many)

Cold starts aren't terrible: Usually under a second for Node.js apps, 2-3 seconds for Java (which honestly isn't bad for the JVM). Enable minimum instances if cold starts are killing your user experience - costs more but keeps instances warm. As of September 2025, Google's improved their cold start performance significantly with better image caching.

VPC integration actually works: Unlike some serverless platforms where network access is an afterthought, Serverless VPC Access lets you talk to private databases and internal services without exposing them to the internet. Setup is annoying but it works once configured.

Traffic splitting for deployments: You can split traffic between revisions, which is clutch for testing new deployments. Send 10% of traffic to the new version, watch the error rates, rollback if things explode.

Monitoring that doesn't suck: Google Cloud Monitoring gives you request latency, error rates, and resource usage out of the box. The dashboards are actually readable, unlike some monitoring tools that require a PhD to interpret.

The Gotchas (Because There Always Are Some)

The free tier runs out faster than expected when you deploy memory-hungry Python apps or anything with heavy startup costs. Google's pricing calculator is optimistic - add 30% to whatever it tells you. The 2025 pricing structure still includes 2 million requests and 360,000 GB-seconds of memory free per month, but egress charges can bite you if you're serving large files.

Request timeout is 60 minutes max - sounds great until you try to run a data migration that takes 3 hours. Use Jobs for long-running tasks, not Services.

Container images get big fast and Artifact Registry storage costs add up. Use multi-stage Docker builds and clean up old images regularly.

IAM permissions are confusing as hell - use the GUI until you figure out the CLI. The Cloud IAM documentation is comprehensive but good luck finding what you actually need.

Deploying to Cloud Run is supposed to be simple - and mostly it is. But I've spent enough nights debugging failed deployments to know where the bodies are buried. Here's what you'll actually encounter, not the marketing fluff.

The "Just Push Code" Fantasy vs Reality

Source-based deployment sounds magical: just git push and Google builds your container automatically using Cloud Buildpacks. It works great until it doesn't. I've had it fail because:

• The automatic detection picked Node.js 14 when I needed 18
• Python buildpack couldn't find my requirements.txt (it was in a subdirectory)
• The build ran out of memory trying to install massive dependencies
• Some obscure npm package needed native compilation that the buildpack couldn't handle

Keep a Dockerfile ready as backup. When buildpacks fail, you can switch to container deployment in 5 minutes instead of 5 hours.

Container Deployment: More Control, More Ways to Fuck Up

Pre-built containers give you complete control, which means complete responsibility when things break. Common disasters I've seen:

The PORT environment variable: Your app MUST listen on process.env.PORT or $PORT. Not 3000, not 8080, but whatever Cloud Run tells you. This kills more deployments than any other single issue.

## This will fail in Cloud Run
app.listen(3000)

## This works
const port = process.env.PORT || 3000
app.listen(port)

Container startup time: If your container takes more than 10 minutes to start, the deployment fails. I learned this the hard way with a Java app that spent 8 minutes downloading Maven dependencies. Multi-stage builds are your friend.

Resource limits: The default 1GB memory limit seems generous until your Node.js app tries to process a 500MB CSV file. Bump the memory allocation or your app will get OOMKilled faster than you can say "heap overflow". I once had a Python data processing service that worked fine for months, then suddenly started failing when someone uploaded a 800MB JSON file. Took down production for 45 minutes while I figured out it was hitting the memory ceiling.

The Database Connection Nightmare

Connecting to Cloud SQL from Cloud Run should be simple. It's not. You have two options:

1. Public IP: Easy to set up, bad for security, gets you yelled at by InfoSec
2. Private IP with VPC: Secure, complicated setup, adds 2-3 seconds to cold starts

I spent a full day fighting the VPC setup because the Serverless VPC Access connector was in the wrong region. The error messages are cryptic as hell - "network unreachable" could mean anything from wrong region to bad IAM permissions. Worst part? The actual error was ERROR: (gcloud.run.deploy) PERMISSION_DENIED: The caller does not have permission but the real issue was the connector being in us-east1 while my service was in us-central1. Eight fucking hours of debugging for a region mismatch that should have been caught by better error messages.

Secrets and Environment Variables (Where Production Goes to Die)

Secret Manager is great once you get it working. Getting it working is the hard part:

• Service account needs the right IAM permissions (good luck figuring out which ones)
• Secret names can't contain underscores (learned after 30 minutes of debugging)
• Environment variables override secrets, which bit me during a production deployment

Pro tip: Test secret access in a simple container first, then add your actual application.

Continuous Deployment: When Automation Attacks

GitHub Actions with Cloud Run works great until your workflow randomly fails with "authentication failed". Usually it's because:

1. The service account key expired (Google rotates them)
2. Someone changed IAM permissions without telling you
3. The action tried to deploy to the wrong region (check your workflow YAML)

I've got a webhook that pings Slack when deployments fail because silent failures are the worst kind of failures.

Docker Multi-Stage Build Example

Here's a real multi-stage build that actually works in production:

## Build stage
FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

## Production stage  
FROM node:18-alpine AS production
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY . .
EXPOSE 8080
ENV PORT=8080
CMD ["npm", "start"]

The Real Deployment Checklist

When your deployment fails (not if, when), check these in order:

1. Container listens on $PORT - kills 50% of deployments
2. Startup time under 10 minutes - Java apps, I'm looking at you
3. Service account has correct permissions - IAM is a maze
4. Secrets are accessible - test with a simple container first
5. VPC configuration if using private resources - region mismatches are common
6. Memory/CPU limits match your workload - don't guess, measure

The Cloud Run logs are actually helpful, unlike some platforms. When something fails, the logs usually tell you exactly what went wrong. Read them before asking Stack Overflow.