Google Cloud Run

Before you start: basic familiarity with containers (what a Dockerfile and a container image are) is assumed. No Kubernetes experience is required or even relevant here — Cloud Run's whole pitch, covered below, is running containers without a cluster to manage.

What Is Cloud Run?

Cloud Run is Google Cloud's fully managed serverless container platform. You package your application in a container, deploy it to Cloud Run, and it automatically scales from zero to thousands of instances based on incoming requests — you pay only for what you use.

Why this exists (the hook)

Say you've built a small REST API. You containerized it with a Dockerfile because that's the standard way to package an app today, but you don't want to run Kubernetes just to serve maybe a handful of requests a day — that's a control plane, node pools, and YAML for something that could be one command. Cloud Run's pitch: give it your container image, and it runs it as an HTTP service, scales the number of running instances up when requests arrive and down to zero when they stop, and bills you only for the CPU/memory time actually spent handling requests. No idle server bill, no cluster to patch.

Analogy

Think of Cloud Run like an on-demand car rental kiosk versus owning a car. Owning a car (a VM or a GKE node pool) means you pay for it whether it's parked in your driveway or on the highway — insurance, depreciation, parking, all the time. Cloud Run is the kiosk: a car (a container instance) is handed to you the moment you need one, you're billed only for the minutes you're actually driving, and when you're done it goes back into the shared pool — if nobody needs a car for a while, the kiosk simply keeps zero cars staffed and ready, costing nothing until the next request pulls up.

How a request flows through Cloud Run (diagram)

Annotated example: deploy and understand what happened

# Build-and-deploy in one step: Cloud Build packages your source into a
# container image for you, then Cloud Run deploys it.
gcloud run deploy my-service \
  --source . \
  --region us-central1 \
  --allow-unauthenticated
# --allow-unauthenticated makes the URL public. Omit it and the service
# still deploys, but every caller needs a valid IAM-based identity token --
# the safer default for internal services.

# Read back the auto-generated public URL
gcloud run services describe my-service \
  --region us-central1 \
  --format "value(status.url)"

What actually happened: Cloud Build turned your source into a container image and pushed it to Artifact Registry, Cloud Run created a revision (an immutable snapshot of that image plus its config — env vars, memory, CPU), and traffic was routed 100% to that new revision. Every subsequent gcloud run deploy creates a new revision rather than mutating the old one — which is exactly what makes instant rollback possible: an old revision never disappears, it's just not receiving traffic until you point traffic back at it.

Try it yourself (2 minutes)

If you have a GCP project with billing enabled (Cloud Run has an always-free monthly tier), deploy Google's public "hello" sample container with zero build step required:

gcloud run deploy hello-world \
  --image us-docker.pkg.dev/cloudrun/container/hello \
  --region us-central1 \
  --allow-unauthenticated

Open the URL it prints. Then wait roughly 15 minutes without hitting it again, and check gcloud run services describe hello-world --region us-central1 for instance count — you'll see it's scaled back to zero. Hit the URL once more and time how long the response takes versus a second immediate request; the difference you feel is the cold start. (the exact idle-to-zero timing and cold-start latency are not fixed guarantees and can vary by traffic pattern and image size — treat the exercise as building intuition, not a benchmark.)

Key Features

Cloud Run vs Cloud Functions vs GKE

|---------|-----------|----------------|-----|

Common Use Cases

Who This Is For

Backend engineers deploying APIs, DevOps teams managing containerised services on GCP, and anyone wanting container flexibility without taking on Kubernetes operational overhead.