The best Next.js hosting platforms in 2026

Next.js is not one thing to host. A marketing site that pre-renders everything at build time and a dashboard that runs middleware, server actions, streaming, and ISR revalidation are different deployment problems that happen to share a package.json. Most hosting comparisons ignore that and rank platforms on price and DX, which is how teams end up on a platform that runs their app fine for four months and then can't do the one thing they need.

So: start with what your app uses, then pick. I build PandaStack, which is one of the options below — I'll say where it fits and where it doesn't.

First, figure out which Next.js you're running

Open your repo and check for these. The answers determine your shortlist more than any pricing page does.

• Do you have a middleware.ts? It runs on every matched request, and platforms implement it very differently — some in an edge runtime with a restricted API surface, some as ordinary Node.
• Do you use ISR or on-demand revalidation? That needs a shared, persistent cache. On a platform that runs several stateless instances with local disk, revalidation is per-instance and your users see different content depending on where they land.
• Do you use the Image component with remote images? Optimization is a CPU-and-cache workload someone has to run. Some platforms bill it separately; some don't have it and you fall back to unoptimized images.
• Do you stream (loading.tsx, Suspense, server actions with progressive responses)? That needs a runtime that supports streaming responses end to end, including through whatever proxy sits in front.
• Do you write to the filesystem, run a background job, or hold a WebSocket? If yes, you are not a serverless app, whatever your framework says.

The four categories

1. Vercel — the reference implementation

Next.js features land on Vercel first because the team that builds the framework builds the platform. If you use the full surface — middleware, ISR, image optimization, server actions, partial prerendering — Vercel is the only place where all of it works exactly as documented on day one. That is a real, defensible reason to pay for it.

The complaints are equally real and mostly about the pricing model rather than the product: bandwidth and function invocations are metered, and a traffic spike or a badly-behaved crawler turns into a bill. If your app is content-heavy and popular, price it out at your real numbers before you commit.

2. Static and edge hosts — Netlify, Cloudflare, Amplify

These run Next.js through an adapter that maps the framework onto the platform's own primitives. For a mostly-static site with a few API routes, they're excellent and often cheaper. The adapter is where you should look before committing: check its open issues for the specific features you use. Adapter lag is a real cost — a Next.js release lands and your platform supports it a version or two later.

Cloudflare specifically is worth its own note. Running Next.js on Workers means your server code runs in a V8 isolate, not Node, so native modules and anything using the full Node API need checking. It is very fast and very cheap when it fits, and a rewrite when it doesn't.

3. Container PaaS — Render, Railway, Fly.io, Northflank, Koyeb

You build the standalone output and run `node server.js` in a container. Everything works because it's just Next.js running as a Node server: middleware is Node, ISR writes to a real disk, streaming works, and you can hold a WebSocket in the same process. There's no adapter to lag.

What you give up: the CDN and image optimization are now your problem — usually solved by putting Cloudflare in front — and multi-instance ISR still needs a shared cache handler pointed at Redis or similar. Also budget for build memory. A Next.js production build on a large app routinely wants more than 2 GB, and the default plan on several platforms is smaller than that.

4. MicroVM platforms — Fly Machines, PandaStack

Same shape as a container PaaS, except your app gets a hardware-isolated virtual machine with its own kernel. This is my category, so weight accordingly. It matters in two situations: when the isolation boundary is a requirement you have to defend — you're running per-customer code, or a security review asks what stops one tenant reading another's memory — and when your app itself creates environments at runtime, because on a snapshot-restore substrate a fresh machine costs about 179ms at p50 rather than a provisioning step.

For a plain marketing site, this is an odd choice and I'd point you at the static hosts.

What a no-Dockerfile Next.js deploy looks like

Any platform with build detection should take a Next.js repo and figure it out. The part worth controlling explicitly is the Node version — pin it in the repo rather than in a dashboard setting, so it travels with the code and the same version builds locally and in CI.

# Pin the runtime in the repo, not in a UI dropdown
echo "22.11.0" > .nvmrc

# Deploy from git — install, build, and start are detected
pandastack apps create --name storefront \
  --git-url https://github.com/acme/storefront \
  --git-branch main

# Override only if your repo is unusual (monorepo, custom output)
pandastack apps create --name storefront \
  --git-url https://github.com/acme/storefront \
  --build-cmd 'npm ci && npm run build' \
  --start-cmd 'node .next/standalone/server.js'

Six checks before you commit

1. Deploy your real app, not create-next-app. Detection surprises live in monorepos, private registries, and postinstall scripts.
2. Hit a page that uses ISR, wait for revalidation, and reload several times. If content flips back and forth, you have per-instance caching.
3. Check the build memory ceiling. A production build that OOMs is the most common first-day failure, and the error message is usually just 'killed'.
4. Test middleware against the runtime it actually runs in. Node-only APIs in an edge runtime fail at request time, not build time.
5. Measure a cold request after your longest idle period if the platform sleeps apps, and check whether uptime monitors reset the idle timer.
6. Price your real traffic, including bots. Metered bandwidth and metered image optimization are where surprise bills come from.

The short version

Using the full Next.js feature surface and not price-sensitive: Vercel, and don't overthink it. Mostly static with a few routes: Netlify or Cloudflare, cheaply. Long-running work, WebSockets, or predictable pricing: a container PaaS with the standalone output and a CDN in front. Hard isolation requirements or an app that spawns environments per user: microVM platforms, mine included. And if you're on Vercel, it works, and the bill is fine — staying is a real answer.