Next.js Hosting: What the App Actually Needs From a Host, by Rendering Mode

Next.js hosting is not one question. A Next.js app runs in one of four ways, static export, a Node server, a Docker container, or a serverless adapter, and each one asks something different of the host. A static export needs a CDN and nothing else. A Node server needs a persistent process, memory and a disk the ISR cache can live on. Serverless needs a platform that understands the framework’s cache. Work out which of the four you have, and the hosting choice mostly makes itself.

The pages that rank for this term are vendor pages, each explaining why its own platform is the natural home for the framework. The framework’s own deployment docs are more useful and say the quiet part: Next.js can be deployed as a Node.js server, a Docker container, a static export, or adapted to other platforms, and it runs on any provider that supports Node. This post takes that list and asks, for each mode, what the host has to provide and what it costs.

Table of contents

• Four ways a Next.js app can run
• Static export: any host with a CDN
• Node server: the honest default
• Docker: the same server, portable
• Serverless and edge: fast until it is not
• What it costs, honestly
• How this fits the rest of the stack
• FAQ

Four ways a Next.js app can run

The build output decides everything. Before comparing hosts, check next.config.js and the way the app is started, because that tells you which of these four you are hosting.

• Static export. output: 'export' turns the build into a folder of HTML, CSS and JS. No server runs. Any static host serves it.
• Node server. next build then next start. A long-running process on a port, behind a reverse proxy. This is the default, and the one most self-hosting guides assume.
• Docker container. The same Node server, packaged with output: 'standalone' into an image. Runs anywhere a container runs.
• Serverless or edge adapter. Pages and routes split into functions that a platform invokes per request. This is what the framework’s own hosting company does, and it is the mode most tied to a specific vendor.

The same codebase can usually move between modes, but not for free. Server components, middleware, image optimisation and incremental static regeneration behave differently in each, and a feature that works in one mode can be silently unavailable in another. The Next.js server-side rendering post covers what SSR actually does; this one is about where it runs.

Static export: any host with a CDN

If the site has no per-request server work, no personalised pages, no API routes that must live in the same app, and no images that need optimising on the fly, export it. The build produces plain files, the host serves them from a CDN, and there is no process to keep alive, no memory to size and no cold start.

The trade is a list of features you give up: dynamic routes need generateStaticParams so every path is known at build time, middleware does not run, ISR does not exist because nothing regenerates, API routes are gone, and the default image loader is replaced by an unoptimised one or a third-party loader. Rewrites and redirects move from next.config.js into the host’s configuration.

What the host needs to provide is small: object storage, a CDN in front, a custom domain with a certificate, and a way to set headers and redirects. A marketing site, a documentation site or a blog fits this mode and should not be paying for a server. The deploy a Next.js static site for free walkthrough is the export mode end to end.

Node server: the honest default

Most Next.js apps with any dynamic behaviour end up here. next start runs a Node process that renders pages on request, serves the static assets, runs API routes and regenerates ISR pages in the background. The host has to give it three things the static mode never needed.

1. A persistent process. Something has to restart it when it crashes and keep it alive between requests. A process manager on a VPS, a container runtime on a platform, either is fine; a shared PHP host is not.
2. Memory. A small Next.js server idles at a couple of hundred megabytes and climbs with route count and concurrent renders. 512MB is tight, 1GB is comfortable for a small app, and a build can need more than the runtime does.
3. A disk for the cache. ISR and the fetch cache write to .next/cache on local disk. With one instance and a persistent disk this works on its own. Run two instances, or restart onto fresh ephemeral storage, and each copy has its own cache, which is how a page shows two different versions depending on which instance answered.

The framework’s self-hosting guide addresses the third point with a custom cacheHandler backed by shared storage, and it recommends a reverse proxy in front of the process rather than exposing it directly. Both are host-level concerns. The deploy Next.js to a VPS post walks through doing all of this by hand; the reason to use a platform is not having to.

Docker: the same server, portable

The Docker mode is the Node server mode with the environment pinned. output: 'standalone' makes the build emit a minimal server.js and only the node_modules it actually needs, so a multi-stage image lands around 150MB instead of a gigabyte. The container exposes port 3000, sets HOSTNAME=0.0.0.0, and behaves identically on a laptop, a VPS and a platform.

The host requirements are the same as the Node server: a process, memory, and something to do about the ISR cache if there is more than one instance. What changes is that the build is reproducible and the runtime is yours to choose, which matters when the platform’s default Node version is not the one the app was tested on. The Docker and Next.js post has the Dockerfile and the environment-variable trap that catches most first attempts.

Serverless and edge: fast until it is not

Serverless hosting splits the app into functions and invokes them per request. There is no process to keep alive, scale-to-zero is automatic, and for a low-traffic site the cost can be close to nothing. The framework was designed with this mode in mind and the developer experience on the platforms that support it is genuinely good.

The limits show up in a predictable order. Cold starts add latency to the first request after idle. Function size and execution-time caps constrain what a route can do. Anything long-lived, a websocket, a background job, a queue consumer, does not fit the model at all and ends up on a separate service. And ISR in serverless requires the platform to provide its own cache backend, which is exactly the vendor coupling the adapter mode implies. A team that later wants to leave discovers the app is shaped around the platform.

For a marketing site with a few dynamic routes, serverless is a fine answer. For an application with a database, sessions, uploads and jobs, the Node server or Docker mode is easier to reason about, because the whole thing is one process you can run locally in exactly the form it runs in production.

What it costs, honestly

The cost of Next.js hosting is driven by memory in the server modes and by bandwidth in the static mode. A static export on a host that includes a generous bandwidth allowance is effectively free until the site is popular. A Node server or container is a monthly plan sized by RAM, with the ISR cache and the build step as the two things that push a small plan into a bigger one.

On RunxBuild a Next.js app is a web service deployed from a GitHub repository: the build runs on push, the build log shows the compile, and the live route, environment variables, custom domain and runtime logs are in the dashboard. The Dev plan at $4 a month (0.3 vCPU, 624MB) runs a small server-rendered site; BasicMini at $13 (1 vCPU, 1GB) is the comfortable size for an app with a database behind it, and autoscaling can move the service between a floor and a ceiling plan on CPU. Rollback to the previous deploy is one click, which is the feature you want the first time a build passes and the app does not. A static export deploys as a static site instead, with 120GB of bandwidth included and $0.10 per GB after. The backend for Next.js post covers what sits behind the app once it needs a database.

How this fits the rest of the stack

Pick the mode first, then the host. Static export wants a CDN and nothing else; the Node server and Docker modes want a persistent process, a gigabyte of memory and a plan for the ISR cache; serverless wants a platform that speaks the framework’s dialect and a tolerance for staying there. The RunxBuild hosting calculator puts the service, the database and the bandwidth on one page so the monthly figure for a Next.js app is a number rather than a guess. Ship the first version on the smallest plan that builds, and let autoscaling argue for the bigger one.

Useful related references:

• Next.js Server-Side Rendering and What It Costs to Host
• Deploy Next.js to a VPS: The Full Path, and What It Costs You Afterwards
• The Next.js Backend: Route Handlers, Server Actions, and Where They Run
• Next.js services on RunxBuild

FAQ

Do I need Vercel to host Next.js?

No. Next.js runs as a Node.js server on any provider that supports Node, as a Docker container anywhere containers run, or as a static export on any static host. The framework’s own docs list all of these. The features most tied to one vendor are the serverless adapter and its ISR cache backend; the Node and Docker modes are portable.

Can I host Next.js on shared hosting?

Only as a static export. Shared PHP-style hosting cannot keep a Node process running, so the server, Docker and serverless modes are out. If the site can be exported to plain files it will serve fine from any host that serves HTML; if it needs SSR, API routes or ISR, it needs a host that runs Node.

Does static export support dynamic routes?

Yes, as long as every path is known at build time. Dynamic segments need generateStaticParams to enumerate the values, and the build produces one HTML file per path. Routes that depend on request data, cookies, headers or search params cannot be exported and need the server mode.

How much RAM does a Next.js server need?

A small app idles around 200 to 300MB and grows with route count and concurrent renders. 512MB works for a tiny site but leaves little headroom for the ISR cache and traffic spikes; 1GB is the comfortable size for a small production app. The build step often needs more memory than the running server, which is worth checking if builds fail on a small plan.

Why does ISR serve different versions on different requests?

Because each running instance keeps its own cache on local disk in .next/cache. With two instances behind a load balancer, one regenerates a page and the other keeps serving the old copy. The fix is a single instance with a persistent disk, or a shared cacheHandler backed by a store both instances can read.