What Is Cloud Run?
Cloud Run is a fully managed serverless platform for running stateless containers, built on the open-source Knative API. You give it a container image that listens on a port, and Cloud Run handles provisioning, scaling (including scaling to zero when idle), load balancing, and TLS termination automatically, without you ever touching a VM or a Kubernetes cluster. Because it accepts any container image, Cloud Run occupies a unique middle ground: you get the packaging flexibility of Docker with the operational simplicity of a fully managed PaaS.
Cricket analogy: Cloud Run is like a stadium that only charges you rent for the exact minutes your match is being played and instantly provides more seating capacity when a crowd surges, rather than paying for the whole venue year-round like owning a stadium outright.
Services and Revisions
A Cloud Run Service is the top-level resource representing your deployed application, and each deployment creates an immutable Revision — a specific container image plus configuration (env vars, CPU/memory limits, concurrency setting) at a point in time. Traffic is assigned to revisions by percentage, so you can send 100% to the latest revision, or split traffic (e.g., 90/10) between an old and new revision for a canary rollout, and instantly roll back by shifting 100% of traffic back to a previous revision without redeploying anything.
Cricket analogy: A revision is like a specific playing XI announced for one match — you can send the whole squad's confidence (100% traffic) to the new lineup, or field a hybrid combination for one dead-rubber game (canary split) before committing fully for the final.
Concurrency, Scaling, and Cold Starts
Each Cloud Run container instance can handle multiple concurrent requests (up to a configurable concurrency limit, default 80, max 1000), and Cloud Run automatically adds more container instances as demand exceeds what current instances can handle, scaling down to zero instances (and zero cost) when there's no traffic. The trade-off for scaling to zero is the cold start: the first request after idle time must wait for a new container instance to start, which can add noticeable latency for heavyweight runtimes; setting a minimum instance count keeps a baseline of warm instances ready to eliminate cold starts for latency-sensitive services, at the cost of paying for that idle capacity.
Cricket analogy: This is like a stadium's food stalls that can serve many fans at once up to a queue limit, adding more stalls as the crowd grows, and shutting down entirely between matches — but the first fan after a long gap has to wait for a stall to reopen and reheat, unless the stadium keeps one stall warm year-round.
# Deploy a container image to Cloud Run with concurrency and min-instances configured
gcloud run deploy hello-api \
--image=gcr.io/my-project/hello-api:2.3.1 \
--region=us-central1 \
--platform=managed \
--concurrency=80 \
--min-instances=1 \
--max-instances=20 \
--memory=512Mi \
--allow-unauthenticated
# Split traffic 90/10 between the latest revision and a previous one for a canary rollout
gcloud run services update-traffic hello-api \
--region=us-central1 \
--to-revisions=hello-api-00042-xyz=10,hello-api-00041-abc=90Cloud Run charges only for the CPU and memory consumed while a container instance is actively handling requests (plus a small always-on allocation if you configure CPU-always-allocated), meaning a service that scales to zero and receives no traffic for a day costs nothing in compute for that day.
Cloud Run containers are stateless and ephemeral — anything written to the local filesystem is lost when the instance is stopped or replaced, and you cannot rely on in-memory state being shared across concurrent requests hitting different instances. Persistent data must go to an external store like Cloud SQL, Firestore, or Cloud Storage.
- Cloud Run runs any container image as a fully managed, autoscaling, pay-per-use service without managing servers or clusters.
- Each deployment creates an immutable Revision; traffic can be split by percentage across revisions for canary rollouts and instant rollback.
- Concurrency settings control how many requests one container instance handles simultaneously, up to a configurable limit.
- Cloud Run scales to zero when idle, eliminating cost but introducing cold-start latency for the first request.
- Minimum instance counts keep warm instances ready to avoid cold starts, at the cost of paying for idle capacity.
- Cloud Run containers are stateless — local filesystem writes and in-memory state don't persist or share across instances.
- Billing is based on actual CPU/memory consumption during request handling, not on provisioned capacity.
Practice what you learned
1. What happens to a Cloud Run service's cost when it receives zero traffic for an extended period?
2. What is a Cloud Run Revision?
3. What is the primary trade-off of setting a minimum instance count above zero?
4. Why can't Cloud Run containers rely on writing important data to the local filesystem?
5. How does traffic splitting between revisions enable a canary rollout?
Was this page helpful?
You May Also Like
Cloud Functions Basics
Understand Cloud Functions, GCP's event-driven Functions-as-a-Service platform for running small pieces of code in response to triggers.
Google Kubernetes Engine Basics
Learn the fundamentals of GKE, Google's managed Kubernetes service, including clusters, nodes, workloads, and Autopilot mode.
Compute Engine Basics
Learn how Google Compute Engine provisions virtual machines, machine types, disks, and networking so you can run workloads on GCP infrastructure.