Next.js Hosting

No. Vercel is one deployment option; a VPS is another. Next.js is an open-source framework - Vercel created it, but it runs on any Node.js server. The output: 'standalone' configuration in next.config.js produces a self-contained server that runs without the Vercel platform or any Vercel-specific tooling. Every core Next.js feature - SSR, API routes, Server Components, image optimisation, Middleware - works on a self-hosted deployment. The things that do not work outside Vercel are Vercel-specific features: Edge Functions using Vercel's edge runtime, Vercel Analytics, and Vercel's built-in CDN. None of those are part of the Next.js framework itself.

You do not strictly need it - next start works without it - but standalone mode is the right choice for VPS deployments. Without it, your server needs the full node_modules directory present alongside the build output, which means either committing node_modules (not recommended) or running npm install on the server before each deployment. With output: 'standalone', Next.js traces every dependency your application actually uses and copies only those into .next/standalone/, along with a minimal server file. Deploy that directory and run node .next/standalone/server.js - no npm install, no Next.js CLI, no extra setup. Standalone output is also what makes CI/CD deployments cleaner: build in the pipeline, copy the output to the server, restart PM2. If you'd rather containerise a Next.js application, see the Docker hosting page.

Yes. Next.js's image optimisation (next/image) runs on the Node.js server, not on Vercel's infrastructure. When a visitor requests an optimised image for the first time, the Next.js server resizes and converts it, caches the result, and serves the cached version on subsequent requests. This works on any self-hosted deployment without additional configuration. For better performance, add sharp to your project's package.json dependencies before building - Next.js uses sharp for image processing when available, which is faster than its built-in fallback. Without sharp, optimisation still works, just more slowly.

Next.js distinguishes between two types of environment variables. Server-side variables - accessible only in server components, API routes, and server-side functions - are set in your server environment via PM2's configuration file (env key), a systemd Environment= directive, or a .env.local file in your project directory. These are never exposed to the browser. Client-side variables - exposed to the browser at runtime - must be prefixed with NEXT_PUBLIC_ and are baked into the JavaScript bundle at next build time. If a NEXT_PUBLIC_ variable changes, you need to rebuild and redeploy; restarting the server process alone is not sufficient. Any variable without the NEXT_PUBLIC_ prefix is server-only regardless of where it's set.

The standard update workflow for a self-hosted Next.js application: pull your new code, run npm install if dependencies changed, run next build, copy the updated public/ and .next/static/ into the standalone output directory, then restart PM2 (pm2 restart your-app). The application is briefly unavailable during the restart - typically a few seconds. For zero-downtime deployments, PM2's reload command (rather than restart) performs a graceful rolling reload: new workers start before old ones stop, so there's no gap in availability. For more complex deployment pipelines, building in CI/CD and deploying only the .next/standalone/ output avoids running the build on the production server entirely.

Yes, without any additional configuration. API routes (/api/ in the Pages Router, route.ts or route.js files in the App Router) run as part of the Next.js Node.js server and work identically to a Vercel deployment. Server Components render on the Node.js process. Middleware runs on the Node.js process in self-hosted mode - note that Next.js Middleware is designed to run on Vercel's edge runtime, but it runs on the standard Node.js runtime when self-hosted, which means the Edge runtime API restrictions (no fs, limited Node.js APIs) do not apply. The practical implication: middleware that uses Node.js-only APIs works in self-hosted mode but would fail on Vercel's edge runtime.

The primary consideration is how much server-side rendering your application does and whether you're running a database on the same server. VPS-1 suits low-traffic sites with mostly statically generated pages, or staging and development environments. VPS-2 is the recommended starting point for most Next.js applications in production - it handles SSR, API routes, image optimisation, and a moderate-traffic site without running close to memory limits. Note that next build for a large application can use 1-2GB of RAM; if builds fail on VPS-1, either upgrade to VPS-2 or build in CI/CD and deploy only the output. VPS-4 suits higher-traffic applications or those where PM2 cluster mode across 4 cores meaningfully improves throughput. VPS-6 suits large-scale deployments or servers running multiple Next.js applications. When in doubt, start on VPS-2 - upgrading is straightforward and does not require migrating data.