Deploying Next.js

Deployment Options Depend on What Your App Uses

A fully static site (using output: "export") can be hosted on literally any static file host or CDN, since there's no server-side rendering, Server Actions, or dynamic Route Handlers involved. Apps using SSR, ISR, Server Actions, or dynamic Route Handlers need a runtime capable of executing Node.js (or edge) code — this rules out plain static hosting and requires either a managed platform or your own server.

Vercel (the company behind Next.js) offers the deepest, most seamless integration, since new Next.js features are frequently designed alongside Vercel's infrastructure, but Next.js explicitly supports self-hosting on any Node.js server, and containerized deployment via Docker for teams that need that flexibility.

// package.json scripts used across most deployment targets
{
  "scripts": {
    "build": "next build",
    "start": "next start"
  }
}

// next start serves the production build, handling SSR/ISR/API routes

next build followed by next start is the standard production flow for any Node.js-capable hosting environment.

Deployment Targets at a Glance

output: "export"    → any static host / CDN (no server features)
Vercel               → zero-config, deepest feature support
Self-hosted Node.js  → "next build" + "next start" on your own server
Docker               → containerized, portable across cloud providers

• Static exports work anywhere but lose SSR, ISR, Server Actions, and dynamic Route Handlers.
• Vercel deploys directly from a Git repository with no manual server configuration.
• Self-hosted Node.js deployments require you to manage the running process (e.g. with a process manager).
• Docker deployments package your app and its runtime into a portable container image.

Deployment Options Cheat Sheet

Choosing based on your app's requirements.

Why Vercel Is a Natural Fit

Vercel's platform maps directly onto Next.js's rendering model — static routes are served from a global CDN, dynamic routes run as serverless/edge functions, and ISR revalidation is handled by the platform automatically, all without any deployment configuration beyond connecting a Git repository.

What Self-Hosting Requires

Self-hosting on your own Node.js server means you're responsible for process management (restarting on crashes), load balancing across multiple instances if needed, and configuring reverse proxies/HTTPS — all handled automatically on Vercel, but well-understood, standard concerns for any Node.js deployment.

Common Mistakes

• Configuring output: "export" for an app that actually needs SSR, ISR, or Server Actions.
• Assuming a static host can run Route Handlers or Server Actions without a Node.js runtime.
• Underestimating the operational work (process management, scaling) required for self-hosting.
• Not testing the production build (next build && next start) locally before deploying.

Key Takeaways

• Deployment options depend entirely on which Next.js features your app actually uses.
• Static exports work on any host but lose all server-side rendering features.
• Vercel offers the deepest, most seamless integration with Next.js's rendering model.
• Self-hosted Node.js and Docker deployments are fully supported for teams needing more control.
• Always test next build && next start locally before deploying to production.