Railway vs Fly.io: You're Billed for Two Different Things

Most comparisons of these two platforms end up as a list of features neither of them competes on. The difference that actually shows up on your invoice is simpler and stranger:

Railway bills you for what your application consumes. Fly.io bills you for what you provisioned. Both describe themselves as usage-based, and both are telling the truth — they just mean different things by “usage.”

Get that backwards and you’ll pick the expensive one for your workload. Here’s how each model behaves, with the rates both companies publish.

The two billing models

Railway’s pricing page leads with it: “Say goodbye to overprovisioning and optimizing box sizes. Railway only charges you for what your app uses.” You don’t choose an instance size. You deploy, and Railway meters the CPU and memory your service actually holds, per second.

Fly.io works the other way. You pick a Machine size — shared-cpu-1x with 512MB, performance-2x with 4GB — and you’re billed for that shape for as long as the Machine is running, busy or not. Its docs are refreshingly blunt about the philosophy: “Plans get complicated, so we just charge based on usage. Pick and choose which pieces you need for your application; that’s all you’ll see on your invoice.”

Note the second structural difference hiding in that quote: Fly has no plan tiers at all. Railway has four.

Railway’s Pro tier is $20/month per workspace with unlimited seats included — not per seat, which several comparison sites still get wrong.

The rates

Railway, at continuous use:

Fly.io, quoting its Amsterdam example — and this matters, because Fly’s prices carry a regional markup, so your region may cost more:

Additional RAM runs about $5 per GB per 30 days. Volumes are $0.15/GB/month provisioned, matching Railway. Snapshots are $0.08/GB/month with the first 10GB free.

Egress is where Fly is structurally cheaper: $0.02/GB in North America and Europe against Railway’s flat $0.05/GB. But Fly’s rate is geographic — $0.04/GB in Asia-Pacific and South America, and $0.12/GB in Africa and India, six times its own NA/EU rate. Serve a lot of traffic to those regions and the cheap-egress advantage inverts.

Fly also has small line items Railway folds in: dedicated IPv4 at $2/month, wildcard SSL at $1/month (the first 10 single-hostname certificates are free).

Which is cheaper depends entirely on shape

Take a full dedicated core. Railway at 1 vCPU + 2GB RAM is $20 + $20 = $40/month. Fly’s like-for-like equivalent, performance-1x with 2GB, is $35.17. Comparable, edge to Fly.

But that comparison quietly assumes you need a dedicated core, and most small web services don’t — they spend their lives waiting on I/O. Fly is the only one of the two that sells you the cheap alternative: shared-cpu-1x with the same 2GB is $10.70, roughly a quarter of Railway’s figure. Railway has no equivalent tier, because its rate is a flat $20 per vCPU whether you need a whole core or a tenth of one.

So if shared CPU is adequate for your workload, Fly wins on price and it isn’t close. The rest of this comparison is about the cases where it isn’t adequate — or where the metering matters more than the rate.

Now take a small web app that idles most of the day — the common case. It averages, say, a tenth of a core and 400MB. Railway meters that honestly: roughly $2 of CPU and $4 of RAM, about $6/month, and Hobby’s $5 credit absorbs most of it. On Fly you’d still be paying for the Machine shape you provisioned, whether that’s $1.94 or $5.70.

That’s the whole ballgame. Railway is cheaper when your app’s average consumption sits well below its peak, because you never buy the peak. Fly is cheaper when your app genuinely uses what it holds, because you’re not paying Railway’s premium for the metering.

The trap is provisioning on Fly the way you’d size a VPS — picking a comfortable box “just in case.” On Fly that headroom is billed. On Railway it’s free until you use it.

Scale to zero: both do it, differently

Both platforms let you stop paying for an idle service, and the mechanics differ in ways that decide whether it’s usable for you.

Fly stops Machines when the app is idle, via auto_stop_machines, and you “don’t pay for their CPU and RAM” while stopped or suspended. You’ll still pay a small amount for the stopped Machine’s root filesystem — $0.15 per GB for 30 days. Fly Proxy restarts the Machine on an incoming request, and a suspended Machine resumes faster than a stopped one.

Railway calls it Serverless. A service sleeps once “no packets are sent from the service for over 10 minutes,” and wakes on traffic from the internet or from another service on the project’s private network.

Two caveats that comparison posts skip, both straight from the vendors’ own documentation.

Railway’s wake can fail the first request. Its docs state plainly that “the first request sent to a slept service may return a 502 Bad Gateway response.” If you put a slept Railway service behind anything that treats a 502 as an outage — a health check, a webhook sender that doesn’t retry, an uptime monitor — you need to know that before you enable it, not after.

Fly’s wake trigger is the proxy, which means HTTP. Autostart is driven by Fly Proxy responding to incoming requests. That’s a clean fit for a web service and an awkward one for a background worker with no inbound HTTP, which has nothing to wake it and needs a different mechanism. Railway’s trigger is broader — private-network traffic from a sibling service counts.

And a WebSocket service defeats both. A long-lived connection with a heartbeat means packets never stop flowing, so Railway’s 10-minute idle timer never fires and Fly’s Machine never looks idle. You pay continuously on either platform. If that’s your workload, ignore scale-to-zero entirely and compare the flat running costs above — where Fly’s cheap shared-cpu tiers and 30+ regions both start to matter.

Geography is the clearest win on the board

Railway runs four regions, all on its second-generation Metal hardware: US West (California), US East (Virginia), EU West (Amsterdam), and Southeast Asia (Singapore).

Fly runs 30+, spanning North America, Europe, Asia-Pacific, South America and Africa.

For most solo projects four regions is plenty — put it near your users and move on. But if you have users in Australia, India, Brazil or Africa and latency is part of your product, this isn’t a close call, and no amount of Railway’s better dashboard compensates for the physical distance. Long-lived connections feel this most acutely, which is why the WebSocket case above tends to land on Fly.

Both are chasing agents now, and it shows

Something worth flagging, because it’s recent enough that most comparisons still describe these products as they were.

Fly.io’s homepage no longer leads with app deployment at all. It reads “Computers for agents” — “Sandboxes aren’t enough. Give your agent a real computer and get back to building” — with “Start with Sprites” as the primary call to action.

Railway has moved the same direction but kept deployment in front. Its homepage reads “Ship software peacefully — with the all-in-one intelligent cloud provider,” with Deploy as the primary button and Agents sitting beside it as the secondary.

Read those two pages side by side and the strategic split is obvious: Fly is repositioning around agent workloads; Railway is adding them to a deployment platform. If you’re deploying a conventional web app, Railway’s homepage is still aimed at you and Fly’s no longer is — which tells you something about where each roadmap is pointed, even though both still do the job.

For agent workloads specifically, the billing models bite differently again. A long-running agent loop that spends most of its time waiting on model responses holds memory while using almost no CPU — which is close to the ideal case for Railway’s metering and close to the worst case for paying for a provisioned Fly Machine. A burst of parallel sandboxes that run hard and exit is the reverse.

The verdict

Pick Railway if you want the shortest path from repository to running service, your app’s average load sits well below its peak, and four regions cover your users. The metered model means you never pay for headroom, the dashboard is the better one, and $5/month on Hobby genuinely covers a small project. This is the default recommendation for solo developers and small teams shipping quickly.

Check Railway pricing → · Read our Railway review

Pick Fly.io if geography is part of your product, you run long-lived connections, or you want a real micro-VM with persistent volumes rather than a managed abstraction. 30+ regions, cheaper NA/EU egress, and no plan tier to pay before you start. The trade is that you size your own Machines and pay for that decision.

Read our Fly.io review

Pick neither if the workload is simply always on and predictable. Both platforms charge a premium for elasticity you won’t use. A flat VPS at $12–15/month gives you more RAM than either will for the money — the same conclusion we reached in Railway vs a VPS for n8n, and the reason self-hosting with Coolify on a cheap VPS keeps winning on pure cost.

How we picked

Rates come from each vendor’s published pricing read in August 2026: Railway’s per-second CPU, memory, volume and egress rates converted to monthly at continuous use, and Fly.io’s Machine pricing as published in its resource pricing documentation. Fly’s figures are its Amsterdam example — the docs are explicit that regional markups apply, so price your own region rather than assuming these carry.

Scale-to-zero behaviour, the 502 caveat, wake triggers and region counts are quoted from Railway’s and Fly.io’s own documentation, not from third-party summaries. That distinction mattered here: several sites still list Railway’s Pro plan as per-seat, and one widely-cited page miscalculated Railway’s vCPU rate by two orders of magnitude.

What we did not do: we have not deployed the same three applications to both platforms and reconciled a month of invoices, and no cost model substitutes for that. The cost comparisons above are arithmetic on published rates applied to stated assumptions about consumption — your app’s actual average CPU and memory are the variables that decide the outcome, and only your workload knows them. Nor have we measured cold-start latency ourselves; Fly’s documentation describes suspended Machines as resuming faster than stopped ones but publishes no figure, and we’d rather cite no number than someone else’s.

To get real numbers: deploy to Railway’s free trial ($5 in credits, 30 days, no card) and watch the metered usage graph for a week, which tells you your actual consumption. Then price the equivalent Fly Machine shape against it. That comparison takes an afternoon and beats any published estimate, including this one.

The Railway link above is an affiliate link. Fly.io does not run a programme we participate in, which is worth knowing when you read the verdict — we earn nothing from recommending it, and it still wins the sections where it wins.

FAQ

Is Railway or Fly.io cheaper?

Neither, universally. Railway is cheaper for apps whose average consumption sits well below their peak, because it meters actual usage rather than a provisioned size. Fly is cheaper for apps that genuinely use what they hold, and for small always-on services where a shared-cpu-1x Machine at $1.94–10.70/month undercuts anything Railway will meter.

Does Railway scale to zero?

Yes, via its Serverless setting. A service sleeps after 10 minutes without outbound packets and wakes on traffic. The catch is documented by Railway itself: the first request to a slept service may return a 502 Bad Gateway, so don’t enable it behind health checks or webhook senders that won’t retry.

Does Fly.io scale to zero?

Yes, with auto_stop_machines, and you stop paying for CPU and RAM while a Machine is stopped or suspended — though you still pay about $0.15 per GB of root filesystem per 30 days. Restart is triggered by Fly Proxy on an incoming request, which works well for HTTP services and less well for background workers with no inbound traffic.

How many regions does Railway have?

Four, all on Metal hardware: US West (California), US East (Virginia), EU West (Amsterdam) and Southeast Asia (Singapore). Fly.io runs 30+ regions, which is the single largest functional gap between the two platforms.

Is Railway Pro $20 per seat?

No — it’s $20 per month per workspace, with seats unlimited and included, plus $20 of usage credit. A number of comparison sites still describe it as per-seat, which materially overstates the cost for a team.

Which is better for WebSockets?

Fly, generally. Long-lived connections prevent either platform’s scale-to-zero from engaging, so you pay continuously on both — at which point Fly’s cheaper small Machines and 30+ regions decide it, since connection latency is geographic.

Can I run AI agents on either?

Both now market to it, and Fly leads its homepage with “Computers for agents” while Railway keeps deployment primary. For agents that idle on memory while waiting on model responses, Railway’s metering fits well. For bursty parallel sandboxes that run hard and exit, Fly’s provisioned Machines fit better.