Next.js hosting: where an app should live and how it deploys

A Next.js app deploys as one of three things: a folder of static files, a single supervised Node process, or a container. The static export sits happily on any static host or CDN. Anything using server rendering, API routes or middleware needs a host that builds the repository, runs the production start command under supervision, and hands the process its environment variables. Vercel, the company behind the framework, is the default most people never question, and it is frequently the right answer. It stops being right when the app grows background workers, a colocated database, or a bill that needs a ceiling you can name in advance.

The shapes a Next.js app can take

The repository tells you which shape you have, and the shape picks the category of host.

If the config sets output: 'export', the build emits a folder of HTML, JS and CSS, and the framework's server features are switched off: no server rendering, no API routes, no middleware. The app is now a static site. Any competent static host or CDN serves it, deploys are file uploads, and the hosting conversation is essentially over.

If the app renders pages per request, or has an app/api or pages/api directory, a Node process has to run and keep running. This is the common case, because the interesting parts of most apps, auth, dashboards, reads from a database, need a server. The process model is simple: next build at deploy time, then next start running supervised, with all configuration arriving as environment variables at boot.

The container shape is a variation on that second shape. output: 'standalone' produces a minimal server bundle designed to be wrapped in an image and run anywhere images run. You buy full control of the runtime and pay for it in image maintenance and a build pipeline you own.

What the process shapes demand from a host

A host for the one-process shape has to build from Git itself, against the Node version the app declares in .nvmrc or the engines field. A build that ran on your laptop re-introduces your laptop as a deployment dependency, which is the dependency you are trying to leave. The production process has to run supervised, so the crash at 3am restarts without you. Environment variables must be settable per environment from a panel, since Next.js reads its configuration at boot and a restart with the wrong DATABASE_URL is an outage with a delay. And the database needs a home beside the process: provisioned, backed up, close enough that the round trip is not your homepage.

Workers change the requirements list. A queue consumer or a scheduler is a second process that must be deployed, restarted and logged with the same seriousness as the web tier. Platforms that only model one process per app push that work into cron, and cron is where background work goes to fail quietly.

The Vercel default, honestly

Vercel earned the default. The framework is built there, deployment needs no configuration, preview deployments per pull request change how you review work, and the newest framework features tend to work there first and smoothest. For a solo project, a demo, or a marketing site with light dynamic routes, the default is correct and interrogating it is a wasted afternoon.

People who move off tend to share the same reasons. Metered pricing gets hard to predict once an app has steady traffic or background work. A long-running worker is most at home on a server you control. The database wants to sit near the renderer instead of across a continent. And self-hosting occasionally lags the newest framework features, which you notice the week you want one. Starting on Vercel still makes sense; what changes is that the default now has consequences worth counting.

Running Next.js well elsewhere is also more work than clicking deploy. Open-source adapters exist for platforms without native support, and they work, with a maintenance cost worth pricing in before you commit a serious app to one.

The middle path: a managed panel or a raw VPS

Between the metered platforms and a container pipeline sits the ordinary managed panel: a cloud server somebody else patches, deploys from Git, a supervised process, TLS renewed automatically, a database provisioned beside the app. This site's production servers run that way, on Cloudways, which bills per server at a flat rate; the entry server is $14 a month for 1GB of RAM, 1 vCPU and 25GB of NVMe. The trade is the one every managed layer offers: no root by default, and the occasional unusual requirement sends you around the panel instead of through it. The Cloudways review covers what that is like week to week, including the parts that still annoy me.

A raw VPS is cheaper on the invoice and costs hours: patching Node, the reverse proxy, process supervision and certificate renewals become your jobs. If operating the box is the point, or the habits already exist, it is a good choice. If the point is the app, the hours are the expensive part.

The broader decision has its own page. The shape diagnostic in where to host an AI-built app walks the hosting question stack-agnostically, with the verification checklist I hold any candidate host to before paying.