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

You are choosing where a SaaS will run, or wondering whether your Vercel invoice means it is time to leave. Before you read a single comparison, open your last invoice and write down three numbers: gigabytes of egress, requests, and your largest line item. Those three figures decide this comparison far more than any feature grid.

Vercel, Railway and Fly.io hold three different ideas of what a running application is. Vercel treats it as a request that ends. Railway keeps your services running and bills the resources they use. Fly.io hands you a virtual machine and asks which region you want it in. Choose wrong and you rarely get an outage. You get an invoice you cannot explain, or a feature you must rebuild by hand.

What are you actually buying from Vercel, Railway and Fly.io?

You are buying three different meters: Vercel meters requests, data transfer and function resources, Railway meters CPU, memory and disk per second, and Fly.io meters running Machines per second plus outbound transfer. The meter is the platform's opinion about what is scarce.

Rates come from Vercel's pricing page, Railway's pricing page and Fly.io's pricing docs, all read on 30 September 2026. The Pro and Hobby plans on Railway include $20 and $5 of usage credit respectively, and Vercel Pro includes a $20 monthly credit, so the sticker plan price is smaller than it looks and the usage line is bigger.

Limits matter too. Railway's pricing page lists per-service resource ceilings that grow with the plan: 1 vCPU and 0.5 GB on Free, 48 vCPU and 48 GB on Hobby, and 1,000 vCPU and 1 TB on Pro. A typical early SaaS will not touch them, but check the ceiling before you plan a memory-hungry worker.

What does an idle app cost on each platform?

Vercel's docs say that after all requests complete the instance is paused and no CPU or memory charges apply until the next invocation, which is the practical benefit of the serverless model. Fly.io bills a stopped Machine only for its root filesystem, at $0.15 per GB for 30 days. Railway bills the CPU, memory and disk your services use, so an always-on service that holds memory keeps costing you with no traffic. That last sentence is my inference from the per-second model, not a Railway statement.

At what traffic does Vercel stop being the cheapest?

On egress alone, Vercel Pro stops being cheapest at about 1.15 TB a month against Fly.io and 1.5 TB against Railway, because its included terabyte is beaten once you pay list price on the excess.

Here is the arithmetic on list prices, treating 1 TB as 1,000 GB and ignoring plan fees and the regional rate differences that may apply to your setup.

Solving it: Vercel's cost is $0.15 times everything above 1,000 GB, so it matches Railway's $0.05 per GB at 1,500 GB and Fly.io's $0.02 per GB at roughly 1,154 GB. This is my arithmetic, not a vendor claim. Fly.io's own docs list higher outbound rates elsewhere: $0.04/GB in Asia Pacific, Oceania and South America, and $0.12/GB in Africa and India. If your users sit there, the gap narrows.

Consider a hypothetical B2B SaaS that serves 2 TB of egress a month. On list prices that is $150 of overage on Vercel Pro, $100 on Railway and $40 on Fly.io in North America or Europe. The spread is real but small next to one engineer's week, which is why egress alone rarely justifies a migration until the terabytes climb.

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

Egress is not the only cliff. Vercel Pro lists 10M CDN requests and then $2 per million, which can hit a chatty single-page app before bandwidth does.

Why does Vercel bill memory while your code waits?

Because fluid compute splits the bill in two. Vercel's fluid compute pricing docs say Active CPU is billed only while your code runs, pausing during I/O, while Provisioned Memory is billed for the whole instance lifetime, including during I/O, until the last in-flight request completes.

Consider a hypothetical endpoint that validates a token, calls Stripe, waits on a database and returns. If 90 milliseconds of the 1.4-second wall clock is CPU, you pay CPU for 90 and memory for all 1,400. Vercel's documented example is a 4 GB function in São Paulo with 4 seconds of active CPU in a 10-second lifetime: about $0.00025 for CPU and $0.00020 for memory. Shrink the CPU work and keep the waiting, and memory becomes the larger term.

The docs also say one instance can handle multiple requests with optimised concurrency, so a busy endpoint spreads that memory across callers. The low-traffic integration endpoint with long third-party waits gets the least benefit. That conclusion is my inference from the billing rules.

What does leaving Vercel actually cost you?

Less than the usual warnings suggest, and in different places. Railway and Fly.io run your container, so what Next.js gives you through Vercel's managed infrastructure becomes something you configure. The Next.js self-hosting guide covers most of it.

1. Check image optimisation. According to the guide, next/image works self-hosted with zero configuration under next start. Watch memory on glibc-based Linux, where the docs say extra configuration may be needed.
2. Plan a shared cache for ISR. The Next.js cache is stored on each instance's local disk by default. With several instances or ephemeral compute you need a custom cache handler, and the guide points to a Redis example.
3. Keep request logic in the container. The guide says Proxy works self-hosted with zero configuration under next start, but it now runs in your region rather than at an edge network, which changes latency and what running code at the edge was buying you.
4. Add version-skew protection yourself. Set a deploymentId so rolling deployments do not serve clients mismatched assets.
5. Put a CDN or reverse proxy in front. The guide recommends a reverse proxy, and static assets served from one region will feel slower even at a lower per-gigabyte price.

None of this is exotic. All of it is work, so if you are trading a few hundred dollars of overage for several engineering days plus permanent operations, run that trade honestly before migrating. Preview deployments are one Vercel feature this post does not price, so list which of your own workflows depend on them before you move.

What is Fly.io's autostop trap?

Enabling one autostop setting without its partner produces failures no dashboard explains. Fly's autostop and autostart docs recommend setting auto_stop_machines and auto_start_machines so they are both enabled or both disabled. They also say min_machines_running only keeps Machines running in your primary region and has no effect on other regions, so those regions can scale down to nothing.

Which one should you pick for a SaaS?

Pick by the one constraint you can name today, working down this list and stopping at the first line that describes your product. These are my recommendations, not benchmarks.

1. Next.js app, under 1 TB of egress, small team. Stay on Vercel. The included terabyte and managed platform are worth more than the plan price at this size, and this fits most of the SaaS MVP stacks I recommend.
2. Long-running processes, queues, websockets or a database beside your app. Railway. Per-second resource billing suits services that stay alive.
3. Users on several continents and a latency budget you can measure. Fly.io, provided you accept that Machine lifecycles and scaling rules become yours to operate.
4. Heavy egress at any scale. Fly.io on price, Railway on price plus convenience. At 3 TB the list-price gap between Vercel and Fly.io is $240.
5. You cannot answer any of the above yet. Vercel, and revisit at 1 TB. Being wrong for a few months costs little; a premature migration costs weeks.

Your framework may also decide for you. A product like BookBed is built with Flutter and Firebase rather than Next.js, so this comparison applies to whatever web layer you add around it rather than to the core.

Now pull your last invoice and price only your three numbers against the tables above. Which line item would move most if you switched?