Vercel vs Railway vs Fly.io for SaaS Hosting in 2026

Three platforms, three incompatible ideas about what a running application even is. Vercel treats it as a request that ends. Railway keeps a container alive and bills you for the privilege, while Fly.io hands you a virtual machine and asks which continent you would like it on.

Choose wrong and you rarely get an outage. You get an invoice you cannot explain, or a feature you now have to rebuild by hand. Most vercel vs railway vs fly writeups stop at "Vercel is expensive, Fly is for global apps" without opening a single pricing page. I opened all of them, because this site runs on Vercel and I have shipped two production SaaS products solo, so the question has always been narrow and financial rather than philosophical. Which meter is going to surprise me, and at what traffic level does it fire?

What Are You Actually Buying From Each One?

You are buying three different meters: Vercel meters requests and data transfer, Railway meters reserved container resources per minute, and Fly.io meters running virtual machines by the second.

That distinction decides your bill far more than any feature grid does. A platform's meter is its opinion about what is scarce, and the three of them disagree completely.

| | Vercel | Railway | Fly.io | |---|---|---|---| | Billing unit | Active CPU, provisioned memory, invocations | GB RAM and vCPU per minute | Machine-seconds on a CPU/RAM preset | | Subscription | $20 per seat per month | $5 Hobby, $20 Pro per month | None; support from $29/month | | Cost while idle | Nothing between requests | RAM keeps billing | Rootfs storage only | | Egress | First 1 TB free, then $0.15–$0.35/GB | $0.05/GB from the first GB | $0.02/GB in NA and EU, from the first GB | | Region model | One compute region plus a global CDN | One region per service | Many regions behind Anycast | | What you operate | Close to nothing | Container settings | Machines, volumes, scaling rules |

Rates from Vercel's regional pricing, Railway's pricing reference and Fly.io's pricing docs, all read in July 2026.

Read the idle row twice. On Railway, RAM costs $10 per GB per month whether a single request arrives or none do, so a 512 MB service that nobody visits still consumes $5 of your $5 Hobby credit. On Fly.io a stopped Machine costs only its root filesystem, billed at $0.15 per GB per 30 days. On Vercel an untouched project costs nothing at all, which is the genuine benefit of the serverless model and the reason it stays attractive long after the pricing complaints start.

Where Does the Bill Actually Break?

The bill breaks at egress, and the crossover sits near 1.5 TB per month, below which Vercel's included terabyte beats both Railway and Fly.io outright on transfer cost.

Here is the arithmetic, using each platform's cheapest published rate. Vercel gives you the first 1 TB of Fast Data Transfer per billing cycle and then charges at least $0.15/GB. Railway charges $0.05/GB starting from the first gigabyte. Fly.io charges $0.02/GB for North America and Europe, also from the first gigabyte.

| Monthly egress | Vercel | Railway | Fly.io (NA/EU) | |---|---|---|---| | 500 GB | $0 | $25 | $10 | | 1 TB | $0 | $50 | $20 | | 1.5 TB | $75 | $75 | $30 | | 3 TB | $300 | $150 | $60 | | 5 TB | $600 | $250 | $100 |

Solve it properly and Vercel stops being the cheap option against Railway at exactly 1,500 GB, and against Fly.io at roughly 1,154 GB. That is my arithmetic on published list prices, not a vendor claim, and your real number moves with region since Vercel's overage runs as high as $0.35/GB while Fly.io charges $0.12/GB into Africa and India.

You have felt the shape of this even if you have never seen the math. Traffic doubles. The invoice quadruples. The mechanism is a free allowance ending, not a platform betraying you.

Egress is also not the only cliff. Vercel meters Edge Requests separately, giving you 10 million per cycle and then charging $2.00 to $3.20 per million, which is the line that punishes a chatty single-page app long before bandwidth does. Builds bill at $0.0035 per CPU-minute, and Vercel's pricing docs are explicit that duration rounds up to the whole minute before being multiplied by the machine's CPU count. A two-minute-and-thirty-four-second build on an eight-CPU machine bills as three minutes across eight CPUs. Merge fifteen pull requests on a Tuesday and that rounding is no longer a rounding error.

Vercel Bills Memory While Your Code Waits

This is the part of Vercel's model almost nobody reads carefully, and for an API-shaped SaaS it matters more than the seat price.

Under fluid compute, Vercel splits function cost into Active CPU and Provisioned Memory. Active CPU covers only the milliseconds your code actually runs, and Vercel's own documentation states that CPU billing pauses while a request waits on I/O. Excellent. Then the same page states that Provisioned Memory bills for the entire instance lifetime, continues during I/O, and keeps running until the last in-flight request finishes.

Sit with what that means for a typical SaaS endpoint. Your handler validates a token, calls Stripe, waits on Firestore, waits on a webhook confirmation, and returns. Active CPU might be 90 milliseconds of that. Wall clock might be 1.4 seconds. You pay CPU for the 90 milliseconds and memory for all 1,400.

Vercel's documented example makes the ratio concrete: a 4 GB function in São Paulo with 4 seconds of active CPU inside a 10-second lifetime costs $0.0002456 in CPU and $0.0002033 in memory. Memory is 45% of that invocation. Now shrink the CPU work and keep the waiting, which is exactly what an integration-heavy product does, and memory becomes the dominant term while the marketing story about only paying for compute you use quietly stops applying.

Actually, that overstates the villainy slightly. Fluid compute lets one instance serve concurrent requests, so a busy endpoint amortises that memory across many callers, and it is a real improvement over per-request billing. The trap is the low-traffic integration endpoint: little concurrency to amortise against, long waits on third-party APIs, memory metered for every second of them.

What Leaving Vercel Actually Costs You

Read Vercel's meter list rather than its feature list. It bills separately for ISR Writes and Reads, Image Optimization transformations and cache operations, Edge Request CPU Duration and Runtime Cache operations. Those are not billing quirks. They are products, and Railway and Fly.io do not charge you for them because they do not provide them.

That is the actual migration cost, and it is paid in engineering rather than dollars. Railway and Fly.io run your container, which means what Next.js gives you through Vercel's managed infrastructure becomes yours to reproduce:

1. Rebuild image optimization. Vercel transforms and caches on demand. In a container you either run sharp yourself with your own cache, or move images to an object store behind a CDN.
2. Rebuild ISR. Incremental regeneration needs shared cache storage that survives restarts and stays consistent across instances. Self-hosted Next.js supports a custom cache handler; wiring it to Redis is a real afternoon, plus ongoing operations.
3. Replace edge middleware. Middleware that ran at the CDN boundary now runs in your single-region container, which changes both latency and what running code at the edge was buying you.
4. Own preview environments. Railway offers PR environments and Fly.io can be scripted into them, but Vercel's per-commit preview URLs with framework detection are a genuinely hard act to follow.
5. Own the CDN. Static assets need a cache in front of them or your container serves every byte from one region, which is how a platform that charges less per gigabyte still feels slower.

None of that is exotic work. All of it is work, and if you are trading $200 a month of Vercel overage for six engineering days plus permanent operational surface, run that trade honestly before you migrate.

Fly.io's Autostop Trap

One configuration mistake on Fly.io produces failures no dashboard explains. Enable auto_stop_machines while auto_start_machines is off and your Machines stop as designed, then never come back, and requests fail against a healthy-looking app. Fly's docs also note that min_machines_running applies only to your primary region. Every other region can scale to zero without warning you.

Which One Should You Pick for a SaaS?

Pick by the single constraint you can already name today, working down this list and stopping at the first line that describes your product honestly.

1. Next.js app, under 1 TB of egress, small team. Stay on Vercel. The included terabyte, the managed ISR and the preview URLs are worth more than the seat price at this size, and this is also the answer for most of the SaaS MVP stacks I recommend.
2. Long-running processes, queues, websockets or a database you want beside your app. Railway. Containers with per-minute resource billing fit workloads that stay alive, and the platform has been pushing hardware forward rather than prices: Railway Metal Gen 2, announced 2 June 2026, brought 96-core machines and five times the compute capacity with no price increase, after Metal had already cut egress from $0.10/GB to $0.05/GB and disk from $0.25/GB to $0.15/GB.
3. Users on multiple continents and a latency budget you can measure. Fly.io. Per-second billing and real multi-region placement are genuinely cheaper for global traffic, provided you accept that scaling rules and Machine lifecycles are now yours to operate.
4. Heavy egress at any scale. Fly.io on price, Railway on price plus convenience. At 3 TB per month the gap between Vercel and Fly.io is $240, which is most of a seat-heavy Vercel bill.
5. You cannot answer any of the above yet. Vercel, and revisit at 1 TB. Being wrong for four months costs you very little; a premature migration costs weeks.

Worth saying plainly: none of this decides your architecture. Callidus OS, the multi-tenant clinic platform I built solo in roughly ten weeks between 14 February 2026 and late April 2026, never touched this comparison, because Firebase came with the stack and hosting followed. Same story on BookBed, the Flutter and Firebase booking product I run. Hosting choice matters most when your framework has not already made it for you.

Do This Before You Migrate Anything

Open your current provider's usage tab and write down three numbers: gigabytes of egress last month, requests last month, and whichever line item is largest. Then price only those three against the tables above.

If the answer is under a few hundred dollars a year, you are optimising the wrong thing and your afternoon belongs to your product instead. If the answer is thousands, you now know which single meter to escape, which is a much easier problem than choosing a platform. Which line on your last invoice actually surprised you?