# What Cloud Run is, for someone who has never used it

> Cloud Run runs your container and bills for the seconds it works. What it runs, its three shapes, how it bills, what changes in your code, cold starts, what it does not do, a first deploy.

Published 2026-10-10 · Updated 2026-10-13 · [By Exodus team](https://exodus.elim.io/about) · Basics
<https://exodus.elim.io/blog/what-cloud-run-is>

Cloud Run is Google's service for running a container that answers HTTP. You hand it an image or source code, and it gives back an HTTPS address, starts as many copies of the app as the traffic needs and stops them when it falls, down to none. By default it bills only while a request is handled: $0.000024 per vCPU-second in Tier 1 regions, after 180,000 free a month.

## In short

- A service answers requests for up to 60 minutes each, a job runs a task for up to 168 hours, and a worker pool, generally available since April 14, 2026, keeps processes up.
- Request-based billing, the default, costs $0.000024 per vCPU-second and $0.0000025 per GiB-second in Tier 1, after 180,000 vCPU-seconds and 360,000 GiB-seconds free a month.
- One instance takes up to 1,000 requests at once, 80 by default at 1 vCPU, and a revision scales to 100 instances unless you lower it.
- For one instance of 1 vCPU and 512 MiB, request-based billing costs less than instance-based until it is busy about 18 hours a day.
- Every service without a GPU has a 99.95% monthly uptime commitment, in 43 regions.

Prices are Google's Tier 1 list prices, read on October 12, 2026.

## What it runs

There is no server to pick and no cluster to keep: you say how much CPU and memory one copy of the app gets, and Cloud Run does the rest. If you came from Heroku, Railway, Render or Fly, most of it will feel familiar: a web process built from your repository, environment variables, logs in a console, a URL. The difference that matters is how it bills, and that one rule changes a few habits in the code.

Your app is a container, a packaged Linux process with its files, that listens for HTTP on the port Cloud Run passes in the `PORT` environment variable, 8080 unless you change it. Anything that runs in Docker runs here: Node, Python, Ruby, Go, Rust, Java, PHP, a binary you compiled yourself. If you have no Dockerfile, `gcloud run deploy` with a source folder builds the image with Google's buildpacks, which read the same `package.json`, `requirements.txt` or `Gemfile` a PaaS reads; [buildpacks or a Dockerfile](https://exodus.elim.io/blog/buildpacks-or-a-dockerfile) compares the two.

Each running copy of the container is an **instance**. You set its size, for example 1 vCPU and 512 MiB of memory, which is enough for most small web apps. A deploy creates a **revision**, an unchangeable snapshot of the image and its settings, and the service sends traffic to revisions.

One instance takes many requests at once. Google's page gives two defaults: 80 when a service is created in the console, and 80 times the number of vCPUs when it is created with `gcloud` or Terraform, so 80 at 1 vCPU either way. The maximum is 1,000. When requests pile up beyond that, Cloud Run starts another instance, up to 100 per revision by default. You can lower that ceiling, and you should, because it is also the ceiling on the bill. [Concurrency on Cloud Run](https://exodus.elim.io/blog/concurrency-on-cloud-run) explains how to pick the number for your stack.

The container has to follow a short contract. It must listen on 0.0.0.0, not localhost, or nothing reaches it. Its disk is memory: whatever it writes counts against the memory limit and disappears with the instance. When Cloud Run stops an instance it sends SIGTERM, waits 10 seconds and then kills the process, so the app should finish its requests and exit in that time. A request that arrives while no instance is ready waits for one, for up to 3.5 times the service's average startup time or 10 seconds, whichever is longer.

## Three shapes

![Three columns. A service is started by an HTTPS request, answers requests with 0 to N instances by the traffic, bills while requests run, and a request may take up to 60 minutes. A job is started by a command from gcloud, Scheduler or CI, runs to the end and exits, bills while it runs, and a task may take up to 168 hours. A worker pool is started by nothing, pulls from a queue, keeps processes up, bills all the time, and is generally available since April 2026](https://exodus.elim.io/media/v2026-09-16/t/exodus/assets/image-83711f45902603732e30c98e0180e7b640e0e88c268087af752c4e7b55cfe8b7-680x360-svg/bytes "The three things Cloud Run runs. Most apps from a PaaS become one service and a job or two.")

- A **service** answers requests. This is your web process. A request may run for 5 minutes by default and up to 60 minutes if you raise the timeout. Each service gets a `run.app` address with HTTPS.
- A **job** runs a command to the end and exits: a migration, a nightly export, anything a cron used to start. It has no URL. A job's task runs for up to 10 minutes by default and up to 168 hours, seven days, if you raise it; with a GPU the limit is one hour. A job can also split into many tasks that run in parallel.
- A **worker pool** keeps processes running that pull work instead of answering requests: a Pub/Sub or Kafka consumer, a loop that holds one connection for hours. It became generally available on April 14, 2026. It has no URL, you set how many instances it runs, and it bills all the time those instances exist.

Most apps from a PaaS become one service, a job or two and nothing else, because a background worker usually turns into requests to the service (more on that below). [Services, jobs and worker pools](https://exodus.elim.io/blog/cloud-run-services-jobs-and-worker-pools) goes through each shape with its commands and limits.

## How it bills

By default a service uses **request-based billing**. An instance is billed while it starts, while it handles at least one request, and while it shuts down, rounded up to the nearest 100 ms. Between requests it is not billed. Two requests that overlap on one instance are billed once, for the time either of them is open, which is why concurrency saves money. After the last request Cloud Run may keep the instance around, idle and unbilled, for up to 15 minutes, so the next visitor does not wait for a start. When nobody calls the service at all, it has no instances and costs nothing.

![A timeline of one instance. On the requests row there is a start, two overlapping requests, an idle gap, a third request, an idle gap of up to 15 minutes and a stop. With request-based billing only the start, the requests and the stop are billed, and the gaps are not. With instance-based billing the whole line from start to stop is billed](https://exodus.elim.io/media/v2026-09-16/t/exodus/assets/image-b23f28449bcbf6a1d32f002d8900041640a6268efbf4753420842e4a3be031dd-680x300-svg/bytes "What one instance is billed for under each setting. Overlapping requests share the billed time.")

Google prices CPU per vCPU-second, memory per GiB-second and requests per million. In Tier 1 regions, such as `us-central1` in Iowa and `europe-west1` in Belgium, the list prices on October 12, 2026 were:

- **Request-based:** $0.000024 per vCPU-second, $0.0000025 per GiB-second, $0.40 per million requests. Free each month: 180,000 vCPU-seconds, 360,000 GiB-seconds and 2 million requests.
- **Instance-based:** $0.000018 per vCPU-second and $0.000002 per GiB-second, with no charge per request. Free each month: 240,000 vCPU-seconds and 450,000 GiB-seconds.

The free tier belongs to the billing account, not to the service, and resets every month: two apps on one account share it. 180,000 vCPU-seconds is 50 hours of one busy vCPU. A web app with a couple of thousand visits a day, ten requests a visit and a third of a second each, uses about 210,000 vCPU-seconds a month and pays for the 30,000 over the line: 72 cents. [The free tier explained](https://exodus.elim.io/blog/the-cloud-run-free-tier-explained) shows what else counts against it.

**Instance-based billing** is the other setting: the CPU stays on for the whole life of the instance, and every second the instance exists is billed, busy or not. Each second is cheaper, so the choice comes down to how much of the day an instance is busy. For one instance of 1 vCPU and 512 MiB, request-based billing stays under the always-on price until the instance is busy about 18 hours a day.

![A line chart of the monthly cost of one instance of 1 vCPU and 512 MiB by hours a day with at least one request in flight. Request-based billing stays inside the free tier up to 1.6 hours a day and rises to $61.14 at 24 hours. Instance-based billing, always on, is a flat $44.71. The lines cross at 18.1 hours a day](https://exodus.elim.io/media/v2026-09-16/t/exodus/assets/image-2066fbc61111a1f0083deea4cb9af2e4f69210df91fd37b24fad0e6fa89ad87a-680x350-svg/bytes "Request-based against instance-based for one instance, after each mode's free tier, requests not counted. Tier 1 list prices of Oct 12, 2026.")

That suits a process that keeps a CPU busy most of the day, and for such a process Cloud Run is often not the cheapest home at all: [Cloud Run or a VPS](https://exodus.elim.io/blog/cloud-run-or-a-vps) compares the two under steady load. [Request-based or instance-based billing](https://exodus.elim.io/blog/request-based-or-instance-based-billing) works the choice through with more cases, and [what Cloud Run costs](https://exodus.elim.io/blog/what-cloud-run-costs) prices a whole small app line by line. In Tier 2 regions, such as London or Frankfurt, request-based prices are 1.4 times these and instance-based 1.2 times.

## What changes for your code

Under request-based billing the CPU is there only while a request is in flight. The disk is memory and goes away with the instance. An instance can stop whenever traffic falls, and the next request may land on a different one. Four habits of a PaaS app break because of this:

1. **Timers inside the process** (`setInterval`, `node-cron`, APScheduler, a clock process) fire late or never, because there is no CPU between requests and no process at all when the service is at zero. With three instances they fire three times.
1. **Work done after the response is sent** stalls. A handler that answers and then sends an email loses its CPU the moment the response is out, so the email goes when the next request arrives, or never.
1. **Files written to local disk** vanish with the instance and are not shared between instances. An upload saved on one instance is a 404 on the next.
1. **Sessions and queues held in memory** are lost when the instance stops, and moving them to a Redis that runs all month brings back the bill you left.

Each one has a standard replacement on Google Cloud: [Cloud Scheduler for timers](https://exodus.elim.io/blog/cron-and-timers-with-cloud-scheduler), [Cloud Tasks for workers and work after the response](https://exodus.elim.io/blog/background-workers-with-cloud-tasks), [a Cloud Storage bucket for files](https://exodus.elim.io/blog/files-and-uploads-with-cloud-storage) and [signed cookies for sessions](https://exodus.elim.io/blog/sessions-without-redis). [The patterns that break on Cloud Run](https://exodus.elim.io/blog/patterns-that-break-on-cloud-run) lists the rest, such as WebSockets held for hours and in-memory caches.

The Exodus CLI looks for these in a repository. Here is its check on a small Express app written for Heroku, with a timer, a session store in memory, uploads to disk and a BullMQ worker:

![Terminal output of exodus check on a sample Heroku app: server.js line 9, files written to local disk, with the hint to write to a Cloud Storage bucket and hand out signed URLs; server.js line 12, sessions kept in process memory; server.js line 27, timers inside the process; worker.js line 4, a worker waits on a Redis queue; and the summary, 4 found that fail the run](https://exodus.elim.io/media/v2026-09-16/t/exodus/assets/image-3000f7f512ea87b29aa675785f71883421e0788480a61ddd4ae66c18e2a8e0a3-680x228-svg/bytes "exodus 0.1.3 on a sample app, Oct 12, 2026. Each finding names the file and line and the replacement; the hints after the first are cut here.")

It missed one thing in that sample: the signup handler sends its welcome email after the response, the second habit above. A search for code after `res.send` or `res.json` in your handlers is worth five minutes before you move.

## Cold starts

When a service at zero gets a request, an instance has to start before it can answer: Cloud Run pulls the image, starts the container and waits for it to listen on the port. That wait is the cold start, and Google publishes no figure for it, because it depends mostly on your app.

The numbers we have are these. In an independent study by TU Berlin, run from Frankfurt between November 2025 and January 2026, Google's function platform, which is built on Cloud Run, had a median cold start of 534 ms with startup CPU boost off; [Cloud Run cold starts, measured](https://exodus.elim.io/blog/cloud-run-cold-start-measured) has the study's setup and the other platforms. Exodus team: one of our Rust APIs at 1 vCPU and 256 MiB started 17 instances in a week of October 2026, with a median container startup of 94 ms and none over 280 ms; another Rust API we moved answered its first byte 0.8 to 1.7 s after a request that had to start an instance. A Node or Python app that loads many packages at start takes longer, so measure your own.

Two settings help:

- **Startup CPU boost** gives an instance more CPU while it starts and for 10 seconds after: 2 vCPU for a service of up to 1, 4 for 2, 8 for 4. The extra CPU is billed for those seconds, which on a small service is cents a month.
- **A minimum number of instances** keeps that many instances running between requests, so the first visitor after a quiet hour does not wait. Their idle time bills at a lower rate: one instance of 1 vCPU and 512 MiB kept all month costs about $9.86 at Tier 1 list prices.

[Min instances and startup CPU boost](https://exodus.elim.io/blog/min-instances-and-startup-cpu-boost) shows when each one pays for itself.

## What comes with it

- **A 99.95% monthly uptime commitment** on every service without a GPU, with credits on the bill when Google misses it, and no plan to buy. In Mexico and Stockholm it is 99.9%.
- **43 regions**, as `gcloud run regions list` printed on October 12, 2026. [Choosing a region](https://exodus.elim.io/blog/choosing-a-cloud-run-region) weighs price tier, latency and what each region offers.
- **HTTPS by default.** Every service gets a `run.app` address with a certificate, ended at Google's edge close to the visitor.
- **Revisions.** Every deploy is kept, and traffic can be split between revisions by percent, so a rollback is one command and a new version can take 5% of traffic first. [Revisions, traffic splitting and rollbacks](https://exodus.elim.io/blog/revisions-traffic-splitting-and-rollbacks) has the commands.
- **Logs and metrics** in Cloud Logging and Cloud Monitoring, with no add-on: whatever the app prints to stdout is a log line, and a JSON line becomes a structured entry. [Logs, metrics and alerts](https://exodus.elim.io/blog/logs-metrics-and-alerts-for-a-cloud-run-app) sets them up.

## What it is not

Cloud Run is not a VM. You cannot SSH into a long-lived box and change things by hand: an instance is replaced at the next deploy and may be stopped at any time. Google announced SSH into a running instance in April 2026, and `gcloud beta run services ssh` exists, but it is in preview for selected customers; for a one-off command, run it as a job.

It is not a fit for a process that holds thousands of open connections all day, or keeps a CPU busy around the clock: both bill all the time, and the chart above shows where that crosses a fixed price.

It does not give you a free custom domain in production. Cloud Run's own domain mappings are in Preview, in 10 regions, and Google says they are not production-ready; for production you put Firebase Hosting or a load balancer in front, as [custom domains and HTTPS](https://exodus.elim.io/blog/custom-domains-and-https-on-cloud-run) explains.

And it has no spending limit unless you set one. Google bills what runs: a loop or a crawler scales the service up and the bill with it. Set a maximum number of instances on every service and a budget alert on the billing account. A spend cap budget can also pause Cloud Run in one project when its estimated cost passes an amount, but it is not instant and it takes the app down; [setting up a project for a small team](https://exodus.elim.io/blog/setting-up-a-google-cloud-project-for-a-small-team) covers both.

## A first deploy

This needs a Google account with billing, the `gcloud` CLI, and a folder with an app that listens on `PORT`. Sign in and choose the project:

```shell
gcloud auth login
gcloud config set project YOUR_PROJECT_ID
```

Turn on the three services a deploy from source uses, Cloud Run, Cloud Build and Artifact Registry:

```shell
gcloud services enable run.googleapis.com cloudbuild.googleapis.com artifactregistry.googleapis.com
```

Deploy from the folder. The command builds the image, stores it, creates the service and prints its URL. The last two flags make it public and cap it at three instances:

```shell
gcloud run deploy hello \
  --source . \
  --region europe-west1 \
  --allow-unauthenticated \
  --max-instances 3
```

Read the last lines of its log:

```shell
gcloud run services logs read hello \
  --region europe-west1 \
  --limit 20
```

The first build takes a few minutes; later deploys reuse the cached layers. A build on Cloud Build and an image in Artifact Registry each have their own small bill and free tier, which [what Cloud Run costs](https://exodus.elim.io/blog/what-cloud-run-costs) adds to the total. To roll back, send all traffic to the revision before:

```shell
gcloud run services update-traffic hello \
  --region europe-west1 \
  --to-revisions hello-00001-abc=100
```

The revision names are in `gcloud run revisions list`. Replace `hello-00001-abc` with yours.

## Where Exodus comes in

If your app is an ordinary web service with a database, a few background jobs and a schedule, it fits Cloud Run. Exodus reads your repository and tells you which parts need to change before it does, with file and line, as in the check above. Its report prices today's host against Cloud Run from Google's list prices, and its plan orders the work: change the code where it runs now, stand up the new app beside it, copy the data, switch the domain.

## FAQ

### Can Cloud Run scale to zero?

Yes. When nobody calls a Cloud Run service, it has no instances and costs nothing. The first request after that waits while an instance starts: one of our Rust APIs started in a median of 94 ms, and a Node or Python app that loads many packages takes longer. A minimum instance avoids the wait for about $9.86 a month.

### How long can a Cloud Run request run?

A request to a Cloud Run service may run for 5 minutes by default and up to 60 minutes if you raise the timeout. Longer work belongs in a job, whose task runs for up to 10 minutes by default and up to 168 hours, seven days, if you raise it; with a GPU the limit is one hour.

### What languages does Cloud Run support?

Cloud Run runs any container that listens for HTTP on the port in the PORT variable, 8080 by default: Node, Python, Ruby, Go, Rust, Java, PHP or a binary you compiled yourself. Without a Dockerfile, a deploy from a source folder builds the image with Google's buildpacks.

### Can I SSH into a Cloud Run container?

Not as a rule. Google announced SSH into a running instance in April 2026, but it is in preview for selected customers. An instance is replaced at the next deploy and may be stopped at any time, so a one-off command, such as a migration, runs as a Cloud Run job.

### Can Cloud Run use a custom domain?

Cloud Run's own domain mappings are in Preview in 10 regions, and Google says they are not production-ready. For production, put Firebase Hosting or a load balancer in front of the service. Every service also gets a run.app address with HTTPS and a certificate, ended at Google's edge.

## Sources

1. [Container runtime contract, Cloud Run, Google (requests go to port 8080 by default, through the PORT variable; a request waits for a new instance for up to 3.5 times the average startup time or 10 s, whichever is greater; SIGTERM, then 10 s, then SIGKILL, and those 10 s are billed; the filesystem is in memory; updated Oct 9, 2026, read Oct 12, 2026)](https://docs.cloud.google.com/run/docs/container-contract)
2. [Deployment options and resource model, Cloud Run, Google (services, jobs, worker pools; worker pools are for non-request work such as pull queues; read Oct 12, 2026)](https://docs.cloud.google.com/run/docs/resource-model)
3. [Maximum concurrent requests for services, Cloud Run, Google (up to 1,000 per instance; 80 by default in the console, 80 times the vCPUs for a new service created with gcloud or Terraform; updated Oct 9, 2026, read Oct 12, 2026)](https://docs.cloud.google.com/run/docs/about-concurrency)
4. [Set maximum instances for services, Cloud Run, Google (by default Cloud Run sets 100 instances for each revision; updated Oct 9, 2026, read Oct 12, 2026)](https://docs.cloud.google.com/run/docs/configuring/max-instances)
5. [Configure request timeout for services, Cloud Run, Google (5 minutes by default, up to 60 minutes; updated Oct 9, 2026, read Oct 12, 2026)](https://docs.cloud.google.com/run/docs/configuring/request-timeout)
6. [Set task timeout for jobs, Cloud Run, Google (10 minutes by default, up to 168 hours, 7 days; 1 hour with GPUs; updated Oct 9, 2026, read Oct 12, 2026)](https://docs.cloud.google.com/run/docs/configuring/task-timeout)
7. [Cloud Run release notes, Google (worker pools generally available Apr 14, 2026; deploying with a Compose file generally available Mar 25, 2026; read Oct 12, 2026)](https://docs.cloud.google.com/run/docs/release-notes)
8. [Cloud Run pricing, Google (request-based: $0.000024 per vCPU-second, $0.0000025 per GiB-second, $0.40 per million requests, free each month per billing account 180,000 vCPU-seconds, 360,000 GiB-seconds and 2 million requests; instance-based: $0.000018 and $0.000002, free 240,000 and 450,000; idle minimum instance $0.0000025 per vCPU-second and per GiB-second; rounded up to the nearest 100 ms; Tier 1 list prices read Oct 12, 2026)](https://cloud.google.com/run/pricing)
9. [Billing settings for services, Cloud Run, Google (request-based instances are charged when they process requests, start and shut down; instance-based for the whole life of the instance; updated Oct 7, 2026, read Oct 12, 2026)](https://docs.cloud.google.com/run/docs/configuring/billing-settings)
10. [About instance autoscaling, Cloud Run, Google (to minimize cold starts Cloud Run might keep instances idle for up to 15 minutes after they finish handling requests; updated Oct 9, 2026, read Oct 12, 2026)](https://docs.cloud.google.com/run/docs/about-instance-autoscaling)
11. [Configure CPU limits for services, Cloud Run, Google (startup CPU boost: 0-1 vCPU becomes 2, 2 becomes 4, 4 becomes 8, during startup and for 10 seconds after, and the boosted CPU is billed; updated Oct 9, 2026, read Oct 12, 2026)](https://docs.cloud.google.com/run/docs/configuring/services/cpu)
12. [Schirmer et al., New Kids: An Architecture and Performance Investigation of Second-Generation Serverless Platforms, TU Berlin, arXiv 2604.15916 v2 (Cloud Run functions, a layer on Cloud Run, with startup CPU boost off; the 534 ms median cold start is from the earlier read in docs/research/2026-10-11-site-claims; re-read Oct 12, 2026)](https://arxiv.org/abs/2604.15916)
13. [Cloud Run SLA, Google (99.95% monthly uptime for a Cloud Run service without GPU, 99.9% in Mexico and Stockholm; read Oct 12, 2026)](https://cloud.google.com/run/sla)
14. [Cloud Run locations, Google, and gcloud run regions list (43 regions on Oct 12, 2026)](https://docs.cloud.google.com/run/docs/locations)
15. [Rollouts, rollbacks and traffic migration, Cloud Run, Google (gcloud run services update-traffic with --to-revisions REVISION=PERCENTAGE; updated Oct 9, 2026, read Oct 12, 2026)](https://docs.cloud.google.com/run/docs/rollouts-rollbacks-traffic-migration)
16. [Map custom domains, Cloud Run, Google (domain mappings are in Preview, not production-ready, in 10 regions; Firebase Hosting or a global external Application Load Balancer for production; updated Oct 9, 2026, read Oct 12, 2026)](https://docs.cloud.google.com/run/docs/mapping-custom-domains)
17. [What's new in Cloud Run at Next '26, Google Cloud blog (SSH into a running Cloud Run container, in preview with select customers; Apr 22, 2026, read Oct 12, 2026)](https://cloud.google.com/blog/products/serverless/whats-new-for-cloud-run-at-next26)
18. [Manage spend cap budgets, Cloud Billing, Google (Cloud Run is an eligible service; enforced on gross estimated costs, not instantly, usage before it is billed as normal; read Oct 12, 2026)](https://docs.cloud.google.com/billing/docs/how-to/budgets-spend-caps)
19. [gcloud reference, Google Cloud SDK 587.0.0 (--help of run deploy, run services update, run services logs read, run services update-traffic, beta run services ssh; read Oct 12, 2026)](https://docs.cloud.google.com/sdk/gcloud/reference/run/deploy)
20. Exodus team: a Rust API of ours on Cloud Run (1 vCPU, 256 MiB), Oct 5-12, 2026: 17 instance starts, container startup median 94 ms, the slowest under 280 ms; another Rust API we moved, Oct 5, 2026: 0.79-1.69 s to the first byte for requests that started an instance; exodus 0.1.3 check on a sample Heroku app, Oct 12, 2026