Best hosting for Next.js: managed platforms vs a VPS

Next.js is a React framework that can build two very different kinds of output, and your hosting choice follows directly from which one you ship. A fully static site is just files a CDN serves; a server-rendered app is a long-running Node.js process that has to stay alive. Confuse the two and you either overpay for a static site or deploy a dynamic app somewhere that cannot run it. This guide explains the rendering modes, then compares the honest trade-off between a managed platform and a self-hosted VPS.

First, decide how your app renders

The single most important question is whether your app is static or needs a server at request time. Next.js supports both, and they have completely different hosting requirements.

• Static export - with output: 'export', Next.js builds plain HTML, CSS and JavaScript at build time. There is no server: the result is a folder of files that any static host or CDN can serve. Cheap and simple, but it rules out anything that runs per request.
• Server-rendered (SSR / ISR / API routes) - server-side rendering, incremental static regeneration, route handlers and middleware all execute code when a request comes in. That needs a Node.js runtime running your build and staying alive to answer requests.

You can check what your project uses: if it relies on getServerSideProps, server components that fetch at request time, API routes under app/api or pages/api, or ISR revalidation, it is a server app. If every page can be generated ahead of time, a static export is on the table.

Option 1: a static export on any static host

If your app is fully static, hosting is trivial and cheap. Set the output to export, build, and deploy the generated folder to a static host or CDN:

// next.config.js
module.exports = {
  output: 'export',
};

# build produces a static 'out/' folder
npm run build

# 'out/' now contains HTML, CSS and JS you can upload anywhere

The out/ directory is just files, so it works on any static host with a global CDN and free HTTPS. This is the same model covered in our guide on static website hosting. The catch is that a static export cannot do server-side rendering, ISR, image optimization on the fly, or API routes - those features simply do not exist without a server.

Option 2: a managed platform

Managed platforms build your app from a Git push and run the server for you, handling scaling, TLS and the build pipeline. Vercel is the most notable here because it is the company that develops Next.js, so its platform tracks new framework features closely. Other platforms such as Netlify also support Next.js through their own adapters.

The appeal is real: you git push and the platform runs the whole flow, so there is no server to patch and no reverse proxy to configure. The trade-off is control and cost. You work within the platform's build and runtime model, and usage-based pricing can climb as traffic, function execution and bandwidth grow. For a small project the free or low tiers are generous; for a busy app the bill scales with usage, which is exactly the point at which self-hosting starts to look attractive.

Option 3: self-hosting on a VPS

Because a server-rendered Next.js app is ultimately a Node.js process, you can run it yourself on a VPS - the same way you would host any Node app. This is the most flexible and usually the cheapest option at scale, in exchange for doing the operations work yourself. The build produces a server you start with next start:

# on the server: install deps and build
npm ci
npm run build

# start the production server (defaults to port 3000)
npm run start

As with any long-running Node process, you should not run next start by hand in an SSH session. Use a process manager such as PM2 to keep it alive and restart it after a crash or reboot, and put a reverse proxy in front of it. This is the exact pattern from our guide on hosting a Node.js app:

# keep the Next.js server alive with PM2
pm2 start "npm run start" --name next-app
pm2 startup
pm2 save

Then point Nginx at the Node process so it terminates TLS and forwards public traffic to port 3000:

server {
  listen 80;
  server_name yourapp.com;

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

Add HTTPS with a free automated certificate (tools like Certbot make this a one-liner). For sizing the machine, the criteria are the same as any web app - memory first, then CPU - covered in our guide on choosing the best VPS for a web project. Providers focused on a strong resource-to-price ratio, such as Contabo or Hetzner, give you generous RAM and vCPU at a low monthly cost, which suits a Node build and runtime well.

How the options compare

Approach	Runs what	You manage	Best when
Static export	Files on a CDN (no server)	Just a build and upload	Every page can be pre-rendered
Managed platform	SSR, ISR, API routes	Just your code and env vars	You want to ship fast, low ops effort
VPS (self-hosted)	SSR, ISR, API routes	OS, Node, PM2, Nginx, TLS	You want control and predictable cost

How to decide

Start from how your app renders, not from a provider's marketing. If every page can be generated ahead of time, ship a static export and host it cheaply on a CDN. If you need SSR, ISR or API routes, you need a Node.js runtime - and then it comes down to a familiar trade-off: a managed platform is the fastest way to ship and the least operations work, while a VPS is cheaper at scale and gives you full control in exchange for running Node, a process manager, a reverse proxy and TLS yourself. Pick the smallest option that covers what your app actually needs, and move up only when scaling or operational overhead becomes the real bottleneck.