Security advice for self-hosting Next.js in Docker

How do you self-host Next.js in Docker securely?

Use Node 22 LTS on Debian Bookworm, build with output: "standalone", run as a non-root user, and inject secrets at start from a manager. Do not use Node 18 (end of life). Node 20 is the previous LTS; prefer 22 for new images.

Application-layer checks still apply. Complete the Next.js security checklist before you harden the image. Structured logs belong in the same image; see structured logging in Next.js.

What is the self-hosted Next.js Docker checklist?

• Pin node:22-bookworm (or a digest) for build stages and node:22-bookworm-slim or gcr.io/distroless/nodejs22-debian13:nonroot for the runner.
• Set output: "standalone" in next.config and copy only the standalone trace, static assets, and public files.
• Create a dedicated user and set USER before CMD.
• Do not bake production secrets into the image or into a committed .env.
• Drop the shell in production when you can; use Distroless or a slim image.
• Keep the host patched, expose only the app port, and terminate TLS in front of the container.
• Scan the image (Trivy or equivalent) in CI on every build.

Which container image should you use?

The official Next.js Docker example has used Alpine and older Node lines. Alpine's musl libc breaks some native addons if you develop on glibc. Debian Bookworm matches most developer machines.

Pin a minor or a digest (node:22.18-bookworm) so a rebuild does not surprise you. Update that pin on a schedule. Avoid node:lts; the major version changes under you.

Why run Next.js as a non-root user?

If the Node process is root, a remote code execution bug can install packages, read every file in the container, and attempt a container escape with extra privileges. Create a user, chown the app files, and set USER before CMD.

1
RUN groupadd -r nodejs && useradd -r -g nodejs -d /app -s /sbin/nologin nextjs \
2
    && chown -R nextjs:nodejs /app
3

4
COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
5
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static
6

7
USER nextjs
8
CMD ["node", "server.js"]

Distroless nonroot images already provide a non-root UID. Use COPY --chown=nonroot:nonroot and USER nonroot.

How should Dockerized Next.js load secrets?

Do not copy a production .env with raw keys into the image. Anyone with the image can docker history or extract the layer. Do not rely on docker run -e for long-lived production secrets either; they appear in process listings and crash dumps.

A 1Password pattern that keeps values out of the image:

1
COPY --chown=nextjs:nodejs --from=1password/op:2 /usr/local/bin/op /usr/local/bin/op
2
USER nextjs
3
CMD ["/usr/local/bin/op", "run", "--env-file=/app/.env.production", "--", "node", "server.js"]

.env.production holds references such as ARCJET_KEY=op://app.arcjet.com/ARCJET_KEY/credential, not the key itself. The only long-lived secret in the container is OP_SERVICE_ACCOUNT_TOKEN, scoped to one vault.

On Distroless, skip the CLI. Use the manager's SDK or the platform's native injection (ECS secrets, Kubernetes secret volumes).

What does a Node 22 standalone Dockerfile look like?

1
FROM node:22-bookworm AS installer
2
WORKDIR /app
3
ENV NEXT_TELEMETRY_DISABLED=1
4
COPY package.json package-lock.json ./
5
RUN npm ci
6
COPY . .
7
RUN npm run build
8

9
FROM node:22-bookworm-slim AS runner
10
WORKDIR /app
11
RUN apt-get update \
12
    && apt-get install -y --no-install-recommends ca-certificates \
13
    && rm -rf /var/lib/apt/lists/* \
14
    && groupadd -r nodejs \
15
    && useradd -r -g nodejs -d /app -s /sbin/nologin nextjs \
16
    && chown -R nextjs:nodejs /app
17

18
COPY --from=installer --chown=nextjs:nodejs /app/.next/standalone ./
19
COPY --from=installer --chown=nextjs:nodejs /app/.next/static ./.next/static
20
COPY --from=installer --chown=nextjs:nodejs /app/public ./public
21

22
USER nextjs
23
ENV NODE_ENV=production
24
ENV NEXT_TELEMETRY_DISABLED=1
25
EXPOSE 3000
26
CMD ["node", "server.js"]

Set output: "standalone" in next.config.ts. Adjust static and public copy paths if the app lives in a monorepo subdirectory.

Distroless runner (no op CLI):

1
FROM gcr.io/distroless/nodejs22-debian13:nonroot AS runner
2
WORKDIR /app
3
COPY --from=installer --chown=nonroot:nonroot /app/.next/standalone ./
4
COPY --from=installer --chown=nonroot:nonroot /app/.next/static ./.next/static
5
COPY --from=installer --chown=nonroot:nonroot /app/public ./public
6
USER nonroot
7
ENV NODE_ENV=production
8
EXPOSE 3000
9
CMD ["server.js"]

The Distroless entrypoint is node, so CMD is the script path only.

How do you screen requests in a self-hosted container?

Hosting on your VM does not replace application-layer limits. Add the same v1 rules you would use on Vercel:

1
import arcjet, { detectBot, shield, slidingWindow } from "@arcjet/next";
2

3
const aj = arcjet({
4
  key: process.env.ARCJET_KEY!,
5
  rules: [
6
    shield({ mode: "LIVE" }),
7
    detectBot({ mode: "LIVE", allow: ["CATEGORY:SEARCH_ENGINE"] }),
8
    slidingWindow({ mode: "LIVE", interval: 60, max: 100 }),
9
  ],
10
});
11

12
export async function POST(req: Request) {
13
  const decision = await aj.protect(req);
14
  if (decision.isDenied()) {
15
    return Response.json({ error: "Forbidden" }, { status: 403 });
16
  }
17
}

If a reverse proxy sits in front, configure proxies so Arcjet sees the client IP, not the proxy. Emit JSON logs from the same process so denials are searchable; the structured logging guide shows the Instrumentation hook.

What else does the host need?

Patch the VM. Expose only 80 and 443 on the public interface, or nothing public if you reach the box over a mesh. Run a reverse proxy with TLS. Do not publish Docker's socket. Scan images in CI and rebuild when Node or Debian publishes a security update.

Add a health check that hits a cheap route, not the homepage if the homepage runs expensive queries. Do not run docker.sock into the app container. Publish only port 3000 on a private network and terminate TLS on the proxy.

Rebuild when Node publishes a security release on the 22 line, even if your app code did not change. Distroless images lag the official Node tag by a short window; pin and update both.

A locked-down image with a world-open login route is still an open login route. Keep the Next.js security checklist in the same review as the Dockerfile.