How to Host a Next.js App: Every Option, Compared

The Next.js docs list four routes, which are a Node.js server, a Docker container, a static export and platform adapters, but in practice you meet six, because the platform route splits three ways and the Node route splits in two.

• A managed platform that builds and runs your repository on every push.
• A PaaS or container platform where you pick the instance size.
• A Docker container on a server you rent.
• A Node process behind nginx on that same kind of server.
• A static export, served as plain files.
• Serverless on a big cloud provider.

They differ on one question above all others: does anything have to run when a person asks for a page? If so, you need a server, and the static route is closed to you.

Two notes on that table. "Tested" means Vercel runs the Next.js compatibility suite, while the docs say other platforms have their own integrations that the Next.js team has not verified, so check each one against the feature you need. And a plain server gets everything, although ISR and image optimisation are only zero-config on one instance, which comes up again below.

You connect a Git repository, and the platform builds each commit and serves it. Vercel is the reference here, since it is a verified adapter. Its Pro plan is $20 a month, which includes one deploying seat and $20 of usage credit. Each extra deploying seat is another $20. Netlify, AWS Amplify and Firebase App Hosting are the usual alternatives. The Next.js docs list all three as offering their own Next.js support rather than the verified adapter.

This is the least work, and for most small teams it is the usual way to host a Next.js app. The cost is that your bill now has several meters, and the database is usually somebody else's product. If you are weighing Vercel in particular, our Vercel cost breakdown has the sums by team size.

These platforms run your app as a Node process or a container, and you choose how big it is. Render, Railway, DigitalOcean, Fly.io and Google Cloud Run all have deploy templates in the Next.js docs. Heroku-style platforms work the same way, and it is the shape most people mean when they search how to deploy a Next.js app to Heroku or DigitalOcean.

Render's Starter instance is $7 a month for 512 MB of RAM, and a Hobby workspace has no monthly fee. You get every Next.js feature because it is a real Node server, and what you give up is the tuned integration of a platform built around one framework.

Helm7 sits in this group, and it is one entry among several. It runs your app as a container next to Postgres, auth, storage, jobs and domains on one bill, from $12 a month on the Builder plan. That price is a minimum spend that usage draws down. It is newer than the others, runs only in Falkenstein and Helsinki, and runs each environment as one instance. The deploy guide covers the same options without the sales pitch.

This is the cheapest fixed cost. Hetzner's CAX11 has 2 vCPUs, 4 GB of RAM and 40 GB of NVMe. It costs €5.99 a month excluding VAT, from 15 June 2026, with 20 TB of traffic included in its EU locations. Hetzner showed the CAX line as currently unavailable on the page we read, so check stock before you plan around it.

You install Docker, build an image and run it, and if you set output to standalone and use a three-stage Dockerfile, the image stays small. The full recipe is in how to dockerize a Next.js app. There is one trap, which is that the ISR cache lives on disk inside the container, so without a mounted volume it starts empty after every deploy.

Everything else is yours, from updates and backups to firewall rules, certificates, and the call when it falls over at night.

No container is needed. This is how to host a Next.js app the plain way, on any Linux machine with Node installed, and it is also how to deploy a Next.js app to nginx.

1. 1BuildRun npm run build. It writes the .next directory.
2. 2StartRun npm run start, which runs next start on port 3000. Set PORT to change it.
3. 3Keep it aliveUse systemd or pm2 so it restarts after a crash or a reboot.
4. 4Put nginx in frontThe Next.js docs recommend a reverse proxy rather than exposing the server. It absorbs malformed requests, slow connections and payload abuse so Next.js can render.
5. 5Stop bufferingStreamed pages arrive all at once if nginx buffers them. The docs show Next.js sending an X-Accel-Buffering header set to no.

server {
  listen 80;
  server_name example.com;

  location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
  }
}

On one instance, ISR, image optimisation and Proxy all work with no setup. Run two instances and each keeps its own cache, so you need a shared cache handler. Self-hosting Next.js lists every setting.

Set output to export and next build writes plain HTML, CSS and JavaScript to an out folder, which any web server can host, whether that is nginx, Apache, an S3 bucket, or GitHub Pages, which has an official Next.js template. Shared cPanel hosting also serves files, so a static export is the safest way to deploy Next.js there, and if your host says it runs Node.js apps, that is a different case, so ask.

• No Incremental Static Regeneration, server actions, Proxy, Draft Mode or cookies.
• No rewrites, redirects or custom headers in next.config. Your web server does those now.
• Dynamic routes need generateStaticParams, and cannot set dynamicParams to true.
• Route handlers that read the request do not work. GET handlers must be marked force-static.
• next/image needs a custom loader, because the default one optimises at request time.

Server Components are fine, since they run once at build time, and a blog, a docs site or a brochure site often qualifies, but an app with logins does not.

AWS Amplify, Firebase App Hosting and Google Cloud Run all run Next.js without a server you patch, and you pay per request and per unit of compute, with no fixed fee to quote here, so price it in the provider's calculator with your own traffic.

The catch is the cache. The Next.js self-hosting guide says that on ephemeral compute, local disk is often non-persistent or unavailable, so the ISR cache is short-lived and per instance. That does not break the app, but it means pages rebuild more often than you might expect, and each rebuild costs compute.

Before you host a Next.js app anywhere, test three things, because each one fails quietly. The app must answer on the production address. Streamed pages must arrive in pieces rather than all at once. And a redeploy must not lose anything a user was waiting on.