Docker for Node.js applications: images that are small, fast and safe

What does a good Node.js Dockerfile look like?

# syntax=docker/dockerfile:1
FROM node:22-alpine AS deps
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --omit=dev

FROM node:22-alpine AS build
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:22-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production
RUN addgroup -S app && adduser -S app -G app
COPY --from=deps  --chown=app:app /app/node_modules ./node_modules
COPY --from=build --chown=app:app /app/.next/standalone ./
COPY --from=build --chown=app:app /app/.next/static ./.next/static
COPY --from=build --chown=app:app /app/public ./public
USER app
EXPOSE 3000
CMD ["node", "server.js"]

For Next.js, the standalone output mode is what makes this small — it traces exactly the files the server needs and leaves the rest behind. Enable it with output: "standalone" in next.config.

Why does layer ordering matter so much?

Docker caches each layer and invalidates every layer after the first one that changes, so anything that changes often must come last.

Copying your whole source tree before running npm ci means every one-character source change re-installs all dependencies. Copying only package.json and the lockfile first means the install layer is reused until dependencies actually change — turning a three-minute build into twenty seconds.

• Order layers from least to most frequently changing.
• Use a .dockerignore that excludes node_modules, .git, .next and local env files — it shrinks the build context and prevents cache busting.
• Use BuildKit cache mounts for package manager caches in CI.
• Pin base images by minor version or digest so builds are reproducible.

How do you handle shutdown correctly?

When an orchestrator scales down or deploys, it sends SIGTERM and waits before sending SIGKILL. A process that ignores SIGTERM has its in-flight requests killed — visible to users as random errors during every deploy.

const server = app.listen(3000);

for (const signal of ["SIGTERM", "SIGINT"]) {
  process.on(signal, async () => {
    server.close(async () => {          // stop accepting new connections
      await db.end();                   // drain the pool
      process.exit(0);
    });
    setTimeout(() => process.exit(1), 10_000).unref(); // hard limit
  });
}

How small should the image be?

Alpine uses musl rather than glibc, which occasionally breaks native modules — sharp, canvas, some database drivers. Test your actual dependency set; if something misbehaves, slim is a perfectly good answer at a modest size cost.

What else belongs in a production container?

1. 1A HEALTHCHECK or an orchestrator probe pointing at a real readiness endpoint.
2. 2Configuration from environment variables at runtime, never baked into the image.
3. 3A read-only root filesystem where possible, with writable volumes only where needed.
4. 4Resource limits — memory and CPU — so one container cannot starve its neighbours.
5. 5An image scan in CI that fails the build on high-severity vulnerabilities.
6. 6Logs to stdout and stderr as JSON, collected by the platform rather than written to files.