---
cuppy_hub: gcp
cuppy_path: reference/compute/cloud-run.md
cuppy_section: docs
cuppy_doc: VR1P-T98Y
cuppy_doc_uuid: 0a5bdfe6-620a-4707-a652-cb9a50b5b585
cuppy_permalink: https://cuppy.io/gcp/d/VR1P-T98Y
cuppy_version: 1
cuppy_updated: 2026-10-23T16:16:52.575Z
cuppy_canonical: https://cuppy.io/gcp/docs/reference/compute/cloud-run
cuppy_mcp: https://cuppy.io/mcp
cuppy_body_sha256: 2fb838c22caf0912520b9707c0d1425b99178a67b189d9087e0305e372b3b6a8
# cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks.
---


# 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.
2. **Rollback is free and exact**, because the old revision still exists with its configuration intact.
3. **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`.


---
<!-- cuppy -->
You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 91 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/gcp/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.
<!-- /cuppy -->