Google Cloud Run is a fully managed serverless platform for running containers on Google Cloud. A developer supplies a container image that listens for HTTP requests or runs a task, and Cloud Run handles provisioning, automatic scaling, load balancing, TLS and billing per use, including scaling to zero when there is no traffic.
In the serverless landscape of cloud computing, Cloud Run sits between function as a service offerings such as AWS Lambda and container orchestration platforms such as Kubernetes. It keeps the operational simplicity of functions while accepting any language, library or binary that can be packaged in a standard OCI container image. Its service model is based on the open-source Knative serving API, which makes workloads comparatively portable.
How Cloud Run executes containers
Cloud Run runs each deployment as a revision, an immutable snapshot of a container image plus its configuration. Incoming requests reach a Google-managed front end, which routes them to container instances of the active revision and starts new instances when the existing ones are busy.
Unlike most function platforms, a single Cloud Run instance can serve many concurrent requests. The default concurrency is 80 requests per instance and can be set from 1 to 1,000. Higher concurrency means fewer instances and fewer cold starts, while a value of 1 isolates every request, which suits CPU-heavy or non-thread-safe code.
Containers must be stateless: the local file system is an in-memory volume that disappears with the instance, and any instance may be stopped when traffic falls. Persistent data belongs in services such as Cloud SQL, Firestore or Cloud Storage.
Services, jobs and functions on Cloud Run
Cloud Run offers several resource types that share the same container runtime but differ in how work is triggered and when it ends.
| Resource type | Triggered by | Typical use |
|---|---|---|
| Services | HTTP requests, gRPC, WebSockets, events | APIs, websites, webhooks |
| Jobs | Manual run, schedule or workflow | Batch processing, migrations, reports |
| Functions | HTTP or event triggers, source code deploy | Small handlers without writing a Dockerfile |
| Worker pools | Pull-based background work | Queue consumers that need no HTTP endpoint |
A job runs one or more tasks to completion and then stops, with configurable parallelism and retries per task. This makes Cloud Run suitable not only for request-driven traffic but also for scheduled batch work that would otherwise need a dedicated virtual machine.
Events from other Google Cloud services, such as file uploads or Pub/Sub messages, are delivered to services through Eventarc or push subscriptions as ordinary HTTP requests, so the same container can handle both user traffic and event processing.
Key configuration parameters
A Cloud Run service is tuned through a small set of parameters that control cost, latency and capacity. The ranges below reflect the platform limits as commonly configured; exact maximums can change between platform releases.
| Parameter | Typical range | What it controls |
|---|---|---|
| Concurrency | 1-1,000, default 80 | Requests handled per instance |
| Minimum instances | 0 or more | Warm capacity that avoids cold starts |
| Maximum instances | Default 100, adjustable | Upper scaling limit and cost ceiling |
| CPU and memory | Up to 8 vCPU and 32 GiB per instance | Compute available per instance |
| Request timeout | Default 5 minutes, up to 60 minutes | Longest allowed request |
| CPU allocation | During requests only, or always | Billing model and background work |
The CPU allocation mode has major consequences. With request-based billing, CPU is throttled outside request processing, so background threads stall after the response is sent. With instance-based billing, CPU is always available and the instance is billed for its whole lifetime, which suits background work and steady traffic.
Cloud Run compared with other serverless options
Cloud Run is most often compared with function platforms and with other serverless container services. The table summarizes the practical differences that drive the choice.
| Platform | Unit of deployment | Concurrency model |
|---|---|---|
| Google Cloud Run | Container image | Many requests per instance |
| AWS Lambda | Function code or container image | One request per execution environment |
| AWS Fargate | Container task in ECS or EKS | Long-running tasks, no scale to zero by default |
| Azure Container Apps | Container image | Many requests, scale to zero available |
| Cloudflare Workers | JavaScript or WebAssembly isolate | Edge execution in lightweight isolates |
The decisive advantages of Cloud Run are portability of the container and request concurrency, which can lower cost for I/O-bound services. Its main trade-off against functions is that the team owns the container image, including the base image, dependencies and security patching.
Cold starts, cost and common pitfalls
When a service scales from zero or adds instances, users may experience a cold start, the time needed to start the container and initialize the application. For small images in Go or Node.js this is often well under a second, while large JVM or Python applications with heavy initialization can take several seconds.
- Set minimum instances for latency-sensitive services, accepting the cost of idle warm capacity.
- Enable startup CPU boost and keep images small to shorten initialization.
- Cap maximum instances to protect databases from connection storms during traffic spikes.
- Avoid background work after the response when CPU is allocated only during requests.
- Use connection pooling carefully, because many instances multiply open database connections.
Billing is based on vCPU-seconds, GiB-seconds and requests, with a free tier. Services with constant high traffic can cost more than equivalent reserved virtual machines, so Cloud Run is usually most economical for variable or bursty workloads.
A plain-language summary
Imagine renting a kitchen only while you are cooking. You bring your own recipe and ingredients packed in a box, the landlord provides as many stoves as there are guests, and you pay only for the minutes the stoves are on. Google Cloud Run works like that for software.
Developers pack their program into a container, and Cloud Run starts copies of it when people use it and shuts them down when nobody does. There are no servers to install or maintain. The main catch is that a stopped program needs a moment to start again.
An example from practice
A small software company offers an image-resizing API to online stores. Traffic is quiet at night and jumps whenever a client uploads a new product catalog. The team packages the Python service as a container and deploys it to Cloud Run with concurrency set to 10, because resizing is CPU-heavy, 2 vCPUs and 2 GiB of memory per instance.
During a catalog import, the service scales from one warm instance to about 60 instances within a minute and processes tens of thousands of images, then shrinks back after the burst. A maximum of 100 instances prevents runaway costs, and one minimum instance keeps the first request fast.
Compared with the two virtual machines the company ran before, the monthly bill falls noticeably because idle hours cost almost nothing, and nobody needs to patch an operating system.