How to Self-Host a Next.js App With Docker

Why self-host Next.js with Docker?

Vercel is the easy path, but plenty of teams want to self-host Next.js with Docker: predictable costs at scale, no per-seat or bandwidth surprises, data residency in a specific region, or simply running it next to a database and other services you already control. Docker makes that portable. The same image runs on your laptop, a CI runner, and a bare-metal box in a Stockholm datacenter, with no 'works on my machine' drift.

The catch is that a naive Dockerfile produces a 1GB+ image stuffed with dev dependencies and source code. Done right, the same app ships in roughly 150-250MB, boots in a second or two, and keeps your registry pulls and cold starts fast. The two ingredients that make that happen are Next.js standalone output and a multi-stage build.

One prerequisite: self-hosting a long-running Node server gives you full SSR, API routes, ISR, and middleware. If you only need a fully static export (no server), `output: 'export'` behind any static host is simpler. This guide targets the dynamic, server-rendered case, which is where Docker earns its keep.

Step 1: Enable standalone output

Next.js can trace exactly which files your app needs at runtime and copy only those into a self-contained folder. Turn it on in your config:

• In `next.config.js` (or `.ts`), set `output: 'standalone'` inside the config object.
• Run `next build`. Next traces dependencies and writes a minimal server to `.next/standalone`, plus a `.next/static` folder for assets.
• Start it locally with `node .next/standalone/server.js` to confirm it boots without your full `node_modules`.
• Standalone bundles only the packages your code actually imports, not the hundreds in `node_modules`. That single flag is responsible for most of the image-size win.

Step 2: Write a lean multi-stage Dockerfile

The standard pattern uses three stages: `deps` installs dependencies, `builder` compiles the app, and `runner` is the tiny final image that ships. Each stage starts from `node:24-alpine` (Node 24 is the active LTS in 2026; Alpine keeps the base around 50MB instead of ~1GB).

A production-shaped Dockerfile looks like this:

• `deps`: `FROM node:24-alpine AS deps`, copy `package.json` + lockfile, run `npm ci`. Caching this layer means dependencies only reinstall when the lockfile changes.
• `builder`: copy `node_modules` from `deps` and the source, run `npm run build` (which produces `.next/standalone`).
• `runner`: `FROM node:24-alpine AS runner`, set `NODE_ENV=production`, create a non-root user, then copy only `.next/standalone`, `.next/static`, and `public` from the builder.
• Finish with `USER nextjs`, `EXPOSE 3000`, and `CMD ["node", "server.js"]`. Add a `.dockerignore` (node_modules, .next, .git, .env) so build context stays small.
• Build and run: `docker build -t my-next-app .` then `docker run -p 3000:3000 my-next-app`.

Step 3: Handle environment variables correctly

This trips up almost everyone. Next.js has two kinds of env vars and they behave differently in Docker. `NEXT_PUBLIC_*` variables are inlined into the JavaScript bundle at build time, so they must be present during `docker build` (pass them with `--build-arg` and `ARG`/`ENV`). Server-only secrets like `DATABASE_URL` are read at runtime and should be passed at `docker run` (or via your orchestrator), never baked into the image.

Practical rule: bake nothing secret into the image. Public, build-time config can be a build arg; everything sensitive comes in at runtime through `--env-file`, `docker run -e`, or your platform's secret store. If you change a `NEXT_PUBLIC_*` value, you must rebuild — runtime injection won't change what's already compiled into the bundle.

• Build time: `docker build --build-arg NEXT_PUBLIC_API_URL=https://api.example.com -t my-next-app .`
• Run time: `docker run -p 3000:3000 --env-file .env.production my-next-app`
• Set `HOSTNAME=0.0.0.0` in the runner so the standalone server binds to all interfaces inside the container, otherwise external traffic can't reach it.

Step 4: Run it in production

A container listening on port 3000 is not a production deployment by itself. Put a reverse proxy in front (Nginx, Caddy, or Traefik) to terminate TLS, handle HTTP/2, and serve as a stable entry point. Caddy is the quickest for automatic HTTPS; Nginx is the most battle-tested. Point it at `localhost:3000` and let it manage certificates.

Add a health check so your orchestrator knows the app is alive — a lightweight route like `/api/health` returning 200, wired into a Docker `HEALTHCHECK` or your platform's probe. Set restart policies (`--restart unless-stopped` or a Compose/Kubernetes equivalent) so the app recovers from crashes and reboots.

A few production details that matter: persist or externalize anything stateful (ISR cache, uploads) since containers are ephemeral; pin your base image to a specific Node version rather than a floating tag; and run as a non-root user, which the Dockerfile above already does. For zero-downtime deploys, build the new image, start it alongside the old one, flip the proxy, then drain the old container.

Where to run your container

Your image will run anywhere with a Docker runtime: a single VPS for a side project, a managed container service, or a Kubernetes cluster for larger fleets. The differentiator for a real-time, SSR-heavy Next.js app is latency and CPU. Server rendering is CPU-bound, and every request pays a round-trip, so raw single-thread speed, fast NVMe storage, and being physically close to your users move the needle more than headline core counts.

If you want the self-hosting upside without babysitting a stack, NordicVentures developer hosting runs your container on NVMe bare-metal and cloud in Stockholm, Frankfurt, and Ashburn, with free migration, transparent pricing (no renewal shock), and 24/7 human support when a deploy goes sideways at 2 a.m. You keep full control of your Dockerfile and environment; we keep the hardware fast and the network close to your users.

Once your Dockerfile builds clean and the container is healthy locally, deploying is the easy part. When you're ready to ship it on infrastructure built for SSR workloads, deploy on developer hosting at /developer-hosting.