Skip to main content
Cloud & AI Hub
Browse
Glossary AI Directory Playgrounds Models Prompts Explainers Strategy Matrix Benchmark Decoder
Compute

Google Cloud Run

Google's serverless container platform — deploy any container, scale to zero, pay per use. The middle path between functions and Kubernetes.

What is Cloud Run?

Google Cloud Run runs containers serverlessly: deploy any container image that listens on a port, and Cloud Run handles provisioning, HTTPS, and autoscaling — including scale to zero (pay nothing when idle) and rapid scale-out under load. It occupies the sweet spot between Lambda-style functions (you write a handler, the platform owns the runtime) and GKE (full Kubernetes power and full ops): you bring a container, and get serverless economics without adopting Kubernetes.

Why the container-not-function model matters

Cloud Run’s “any container” contract is its defining advantage over FaaS. No runtime restrictions, no vendor-specific handler signatures, no packaging quirks — if it runs in a container and serves HTTP, it runs on Cloud Run, which means trivial local development (it’s just a container), painless portability (the same image runs anywhere), and no lock-in to a proprietary function format. It handles request-driven workloads and, with always-on CPU, background and streaming work too. This makes it the natural landing spot for the large class of stateless web services and APIs that don’t need Kubernetes but shouldn’t be contorted into functions.

The serverless realities still apply

Cloud Run inherits the serverless caveats: cold starts on scale-from-zero (mitigated with minimum instances, at the cost of paying for idle — the usual tradeoff), statelessness (persistent state lives elsewhere), and request-timeout and concurrency limits to design around (Cloud Run’s per-instance concurrency — many requests per container — actually softens cold-start and cost pressure versus one-request-per-instance models). And the perennial crossover: at sustained high, steady load, always-on GKE or GCE capacity can undercut per-use pricing.

What people get wrong

  • Reaching for GKE when Cloud Run would serve the stateless workload with a fraction of the concepts.
  • Ignoring concurrency tuning — Cloud Run’s multi-request-per-instance model is a major cost and cold-start lever left at defaults.
  • Scale-to-zero for latency-critical paths without minimum instances, then blaming the platform for cold-start latency.

Primary source: Google Cloud Run documentation

Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.