Google Cloud Run vs Heroku
SEPT 2026 auditA comparison of Google Cloud Run and Heroku built from values read directly from each provider's own documentation, with the source recorded against every figure.
The short answer
Choose Google Cloud Run if…
A container you already build, that should cost nothing when nobody is using it. Scales to zero by default and back up on request volume, with a 60-minute ceiling per request that most request-driven platforms do not offer.
Editorial · Palash Bagchi · approved
Choose Heroku if…
Teams that want to deploy by pushing to Git and let the platform handle the runtime, with Postgres, a scheduler and Docker deploys available on the same platform.
Editorial · Palash Bagchi · approved
Consider something else if…
- Google Cloud Run: You need a process that stays running between requests, or a disk that survives a deploy.
- Heroku: The dyno filesystem is ephemeral, and a web process must respond within 30 seconds of receiving a request.
6 sourced criteria separate them — see where, with sources, below.
Pick the criteria you care about. The chart counts how many of them lean toward each provider — the same read as scanning the bars below, just totalled for the ones you chose.
Google Cloud Run 0
Heroku 0
At a glance.
| Criterion | Google Cloud Run | Heroku |
|---|---|---|
| Pricing | ||
| Pricing model | Metered by resource, billed in 100 ms increments, with no monthly minimum. Two billing settings change what is counted: request-based charges CPU only while a request is being processed, instance-based charges for the whole instance lifecycle. Prices vary by region — the location list is split into Tier 1 and Tier 2 pricing — and the free tier is applied as a spending-based discount at Tier 1 rates. | Usage-based on wall-clock time, prorated to the second |
| Limits | ||
| Max request duration | 5 minutes by default, extendable to 60 minutes per request. | 30 seconds (initial window for the web process to return response data) |
| Deployment | ||
| Git deployment | Supported | Supported |
| Docker deployment | Supported | Supported |
| Containers | Supported | Supported |
| Infrastructure | ||
| Persistent processes | Limited — instance-based billing keeps CPU allocated | Supported |
| Scales to zero | Supported | Limited |
| Autoscaling | Supported | Limited |
| Regions | 41 regions, counted from Cloud Run's own locations list — Google publishes the list rather than a total. They are split into Tier 1 and Tier 2 pricing, so the region chosen changes the bill as well as the latency. | 2 regions on the Common Runtime, which is what a standard dyno runs in: eu (Europe) and us (United States). A further 10 — Dublin, Frankfurt, London, Montreal, Mumbai, Oregon, Singapore, Sydney, Tokyo and Virginia — exist only in Private Spaces, an Enterprise product. |
Where they differ.
Pricing model
- Google Cloud Run
- Metered by resource, billed in 100 ms increments, with no monthly minimum. Two billing settings change what is counted: request-based charges CPU only while a request is being processed, instance-based charges for the whole instance lifecycle. Prices vary by region — the location list is split into Tier 1 and Tier 2 pricing — and the free tier is applied as a spending-based discount at Tier 1 rates.
- Heroku
- Usage-based on wall-clock time, prorated to the second
Sources (2) →Sources ↓
- Cloud Run pricing — Google Cloud ↗
“Cloud Run charges you only for the resources you use, rounded up to the nearest 100 millisecond. Your total Cloud Run bill will be the sum of the resource usage in the pricing table after the free tier is applied. [...] Cloud Run pricing depends on the selected region. Pricing for Cloud Run services also depends on the billing configuration. [...] The free tier is applied as a spending based discount using Tier 1 pricing.”
Read 2026-09-09 · official pricing
- Usage & Billing | Heroku Dev Center ↗
“Heroku computes usage from wall-clock time, not CPU time. Any dynos scaled above 0 accrue usage, regardless of traffic or activity. Heroku prorates all costs to the second.”
Read 2026-09-05 · official docs
Max request duration
5 minutes by default, extendable to 60 minutes per request.
30 seconds (initial window for the web process to return response data)
Sources (2) →Sources ↓
- Configure request timeout for services — Google Cloud Documentation ↗
“The timeout is set by default to 5 minutes (300 seconds) and can be extended up to 60 minutes (3600 seconds).”
Read 2026-09-09 · official docs
- Limits | Heroku Dev Center ↗
“HTTP requests have an initial 30 second window for the web process to return response data. It can be either the completed response or some amount of response data to indicate that the process is active. Processes that fail to send response data within the initial 30-second window see an H12 error in their logs.”
Read 2026-09-05 · official docs
Persistent processes
- Google Cloud Run
- Limited — instance-based billing keeps CPU allocated
- Heroku
- Supported
Sources (2) →Sources ↓
- Billing settings for Cloud Run services — Google Cloud Documentation ↗
“With request-based billing, CPU is only allocated during request processing. With instance-based billing, CPU is allocated for the entire container instance lifecycle. [...] Instance-based billing can be useful for running short-lived background tasks and other asynchronous processing tasks. This setting was previously called CPU always allocated.”
Read 2026-09-09 · official docs
- Dynos (App Containers) | Heroku Dev Center ↗
“Worker dynos are typically used to run background jobs, queueing systems, and timed jobs. You can have multiple kinds of worker dynos in your application.”
Read 2026-09-05 · official docs
Scales to zero
- Google Cloud Run
- Supported
- Heroku
- Limited
Sources (2) →Sources ↓
- About instance autoscaling in Cloud Run services — Google Cloud Documentation ↗
“When a revision does not receive any traffic, by default, it is scaled to zero instances.”
Read 2026-09-09 · official docs
- Eco Dyno Hours | Heroku Dev Center ↗
“If an app has an Eco web dyno, and that dyno receives no web traffic in a 30-minute period, it sleeps. In addition to the web dyno sleeping, if you have a worker Eco dyno, it also sleeps. Eco web dynos do not consume Eco dyno hours while sleeping.”
Read 2026-09-05 · official docs
Autoscaling
- Google Cloud Run
- Supported
- Heroku
- Limited
Sources (2) →Sources ↓
- About instance autoscaling in Cloud Run services — Google Cloud Documentation ↗
“By default, each Cloud Run revision is automatically scaled to the number of instances needed to handle incoming requests, events, or CPU utilization. [...] Cloud Run adjusts instance counts to keep average CPU and concurrency within target thresholds.”
Read 2026-09-09 · official docs
- Scaling Your Dyno Formation | Heroku Dev Center ↗
“Heroku offers Autoscaling for Performance-, Private- and Shield-tier dynos. If that feature doesn't meet your needs, consider a third-party add-on from the Elements marketplace.”
Read 2026-09-05 · official docs
Regions
41 regions, counted from Cloud Run's own locations list — Google publishes the list rather than a total. They are split into Tier 1 and Tier 2 pricing, so the region chosen changes the bill as well as the latency.
2 regions on the Common Runtime, which is what a standard dyno runs in: eu (Europe) and us (United States). A further 10 — Dublin, Frankfurt, London, Montreal, Mumbai, Oregon, Singapore, Sydney, Tokyo and Virginia — exist only in Private Spaces, an Enterprise product.
Sources (2) →Sources ↓
- Cloud Run locations — Google Cloud Documentation ↗
“Each Cloud Run resource resides in a region. [...] Subject to Tier 1 pricing asia-east1 (Taiwan) asia-northeast1 (Tokyo) asia-northeast2 (Osaka) asia-south1 (Mumbai, India) asia-southeast1 [...] northamerica-northeast2 (Toronto) southamerica-east1 (Sao Paulo, Brazil) southamerica-west1 (Santiago, Chile) us-west2 (Los Angeles) us-west3 (Salt Lake City) us-west4 (Las Vegas)”
Read 2026-09-09 · official docs
- Regions | Heroku Dev Center ↗
“eu Europe Common Runtime us United States Common Runtime dublin Dublin, Ireland Private Spaces frankfurt Frankfurt, Germany Private Spaces london London, United Kingdom Private Spaces montreal Montreal, Canada Private Spaces mumbai Mumbai, India Private Spaces oregon Oregon, United States Private Spaces singapore Singapore Private Spaces sydney Sydney, Australia Private Spaces tokyo Tokyo, Japan Private Spaces virginia Virginia, United States Private Spaces”
Read 2026-09-05 · official docs
When these numbers change, hear about it. Sources are re-checked monthly; a repricing goes out as a short note.
Documented by only one.
These criteria are published by one provider and not the other. An absence here means we have not found a source, not that the feature is missing.
Questions this comparison answers.
Should I choose Google Cloud Run or Heroku?
Pick Google Cloud Run if A container you already build, that should cost nothing when nobody is using it. Scales to zero by default and back up on request volume, with a 60-minute ceiling per request that most request-driven platforms do not offer.
Pick Heroku if Teams that want to deploy by pushing to Git and let the platform handle the runtime, with Postgres, a scheduler and Docker deploys available on the same platform.