Most "best Next.js hosting" lists rank platforms as if one wins for everyone. That framing is wrong. Next.js is not one workload — it is a spectrum from a fully static marketing site to a stateful full-stack app with a database, background jobs, and per-request server rendering. The right host depends entirely on which Next.js features your app leans on. This guide sorts the real options by the decision that actually matters, so you pick once and don't re-platform in six months.
The one question that decides your host
Before comparing platforms, answer this: what does your Next.js app do at request time?
- Mostly static — marketing pages, docs, a blog. Output is static HTML plus a little client JavaScript. Almost any host serves this well and cheaply.
- Static + incremental (ISR) — mostly static, but pages revalidate on a schedule or on-demand. Now the host must run the Next.js server or a compatible adapter, not just serve files.
- Edge / middleware heavy — you rewrite, redirect, geolocate, or personalize in middleware.ts and want it close to users. This narrows the field sharply.
- Full-stack + stateful — Route Handlers hitting a database, auth sessions, queues, websockets, cron. Now you are really hosting a Node server, and colocation with your database matters more than CDN edge tricks.
Your answer maps almost directly to a host. Here is the map.
The options, sorted by fit
| Host | Next.js support | Best for | Free tier | Main watch-out |
|---|---|---|---|---|
| Vercel | First-class, zero-config (built by the Next.js team) | ISR, edge middleware, image optimization; teams that want no infra work | Yes (Hobby) | Usage-based function + bandwidth pricing can climb fast at scale |
| Cloudflare (Workers/Pages) | Via the OpenNext adapter | Global edge, high traffic, bandwidth-sensitive apps | Yes (generous) | Workers runtime — not every Node API/feature is 1:1; you adopt the adapter |
| Netlify | Strong, via its Next runtime | SSR/ISR sites that want great DX without Vercel lock-in | Yes | Some ISR/edge behaviors differ from Vercel; verify the features you rely on |
| Railway | Runs next start as a Node service | Full-stack apps that want DB, app, and jobs in one project | Trial credit | You operate it as a server: no automatic global CDN/ISR — you own caching |
| Render | Runs next start as a web service | Predictable flat-rate full-stack hosting | Yes (with spin-down) | Same as Railway: a Node server, not an edge platform |
| Fly.io | Node server in a container, multi-region | Latency-sensitive full-stack apps deployed near users | Trial | More operational surface; you manage machines and regions |
| Self-host (VPS/Docker) | next start behind a reverse proxy | Cheapest at scale, full control | N/A | You own uptime, TLS, scaling, and caching yourself |
Reading the table: three real recommendations
You want zero infra work and use the whole feature set
If you use ISR, middleware.ts, next/image, and streaming Server Components, start on Vercel. It is the reference implementation: every feature ships there first and works with no configuration. The honest tradeoff is cost — Vercel bills on function execution and bandwidth, so a viral page or an image-heavy site can produce a bill that surprises you. For many teams the time saved is worth it; for high-traffic or image-heavy sites, price it against the next option first.
Bandwidth or global latency is your constraint
Look at Cloudflare through the OpenNext adapter. You get Cloudflare's edge network and its low egress costs — which matter most exactly when Vercel gets expensive. The cost is adoption friction: you build against the Workers runtime via an adapter, and must confirm the specific features you use are supported before you port.
Your app is full-stack and stateful
A real database, auth, background jobs — the edge-CDN model is the wrong fit. Reach for a PaaS that runs your Next.js app as a plain Node server next to its database: Railway or Render for simplicity, Fly.io when per-region latency matters. You give up automatic ISR and edge distribution, but gain one place to run the app, the database, and the workers, with pricing you can predict.
The trap to avoid
The common mistake is choosing an edge platform for a stateful app because a listicle called it "the best," then fighting the platform for months because your database round-trips are slow from the edge and your background jobs have nowhere to run. The inverse also happens: hosting a purely static marketing site on a full PaaS and paying for an always-on server you don't need. Match the host to the workload and both problems disappear.
How to choose in 60 seconds
- Mostly static? Deploy free on Vercel, Netlify, or Cloudflare Pages and stop reading.
- ISR or edge middleware, and want it effortless? Vercel. If bandwidth cost is the worry, Cloudflare via OpenNext.
- Database, auth, and background work? Railway or Render; Fly.io if latency-critical; self-host if cost-at-scale dominates and you have the ops appetite.
- Still unsure? Start on the free tier that matches your answer, ship, and measure the real bill and latency before optimizing. Re-platforming a small app is cheap; over-choosing on day one is the expensive mistake.
A note on pricing
Every platform above changes its prices and free-tier limits regularly, so treat any specific dollar figure you read — here or elsewhere — as a starting point to verify on the provider's own pricing page, not gospel. What is stable is the shape of each model: Vercel and Cloudflare bill by usage (functions, bandwidth), while Railway, Render, and Fly bill closer to a running instance. That shape — usage-based versus instance-based — predicts your bill better than any headline number, because it tells you what happens when traffic spikes.
FAQ
Is Vercel the only good option because it made Next.js?
No. Vercel is the smoothest and most fully-featured, but Netlify and Cloudflare both run Next.js well, and for stateful apps a PaaS is often the better fit. “Made by the same team” buys you zero-config and feature-day-one support, not a monopoly on quality.
Can I self-host Next.js?
Yes. next build && next start runs anywhere Node runs. Behind a reverse proxy on a VPS it is the cheapest option at scale, at the cost of owning uptime, TLS, and caching yourself.
Will I get locked in?
Standard Next.js features are portable across hosts because they are part of the framework. Lock-in risk comes from a platform's proprietary add-ons (a specific KV store, edge config, or image service). Keep those at the edges of your app and staying portable is easy.