What Is Google Cloud Run? Serverless Containers on GCP
Google Cloud Run runs a container image as a scalable service or job, handling scaling (including to zero) and infrastructure so you just supply an image.
Cloud Run hits a sweet spot between Lambda-style functions and full Kubernetes: you give it a container, and it runs it as an autoscaling HTTP service or a batch job. You do not manage servers or clusters, and it scales to zero when idle so you pay nothing between requests.
How Cloud Run works
You deploy a container image that listens on a port. Cloud Run routes HTTP (or gRPC) requests to instances, spinning them up as traffic arrives and down to zero when idle. Each revision is immutable, and you can split traffic across revisions.
Services vs jobs
- Services handle incoming requests and autoscale with traffic.
- Jobs run a container to completion for batch or scheduled work.
- Both run the same container image format.
Scaling and cold starts
Cloud Run scales horizontally based on concurrency and request load. Scaling to zero saves money but introduces a cold start on the next request; you can set a minimum number of warm instances to avoid that for latency-sensitive services.
Why teams like it
It runs any container, so there is no proprietary runtime to target. It is cheaper than always-on servers for bursty traffic, simpler than GKE, and more flexible than function-only platforms because you control the whole image.
Role in CI/CD
A pipeline builds the image, pushes it to Artifact Registry, and runs gcloud run deploy to ship a new revision. With Workload Identity Federation, GitHub Actions authenticates without a key file. Traffic can shift gradually between revisions for canary releases.
Key takeaways
- Cloud Run runs any container as an autoscaling service or batch job.
- It scales to zero to save cost, with optional warm instances to avoid cold starts.
- Pipelines push an image to Artifact Registry and deploy a new revision.