Fly.io vs Google Cloud Run
SEPT 2026 auditA comparison of Fly.io and Google Cloud Run built from values read directly from each provider's own documentation, with the source recorded against every figure.
The short answer
Choose Fly.io if…
Workloads that ship as Docker images and need placement in particular regions. Billing is purely usage-based with no plan tiers, which suits spiky or region-pinned traffic better than a flat monthly fee.
Editorial · Palash Bagchi · approved
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
Consider something else if…
- Fly.io: You want a predictable flat bill rather than charges that track the resources provisioned for each app.
- Google Cloud Run: You need a process that stays running between requests, or a disk that survives a deploy.
5 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.
Fly.io 0
Google Cloud Run 0
At a glance.
| Criterion | Fly.io | Google Cloud Run |
|---|---|---|
| Pricing | ||
| Pricing model | Usage-based, no compute plan tiers | 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. |
| Deployment | ||
| Git deployment | Limited | Supported |
| Docker deployment | Supported | Supported |
| Infrastructure | ||
| Persistent processes | Supported | Limited — instance-based billing keeps CPU allocated |
| Edge network | Limited | Limited — deploy per region, add a load balancer |
| Scales to zero | Supported | Supported |
| Autoscaling | Limited | Supported |
| Regions | 18 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. |
Where they differ.
Pricing model
- Fly.io
- Usage-based, no compute plan tiers
- 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.
Sources (2) →Sources ↓
- Fly.io pricing ↗
“Plans get complicated, so we just charge based on usage. Billing is based on the resources provisioned for your apps, pro-rated for the time they are provisioned.”
Read 2026-09-05 · official docs
- 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
Git deployment
- Fly.io
- Limited
- Google Cloud Run
- Supported
Sources (2) →Sources ↓
- Continuous deployment with GitHub Actions — Fly Docs ↗
“push to the repository's master branch. If your repository uses a default branch other than master, such as main, then you should change that here. [...] jobs: deploy: name: Deploy app runs-on: ubuntu”
Read 2026-09-07 · official docs
- Continuously deploy from a repository — Cloud Run — Google Cloud Documentation ↗
“If you have source code or functions in a Git repository and want to automate builds and set up continuous deployments from a repository, you can use either Cloud Build or Developer Connect in the Cloud Run console.”
Read 2026-09-09 · official docs
Persistent processes
- Fly.io
- Supported
- Google Cloud Run
- Limited — instance-based billing keeps CPU allocated
Sources (2) →Sources ↓
- Billing — Fly Docs ↗
“stopped or suspended Machines are billed based on their root file system (rootfs) usage per second (the time they spend in the `stopped` or `suspended` state) by $0.15 per GB per month”
Read 2026-09-07 · official docs
- 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
Autoscaling
- Fly.io
- Limited
- Google Cloud Run
- Supported
Sources (2) →Sources ↓
- Autoscaling · Fly Docs ↗
“Autoscaling adjusts the number of running or created Fly Machines dynamically. We support two forms of autoscaling: Autostop/autostart Machines and Metrics-based autoscaling. [...] Fly Proxy autostop/autostart starts and stops Machines based on load; Machines are never created or deleted. [...] The metrics-based autoscaler scales your application based on any metric. You deploy the autoscaler as an app in your organization.”
Read 2026-09-05 · official docs
- 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
Regions
18 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.
Sources (2) →Sources ↓
- Fly.io regions ↗
“You can host your apps in any of the following regions — including ams (Amsterdam, Netherlands), nrt (Tokyo, Japan) and syd (Sydney, Australia).”
Read 2026-09-05 · official docs
- 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
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 Fly.io or Google Cloud Run?
Pick Fly.io if Workloads that ship as Docker images and need placement in particular regions. Billing is purely usage-based with no plan tiers, which suits spiky or region-pinned traffic better than a flat monthly fee.
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.