Fly.io's Fee Layers, Itemized: The Real Bill Behind the $2.02 Machine

Fly.io will sell you a virtual machine for about $2.02 a month. That number is real — Qovery's September 2026 PaaS comparison cites it, and it matches Fly's own per-second pricing for a shared-cpu-1x with 256 MB of RAM running around the clock. It is also, for almost any real app, roughly a fifth of the invoice.

The machine is just the bottom layer. Stacked on top of it are separately metered charges for IP addresses, bandwidth, storage, and certificates — each reasonable on its own, each discovered one line item at a time. So let's do the accounting up front, before a single paragraph of analysis. Here is what a small but realistic app — a web service, a background worker, a 10 GB volume, one dedicated IPv4, and 50 GB of egress in North America or Europe — actually costs on Fly.io in September 2026:

The headline was $2.02. The bill is $8.54 if you carefully run one of everything, and $10.56 if you accept the defaults — five times the number that got you in the door. Every row of that table is a layer worth understanding, because each one scales differently, surprises a different kind of migrator, and has its own crossover point where flat-rate owned hardware wins. Let's itemize them.

Layer by layer: where the other $8 comes from​

Compute: honest per-second billing with a quiet doubling. Fly bills Machines per second while running, and stopped Machines cost nothing for compute — Fly's own staff confirmed that stopped Machines incur no compute charge. The gotcha is not the meter, it's the default: fly launch provisions two Machines for high availability unless you opt out. Nothing about the $2.02 figure warns you that the default path doubles it to $4.04 before you've configured anything. Add the well-documented failure mode of orphan Machines accumulating across deploys — one May 2026 incident report describes a worker app silently growing to 16 Machines, half of them stopped but the running half all billing — and compute deserves a monthly fly machines list audit, not just trust.

IP addresses: $2 per app for the dedicated kind. Each dedicated IPv4 costs $2/month per app. Shared Anycast IPv4 and IPv6 are free, and many small HTTP apps can live on the shared address — but the moment you need a stable dedicated address (non-HTTP TCP, reputation-sensitive outbound, compliance), it's a flat $2 stapled to every app that needs one. Two public-facing apps means $4 before either serves a request.

Bandwidth: three tiers, one 6x cliff. Outbound transfer is $0.02/GB in North America and Europe, $0.04/GB across Asia-Pacific, Oceania, and South America, and $0.12/GB in Africa and India. Inbound is free. At 50 GB in Virginia, bandwidth is a $1 footnote; serve that same 50 GB from Johannesburg and it's $6 — triple the cost of the machine generating it. Region choice on Fly is a pricing decision wearing a latency costume.

Volumes: $0.15/GB-month, billed while stopped. This is the layer that breaks ex-Render/Railway intuition hardest. Fly's billing docs state it explicitly, and staff confirmed it years ago: you are charged for provisioned volume gigabytes even when the attached Machine is stopped or the volume is detached. Stop every Machine in an app over the holidays and the compute line drops to zero — but the 10 GB volume keeps billing its $1.50. Scale-to-zero saves compute; it never saves storage.

Certificates: free until they aren't. The first ten custom-domain certificates are free, and apps on *.fly.dev domains don't count against the quota at all. Past ten, each additional hostname cert costs $0.10/month. For a two-domain side project this row is permanently $0 — but if you're a SaaS vending per-customer custom domains, it's a meter that grows with your customer count, and one worth modeling before customer eleven.

The stateful upgrade: managed Postgres starts at $38. The moment SQLite-on-a-volume stops being enough, Fly's managed Postgres Basic plan starts at $38/month plus $0.28/GB of storage. That single line item is more than triple our entire example bill. Self-running Postgres on a shared-cpu-2x with a volume is dramatically cheaper — and dramatically more your problem at 3 AM. Either way, the database is where the "$2 hobby project" narrative ends.

One more piece of context: there is no permanent free tier to absorb any of this. Fly removed its free allowances in 2024; the old quotas (a few shared VMs, gigabytes of volume and bandwidth) survive only on grandfathered legacy accounts. New accounts get a short trial, then the meter runs from dollar zero.

The three line items that ambush ex-Render/Railway migrators​

Migrators don't arrive with blank expectations — they arrive with Render and Railway mental models, where connectivity is bundled into the instance price and stopping something mostly stops its bill. Three Fly layers violate those models specifically:

1. Per-app IPs: connectivity sold separately. On Render, a web service's public endpoint is part of the service price; there is no line item for "having an address." On Fly, the dedicated address is a $2/month SKU per app. The surprise isn't the amount — it's the ontology. Migrators budgeting "two services ≈ two instance prices" discover a third price they never had a row for, applied per app.

2. Stopped-volume billing: the bill that survives scale-to-zero. Both Render and Railway teach operators that stopped/suspended workloads cost little or nothing. Fly agrees — for compute. But storage is provisioned capacity, not consumed seconds, so a stopped app with a 40 GB volume still owes $6/month indefinitely. Teams that spin down staging environments to save money learn that only the compute half of staging was ever spinning down.

3. The HA default: the headline price, doubled silently. fly launch giving you two Machines is genuinely good reliability advice. It is also a 2x multiplier applied to the exact number — the $2.02 machine — that anchored your budget. The migrator who estimated "three services, roughly six bucks" meets a $12 compute line and assumes a billing error. It isn't; it's the default doing its job without saying the price out loud.

Sensitivity check: the same app at three traffic levels in three regions​

The itemized table above fixed two variables — 50 GB of egress, NA/EU region — that are precisely the variables a growing app can't fix. Here's the full bill (HA web pair, worker, 10 GB volume, one IPv4) across traffic levels and region tiers:

The base footprint without bandwidth is $9.56; everything above that is egress. In Virginia, growing from 10 GB to 500 GB roughly doubles the bill. In Mumbai or Johannesburg, the same growth multiplies it more than sixfold — bandwidth alone ($60) costs nearly ten times the machines producing it. Somewhere between 100 and 500 GB, depending on region, metered egress stops being a footnote and becomes the bill. That crossover is the number to carry into the next section.

The flat number: this whole footprint on one owned box​

Now the other side of the ledger. A Hetzner CX22 cloud VM — 2 shared vCPUs, 4 GB of RAM, 40 GB of SSD, 20 TB of included traffic — costs roughly €4/month including its IPv4 fee, about $5. That single flat number absorbs our entire example app several times over: both services, the volume, and 50 GB of egress would consume 0.25% of the included traffic allowance. The 500 GB "heavy" scenario from the table above? Still 2.5% of the allowance. The region cliff doesn't exist — there is no per-gigabyte meter at all.

And the flat number scales flatly. A dedicated AX41-NVMe — Ryzen 5, 64 GB of RAM, 2× 512 GB NVMe — runs about €39/month and would host dozens of footprints like this one without any line item changing. Compare that to the managed-Postgres upgrade path: on Fly, adding a managed database jumps the example bill from ~$11 to ~$50; on the dedicated box, Postgres is a container you run with RAM you already pay for.

Honesty requires the other direction too. The flat box gives up everything the meter is good at: per-second billing, scale-to-zero, Machines that boot near users on five continents, and not being the person who replaces the NVMe at 3 AM. Fly's anycast edge and instant global regions are genuinely hard to self-host — a single Falkenstein VM will never serve Sydney in 30 ms. If your workload is spiky, globally distributed, or sleeps most of the day behind auto-stop, the meter can beat the flat rate by a wide margin. The comparison above is for the most common small-app shape — always-on, one region, modest traffic — which is exactly where flat wins hardest.

When the meter wins and when the flat rate wins​

The rule that falls out of the tables is simple. Fly.io's meter wins when your workload looks like the thing per-second billing was invented for: bursty traffic, nights and weekends at zero behind auto-stop, users spread across regions where anycast earns its keep. Every hour a Machine sleeps is an hour the flat box charges anyway.

The flat rate wins when your workload looks like most small production apps: always on, in one region, with traffic that grows steadily past the ~100 GB point where egress starts outpacing compute. At that shape, $10–$20/month of metered layers collapses into ~$5 of flat capacity — and the gap widens with every gigabyte and every added service, because the flat number doesn't move.

Either way, budget from the itemized bill, not the headline. The $2.02 machine is real. It's just never the whole invoice.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with flat economics instead of per-layer meters. Star the repo on GitHub or deploy your first app today.