Every Next.js deployment guide compares features. This one compares experience — from three real client projects, each on a different platform, each running in production for 6+ months.
The projects
Project A (Vercel): Portfolio site with blog. 60 static pages, MDX content, contact form via Server Action. ~3,000 visits/month.
Project B (Fly.io): B2B SaaS dashboard. Server-rendered pages, WebSocket connections, Postgres database on the same platform. ~800 daily active users.
Project C (Railway): E-commerce storefront. ISR for product pages, Stripe checkout, image-heavy catalog. ~15,000 visits/month.
Cost comparison
| Vercel | Fly.io | Railway | |
|---|---|---|---|
| Monthly cost | $20 (Pro plan) | $15–25 (usage-based) | $10–20 (usage-based) |
| What you get | Hosting + edge network + analytics | 2 VMs (256MB) + builder | 1 service + builder |
| Database | Separate (Neon: $0–19) | Included (Fly Postgres) | Separate (Railway Postgres: $5+) |
| Bandwidth | 1TB included | Pay per GB ($0.02) | 100GB included |
| Build minutes | 6,000/month | Unlimited (your VM) | 500 included |
Real monthly costs after 6 months:
- Project A (Vercel): $20/month flat. Never exceeded Pro plan limits.
- Project B (Fly.io): $22/month average. Spiked to $35 one month when a traffic burst scaled up machines.
- Project C (Railway): $16/month average. Predictable — Railway's usage-based pricing is simpler than Fly's.
Deployment experience
Vercel
Deploy time: 45–90 seconds for a full build. Incremental builds (ISR) are instant — just the changed pages.
The good: Zero configuration for Next.js (they built it). Git push → deployed. Preview deployments for every PR. Edge Functions, Image Optimization, Analytics — all built in. The developer experience is unmatched.
The limitation: Vercel is opinionated. You run Next.js their way. Serverless functions have execution time limits (10s on Pro, 60s on Enterprise). WebSocket support requires workarounds. Long-running background jobs don't fit the model.
For Project A (static portfolio), Vercel is perfect. For Project B (WebSocket dashboard), it would have been a poor fit.
Fly.io
Deploy time: 2–4 minutes. Builds a Docker image and deploys to VMs globally.
The good: Full control. You run a real Node.js server, which means WebSockets work natively, background jobs run in the same process, and there are no serverless execution limits. Multi-region deployment is straightforward — your app runs on VMs in the regions you choose.
The limitation: You manage infrastructure. VM sizing, health checks, auto-scaling config, Postgres backups — it's all on you. The fly.toml config has a learning curve. When something breaks at 2 AM, you're debugging infrastructure, not just code.
For Project B (SaaS dashboard), the control was worth the operational overhead. WebSocket connections stayed alive without workarounds, and the background job processor ran in the same deployment.
Railway
Deploy time: 90–120 seconds. Detects the framework, builds, deploys.
The good: Simpler than Fly, more flexible than Vercel. You get a real server (not serverless) without managing VMs. Deployment from Git is automatic. The dashboard is clean and shows logs, metrics, and costs in one place. Postgres is one click away.
The limitation: Single region only (US or EU, you pick). No multi-region deployment without running multiple services. Auto-scaling is basic compared to Fly. The platform is younger — fewer docs, smaller community.
For Project C (e-commerce), Railway's simplicity was right. Single region (EU) was fine for a European audience, and the ISR/Stripe setup worked without modification.
Cold starts
This matters for serverless platforms (Vercel) and scaled-to-zero configs (Fly, Railway).
- Vercel: Serverless functions cold start in 200–500ms. Static pages and edge functions: no cold start.
- Fly.io: If you scale to zero, VM boot takes 3–5 seconds. With
min_machines_running = 1, no cold start (but you pay for the idle VM). - Railway: No cold starts — the service runs continuously. But you pay for idle time.
For the portfolio (Project A), Vercel's serverless cold starts were imperceptible — the contact form Server Action took 300ms on cold start, fine for a form submission.
For the SaaS dashboard (Project B), cold starts were unacceptable. Users expect the dashboard to load instantly. We kept one Fly VM running at all times.
The decision framework
Choose Vercel when:
- Your app is mostly static or ISR
- You want zero DevOps
- You're on the Pro plan budget ($20/month)
- You don't need WebSockets or long-running processes
- Performance and DX matter more than infrastructure control
Choose Fly.io when:
- You need WebSockets, background jobs, or long-running processes
- You want multi-region deployment
- You're comfortable with infrastructure management
- Your app needs a co-located database (Fly Postgres)
Choose Railway when:
- You want something between Vercel's simplicity and Fly's control
- Single-region deployment is fine
- You want predictable pricing without serverless complexity
- You're deploying a Next.js app with a database
What I default to
For client projects, my default is Vercel. Not because it's always the best fit — because it removes an entire category of decisions. No Docker files, no VM sizing, no scaling config. The client gets a deployed app with preview URLs and automatic deployments from day one.
I reach for Fly.io when the project needs things Vercel can't do: WebSockets, background processing, or specific infrastructure requirements. The trade is operational complexity for capability.
Railway is my recommendation when clients want to self-manage after handoff. The dashboard is intuitive, the pricing is transparent, and there's less vendor-specific knowledge needed to maintain the deployment.
Deploying a Next.js app and not sure which platform fits? Let's talk — I help pick the right infrastructure so you're not migrating in month 6.