Google Cloud Run
Google's own overview docs for Cloud Run, "a fully managed application platform for running your code, function, or container" — the third hyperscaler's entry in the managed-PaaS tier this spoke tracks, alongside AWS's Lambda/Firecracker line. Routed here via Telegram.
Four resource types, not one
Services answer HTTP at a *.run.app endpoint (custom domains, WebSockets, HTTP/2, gRPC).
Jobs run a task to completion — manual, scheduled, or workflow-triggered, with array jobs for
parallel independent tasks. Worker pools pull continuous background work (Kafka, Pub/Sub,
RabbitMQ) with no public URL and no default autoscaling — you set instance count manually or scale
on an external metric (Kafka lag, Pub/Sub backlog). Instances (preview) are long-lived singleton
runtimes, each with its own URL. Deploy is container-first but doesn't require writing a
Dockerfile — Google's open-source buildpacks containerize source for Go, Node.js, Python, Java,
.NET and Ruby.
True scale-to-zero, and a billing-mode choice none of the indie PaaS tier offers
Services autoscale to ~1,000 instances by default and, with no traffic, remove the last instance — not "spin down," gone entirely, which is a stronger claim than render's 15-minute idle sleep. CPU and memory bill at 100ms granularity, and the platform offers two billing modes as a deliberate choice: request-based (pay per request, nothing while idle) or instance-based (pay for the instance's whole lifetime, no per-request fee). Every Tier 2 PaaS page this spoke holds picks one model and sells it; Cloud Run lets the operator pick per service.
Where the docs stop short
No cold-start number: the page describes "higher latency" on a request to a scaled-to-zero service, "depending on how quickly your container becomes ready," and separately states new instances are ready in about 20 seconds — but doesn't connect the two into a stated cold-start figure. No request timeout or concurrency limit is given in the overview; both are pushed to linked configuration pages. Instances restart for infrastructure updates "every 1 to 2 weeks," which is a maintenance fact none of fly-io, render or railway's pages state about themselves.
Why it matters to the spectrum this spoke tracks
Cloud Run is the clean test of whether a hyperscaler can sell the Tier 2 PaaS pitch ("no idle markup," git-push-shaped deploys) on its own infrastructure rather than ceding it to Render/Railway/ Fly. The standing growth edge here — a neutral, methodology-disclosed PaaS benchmark — still has nothing to measure Cloud Run against those three on cold-start or price at matched load; this page is first-party only (T3) and states no comparative number at all.
Related
google-cloud · aws-lambda-microvms · render · railway · fly-io · cloudflare · cloud-run-sandboxes · agent-starter-pack · synthesis