Cloud Run's resource model

1. Four resource types, and the question each answers

Resource	For	Scaling
service	request-driven work — "Websites, APIs, Microservices"	automatic, on incoming request volume
job	task-driven work that runs to completion	per execution
worker pool	background work with no public endpoint	manual, or on external metrics — not on requests
instance	a singleton with its own URL and a restart policy	none

Choosing wrongly here is the most common Cloud Run design error, and the giveaway is a service with a long-running background loop: that is a worker pool, because a service scales on requests it is not receiving.

2. A revision is immutable, and that is the whole deployment model

"A revision consists of one or more container images, along with configuration settings."

Revisions are immutable snapshots, one per deployment, carrying the images and the configuration — environment variables, memory limits, and the rest. A revision cannot be modified. Changing anything creates a new revision.

Three consequences:

1. There is no "change an environment variable" operation. There is only "deploy a new revision with the

new value". Expect a new revision in the audit log for every config touch, and design any change process around that rather than against it.

1. Rollback is free and exact, because the old revision still exists with its configuration intact.
2. The service's URL is stable and load-balanced across revisions, so traffic splitting between revisions

is a property of the service, not something to build.

3. Jobs decompose twice

job → execution → task

A job is the definition. An execution is one run of it. Tasks are the parallel units inside an execution, and they run to completion. So "retry the job" and "retry the task" are different operations at different levels, and a job's observability has to be read at the task level to be useful.

4. Worker pools and instances — the two that surprise people

• a worker pool has no public endpoint and no automatic request-based scaling. Autoscaling is manual or

driven by external metrics. This is the Cloud Run shape for a queue consumer that should not be reachable from the internet.

• an instance resource is a singleton with its own dedicated URL and a restart policy, and **no

autoscaling at all**. It is the closest Cloud Run gets to "one long-lived container, addressable".

Note the word instance is used two ways in Cloud Run's documentation: the resource type above, and the container instances a service scales out to. Read which one a page means from its context.

5. What must be true of the container

Covered as errors because that is how you meet it: the container must listen on the port given by the PORT environment variable, on all interfaces rather than loopback, and be a 64-bit Linux image. The verbatim failure strings and their fixes are in reference/compute/errors.md §1.

6. For an estimate

Cloud Run's unit of deployment is a container plus its configuration, versioned. That makes it the cheapest target on Google Cloud for a containerised service arriving from anywhere else: no cluster, no node pool, no scaling policy to port. Where it costs more than expected is the two cases in §1 and §4 — background workers and singletons — which need a different resource type and, on some source platforms, a different architecture.

Next: guides/compute/deploy-a-container-on-cloud-run.md, and the comparison with AWS Fargate / App Runner / Lambda and Azure Container Apps in guides/parity/compute.md.