Discussion on "Production Next.js Dockerfile: Multi-Stage, Standalone and Non-Root"

Waseem Anjum · 2026-10-26T16:17:33.413Z

A production Next.js Dockerfile is a multi-stage build that installs dependencies, runs next build with output: 'standalone', and copies only the traced server, static assets and public/ folder into a

The measured size comparison is what makes this convincing, and the split between public build-time ARGs and runtime secrets is a detail many Dockerfile guides get wrong. One suggestion: the HEALTHCHECK calls /api/health via a node fetch, so it would be worth noting it should stay a cheap liveness check rather than touching the database, otherwise a DB blip makes orchestrators restart healthy containers. Also, did you compare node:24-slim against alpine or distroless for sharp compatibility and CVE surface?

Good call on keeping it a liveness check. The /api/health route in the post only returns a status and the process uptime, with no database call, and that's on purpose: if a DB blip fails the probe, Docker marks the container unhealthy and Coolify or Swarm can pull containers that are actually fine. If you want DB status, put it on a separate endpoint that your monitoring watches.

On base images, I measured slim and Alpine in the same test: 287 MB on node:24-slim vs 229 MB on node:24-alpine. I didn't build a distroless variant or run a CVE scan, so I don't have numbers there. Sharp ships prebuilt musl binaries, so Alpine works for it, but I keep slim as the default because glibc is the safer bet for other native modules. A distroless runner with a Trivy or Docker Scout comparison would make a good follow-up.

Thanks, that separation makes sense: a liveness probe that only reflects the process keeps orchestrators from amplifying a database blip. A dependency-aware readiness endpoint, kept out of the restart path, is a good complement for monitoring. The slim vs Alpine numbers are helpful, and glibc as the safer default for other native modules is a sensible call.

The standalone tracing is the detail people miss: only the files the server actually imports make it into the runtime stage, which is where most of the size drop comes from. The non-root step pairs well with it and is an easy one to skip.

Exactly. In my test the app files inside the standalone runner came to 59 MB, so most of the 287 MB is the Node base image itself. And non-root is only a couple of lines once the node user owns .next, so there's little reason to skip it.

Search Hashnode

Production Next.js Dockerfile: Multi-Stage, Standalone and Non-Root

Responses5