SassTurf
BlogBuilding
Building

Vercel vs Railway vs Fly.io: Where to Host — and When to Switch

Vercel, Railway, or Fly.io? A hands-on comparison for indie SaaS — costs, developer experience, and the exact point where you should migrate your API.

Shubham Soni
Shubham Soni
Jul 17, 2026 · 9 min read
Table of contents7 sections
  1. 01The Night My Function Count Went to the Moon
  2. 02Vercel: The Frontend King (and the Serverless Trap)
  3. 03Railway: The Backend Box That Won’t Surprise You
  4. 04Fly.io: Global Edge for When You Actually Scale
  5. 05Cost at Scale: What Each One Actually Bills You
  6. 06When to Switch (The Exact Triggers)
  7. 07The Bottom Line

The Night My Function Count Went to the Moon

It was late 2024. I was building a small uptime-monitoring tool — one of those “check a URL every five minutes and email me if it’s down” ideas that every engineer builds and never launches. I did what felt natural: I put everything on Vercel. Frontend, API, and the little polling job that did the actual checking. One repo, one git push, done. Beautiful.

Then I opened the usage dashboard a week later.

The polling function — the one that ran every five minutes, per monitored endpoint — had racked up a genuinely absurd number of invocations. I had maybe three test endpoints and it was already a scary-looking line on the graph. So I did the napkin math for what a thousand users each watching twenty endpoints would look like. Twenty thousand invocations every five minutes. Forever. On a serverless platform that bills per invocation and per compute-second.

That’s the moment it clicked: Vercel isn’t a server. It’s a serverless front door. And I’d been trying to run a boiler room behind a front door.

This post is the thing I wish someone had told me that night. Three hosts — Vercel, Railway, and Fly.io — that everyone lumps together as “places to deploy,” but that actually solve three completely different problems. Here’s what each is genuinely good at, what it costs when you’re not looking, and the exact point where you should pack up and move.


Vercel: The Frontend King (and the Serverless Trap)

Let me be clear: I love Vercel. If your app is Next.js or Astro, start here and don’t overthink it. They own Next.js, so deployment is genuine magic — push to GitHub, get a preview URL per branch, ship. For frontend and light backend, nothing is smoother. I’ve said this before and I’ll say it again: Vercel is the undisputed king for the frontend.

But there are two things nobody warns you about, and both cost money.

The Hobby plan is non-commercial. Period. Vercel’s free Hobby tier is glorious — 100 GB of fast data transfer, a million function invocations, and a few hours of active CPU a month. But per their own terms, it’s for personal, non-commercial use only. The day your project charges money, you’re supposed to be on Pro at $20 per seat a month. Plenty of founders run a real business on Hobby and don’t find out they’re offside until traffic spikes. (I ranted about this exact gotcha in what it really costs to run a SaaS.)

The serverless bill scales with your worst function. Pro gives you $20 of usage credit baked in, and Vercel has moved to “fluid compute,” which bills active CPU — you pay for CPU-milliseconds, not wall-clock time, so the I/O waiting is basically free. That’s a real improvement and it cuts bills hard for I/O-heavy work. But the model doesn’t save you from a runaway function. A single endpoint getting hammered — a webhook, a cron job, a polling loop like my uptime monitor — can quietly eat most of your usage. Move that one function off Vercel and you can slash the function part of your bill dramatically. The lightweight stuff? Leave it there. It’s fine. (That’s the whole reason I started putting edge functions on Bunny.)

My take: Vercel for your frontend and your light, spiky API routes. The moment something needs to run all the time, it belongs somewhere else. And for the love of God, set a billing cap.


Railway: The Backend Box That Won’t Surprise You

Railway is where my uptime monitor’s polling job should have lived from day one.

Here’s the mental model that fixed everything for me: Vercel rents you function calls; Railway rents you a machine. When you need a tiny instance humming 24/7 for a predictable fee — a worker, a cron loop, a WebSocket server, an API that gets steady traffic instead of spiky traffic — Railway shows up like a fairy godmother. You get a real container that can hammer twenty thousand API calls without a per-invocation bill waiting to ambush you.

The pricing is honest in a way I appreciate:

  • A one-time $5 trial credit, no credit card, to kick the tires. It expires in 30 days.
  • The Hobby plan is $5/month and includes $5 of usage. If your resource usage for the month lands at or under $5, you pay just the $5 subscription. Go over, and you pay the delta — per-second billing on CPU, memory, and disk, plus bandwidth. No idle fees, no overprovisioning penalty.
  • Pro is $20/month per seat when you need production limits, longer log retention, and teammates.

So a small always-on service genuinely does cost about five bucks a month, and it won’t spike on you because a webhook went viral. The dashboard is the other reason I keep coming back — it’s so clean that non-technical friends have deployed things on it without me on the call.

The sleeper feature is one-click templates. Railway has a library of open-source, self-hostable projects — PostHog, Metabase, NocoDB — where you pick one and it’s live in seconds. Need a Postgres or Redis next to your app? Add it from the same dashboard. For backend workloads, it’s my second home. For frontend, though? I never use it. Keep that on Vercel.


Fly.io: Global Edge for When You Actually Scale

Fly.io is the nerdy cousin of the other two, and I mean that as a compliment. It’s a command-line-first platform that feels like a magic wand if you live in the terminal. Install the CLI, type fly launch, and your app — packaged as a container, so a Docker mindset helps — gets scattered across the globe. Multi-region deployment out of the box. That’s the headline: your app running physically close to users in Frankfurt, Singapore, and São Paulo at the same time, not stuck in one AWS-style datacenter. If you ever loved the old Heroku CLI vibe but want something built in this decade, Fly is your soulmate.

But here’s the update most blog posts get wrong — including some of my own older ones — so read this twice:

Fly.io no longer has a free tier. They sunset it in October 2024. New signups get a short trial and then must add a card. It’s fully pay-as-you-go now, billed per second.

If you were counting on those three free shared VMs, that era is over unless you’re a grandfathered legacy account. The upside: pay-as-you-go is genuinely cheap if you know what you’re doing. The smallest shared-cpu-1x machine with 256 MB of RAM runs about $2 a month, and paid support (which you don’t need early on) starts at $29/month. They offer managed Postgres too, though I only ever use Fly for compute and keep my database on Neon.

My take: I love Fly.io, but don’t start here. It rewards you when you’re ready to geek out on multi-region setups and squeeze real performance for global users. Reach for it when “my users are all over the world and latency matters” becomes an actual, revenue-affecting problem — not on day one.


Cost at Scale: What Each One Actually Bills You

Numbers, because vague comparisons are useless. All current as of mid-2026 — and prices on these platforms move constantly, so treat this as the shape, not gospel:

VercelRailwayFly.io
Free / trialHobby free, non-commercial only$5 credit, 30 days, no cardShort trial, then card — no free tier
Entry paid planPro, $20 / seat / moHobby, $5 / mo (incl. $5 usage)Pay-as-you-go, no fixed plan
How it billsPer invocation + active CPU (fluid compute)Per-second CPU / RAM / disk + bandwidthPer-second machine usage
Small always-on serviceGets expensive fast~$5 / mo, predictable~$2 / mo per tiny VM
Surprise-bill riskHigh if a function runs hotLow — usage caps near your planLow-to-medium, watch machine count
Best atFrontend + spiky API24/7 backend, cron, workersMulti-region, global latency

The pattern is the same one I keep hammering across the whole deployment tier list: Vercel’s cost is unpredictable because it scales with your spikiest endpoint; Railway’s and Fly’s are predictable because you’re renting a machine, not renting requests. When you have zero revenue, predictable-and-boring beats magical-and-scary every single time.

One thing I’ll say for all three: none of them is the Render trap, where the price feels disproportionate to what you get. And none is AWS, where the learning curve is the real bill. If you’re weighing a fourth option, look at Koyeb for a flat-fee always-on instance, or DigitalOcean when you graduate to needing real infrastructure — but honestly, these three cover 95% of indie SaaS.


When to Switch (The Exact Triggers)

This is the part everyone actually wants, so no fluff. Here’s the migration path I’d follow, and the specific signals that tell you it’s time to move.

Stage 1 — Everything on Vercel. You’re pre-launch or barely launched. Frontend, API routes, the lot. It’s free (Hobby) or $20 (Pro if you’re commercial). Do not optimize anything yet. Ship, get feedback, iterate.

Switch trigger → Vercel to Railway: the day you open your usage graph and one workload is eating everything. A cron job. A polling loop. A webhook handler getting slammed. A background worker that never sleeps. That’s the signal. You don’t move your whole app — you move that one always-on piece to a $5 Railway box and call it from your Vercel frontend. Frontend on Vercel, heavy lifting on Railway. This single change has saved me more money than any other deployment decision.

Switch trigger → Railway to Fly.io: when latency becomes a real complaint from real, paying users on other continents. If your customers are all in one region, Railway is plenty. But when someone in Sydney is waiting on a server in Virginia and it’s costing you conversions, Fly’s multi-region edge earns its keep. This is a good problem — it means you have users in Sydney.

When to reach past all three: the day you genuinely outgrow them — dedicated infra, managed databases with point-in-time recovery, load balancers — Northflank or DigitalOcean are the grown-up next step. But you’ll know. You won’t have to ask.

Notice what’s not a trigger: “I read a thread that said X is faster.” “A YouTuber uses Y.” Your host should change because your product forced it to, not because of platform FOMO. I wasted weeks on exactly that kind of thing. Don’t.


The Bottom Line

Deployment should be the 1% of your work that quietly hums in the background while you pour your energy into the thing that actually decides whether you make it — getting users. These three tools aren’t rivals fighting over the same job; they’re three different tools for three different moments in your product’s life. Start on Vercel because shipping fast matters more than saving five dollars. Move your always-on workloads to Railway the day one of them tries to bankrupt you. Reach for Fly.io when the whole planet is your customer.

I learned this the expensive way, staring at a function-invocation graph for a product nobody was using. You get to learn it the cheap way — by reading this and setting a billing cap before you push. (For the bigger picture of surviving on a shoestring, the broke solopreneur’s survival guide ties the whole stack together.)

This is the Broken Engineer Guide. I over-engineer everything, fail at business, and hand you the receipts so you don’t have to pay for the lesson twice. Now go set that billing cap.

Shubham Soni
Written by
Shubham Soni

A decade building, launching, and occasionally breaking SaaS products. I write SassTurf to share what actually moved the needle — free, no fluff.

Keep reading

Building

LangChain Alternatives That Actually Earn Their Place (2026)

9 min read
Building

Kubernetes Deployment: A Founder's Guide to the One File You'd Actually Write (2026)

9 min read
Email Marketing

Out of Office Email Templates That Don't Sound Like a Robot (2026)

8 min read

Enjoyed this? Get the next one.

One useful SaaS essay in your inbox each week. No fluff, unsubscribe anytime.