Cloud Parts

Google Cloud Run

Give Google a container that listens on a port; it runs as many copies as traffic needs, down to zero.

What it is
Containers,Serverless functions (FaaS)
Used for
Platform as a service (PaaS)
Type
Managed service on Google Cloud
Made by
Google Cloud
License
Proprietary
Facts checked
5 October 2026
Website

What it is

Cloud Run runs any container image that serves HTTP. Each deploy creates a revision, and Cloud Run starts instances of it as requests arrive. Unlike Lambda, one instance handles many requests at once: up to 80 per vCPU by default when deployed from the CLI, configurable up to 1,000. When traffic stops, idle instances are kept for up to 15 minutes and then the service scales to zero. Instances go up to 8 vCPU and 32 GiB, a request can run for up to 60 minutes, and GPUs are available for inference.

Besides request-driven services, Cloud Run has jobs, which run a container to completion (as many parallel tasks as you ask for, each for up to 7 days) and worker pools for always-on background consumers. You can deploy from source in Go, Node.js, Python, Java, .NET, Ruby or PHP and Cloud Run builds the image for you. Billing is either request-based (no charge while an instance isn’t handling a request) or instance-based (pay for the instance’s whole lifetime, no per-request fee).

Why teams pick it

  • Plain containers: any language or binary, and the same image runs locally or on Kubernetes
  • Scales to zero, so a quiet service costs nothing on request-based billing
  • Concurrency per instance means fewer cold starts and better use of memory than one-request-per-instance platforms
  • Services, batch jobs and background workers on one platform with the same deploy model

Watch out for

  • Cold starts after scaling to zero; set minimum instances to keep some warm, which you pay for
  • Instances top out at 8 vCPU and 32 GiB, and files written to local disk use up the instance’s memory
  • If all instances are busy, requests wait briefly and then fail with HTTP 429
  • Google Cloud only; the API and IAM model don’t carry over to other clouds

Alternatives

What all containers have in common →
AWS FargateAWSRuns ECS tasks and EKS pods without servers: you size each task, AWS finds the machine.Cloudflare ContainersCommercialLinux container images that run on Cloudflare’s network next to a Worker, each instance started on demand by its own Durable Object and put to sleep when idle.+1 Cloudflare Sandbox SDKDockerOpen sourceThe tool that made containers mainstream: build an image from a Dockerfile, then run it anywhere.gVisorOpen sourceA Linux kernel reimplemented in Go that runs in user space, so a container’s system calls never reach the host kernel directly.PodmanOpen sourceRuns Docker-style containers without a daemon, as root or as an ordinary user, and hands long-running ones to systemd.

How it fits with other technologies

Deploy a service from source, then a parallel batch job · bash

gcloud run deploy api --source . --region europe-west1 \
  --cpu 1 --memory 1Gi --concurrency 80 \
  --min-instances 0 --max-instances 20 \
  --allow-unauthenticated

gcloud run jobs create nightly-report --region europe-west1 \
  --image europe-west1-docker.pkg.dev/acme/jobs/report:2026-10 \
  --tasks 10 --task-timeout 1h
gcloud run jobs execute nightly-report --region europe-west1

See it in a real stack

No architecture uses Google Cloud Run yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2008–2026

Google had offered serverless hosting since App Engine’s preview in April 2008, but on its terms: at first only Python, code written exclusively in Python, no writing to the filesystem, and responses due within a few seconds. Containers later became the standard way to package any app, yet running them meant operating a Kubernetes cluster. Google’s launch post summed up the dilemma: developers had to choose “between the ease and velocity that comes with serverless or the flexibility and portability that comes with containers”.

Google announced Cloud Run on April 9, 2019, in a post by Eyal Manor and Oren Teich. You hand it a stateless container that serves HTTP, and it scales the container up within seconds and down to zero. Google said it was based on Knative, an open-source API for serverless workloads on Kubernetes (first commit January 2018), so the same service could also run on a GKE cluster or anyone’s Kubernetes. Google later clarified that fully managed Cloud Run doesn’t use Knative itself but stays compatible with the Knative API. Cloud Run became generally available on November 14, 2019, billed to the nearest 100 milliseconds, alongside Cloud Run for Anthos (since renamed Knative serving) for GKE clusters in Google Cloud or on premises.

Since then it has grown from a web-request runner into a general compute platform: 60-minute requests in 2021, batch jobs in 2023, GPUs in 2025 and always-on worker pools in 2026.

Why it’s built this way

Any container that listens on a port
Earlier serverless platforms limited your language, libraries and filesystem. Accepting a plain container image removed those limits and meant the same image could run on a laptop or a cluster.
Compatible with the open Knative API
Google’s pitch answered the fear of lock-in: a Knative service definition could move between fully managed Cloud Run, GKE and other Kubernetes clusters, even though the managed service doesn’t run Knative itself.
Many requests per instance
Unlike one-request-per-instance functions, a Cloud Run instance serves up to 80 requests per vCPU by default, so fewer instances (and fewer cold starts) handle the same traffic.
A gVisor sandbox first, a microVM later
gVisor intercepts system calls in user space, which starts fast but can’t emulate every Linux feature. A second-generation microVM environment, generally available in 2022, gave full Linux compatibility for apps that needed it.

Timeline

  1. 2008

    App Engine preview: Google’s first managed platform for running apps

  2. 2019

    Cloud Run announced in April; generally available on November 14

  3. 2021

    60-minute request timeouts and up to 1,000 concurrent requests per instance

  4. 2022

    Second-generation microVM execution environment reaches general availability

  5. 2023

    Cloud Run jobs for run-to-completion work become generally available

  6. 2025

    GPUs generally available in April for inference workloads

  7. 2026

    Worker pools for always-on background work reach general availability

Sources13 · facts checked 5 October 2026

Improve this page on GitHub