Web Container Docker Configuration#

The Dify web container packages a Next.js (and optionally vinext) frontend into a minimal Alpine-based image. The key files are:

Multi-Stage Build#

The Dockerfile has four stages on top of node:24.20.0-alpine:

1. base — Enables corepack/pnpm, sets PNPM_HOME, accepts the NEXT_PUBLIC_BASE_PATH build arg (the only variable baked in at image build time). 1
2. packages — Installs workspace dependencies with pnpm install --frozen-lockfile --ignore-scripts. The --ignore-scripts flag skips lifecycle scripts during Docker dependency installation, preventing development-only scripts (like the root prepare: vp config hook setup) from requiring Git during image builds. 2
3. builder — Sets NODE_OPTIONS="--max-old-space-size=4096" and runs pnpm build && pnpm build:vinext to produce both the Next.js and vinext outputs. 3
4. production — Copies compiled outputs, sets default environment values, creates the non-root dify user, and declares the entrypoint. 4

Build outputs are copied into two parallel trees 5:

• targets/next/ ← web/.next/standalone (Next.js standalone server)
• targets/vinext/ ← web/dist/standalone (vinext server)

Next.js standalone output is enabled by output: 'standalone' in next.config.ts.

Non-Root User#

The production stage creates a dedicated system user and group dify with UID/GID 1001 (configurable via the dify_uid build arg) 6. All /app files are chown-ed to this user, and the final USER dify directive ensures the container process runs unprivileged 7. The entrypoint script itself is copied with --chmod=755 so it remains executable under the non-root user 8.

Entrypoint Behavior#

entrypoint.sh runs with set -e and does two things:

1. Environment variable mapping — Docker-native variable names are translated into NEXT_PUBLIC_* equivalents that the running Node server exposes to the client 9:

Feature-flag variables (e.g., MARKETPLACE_ENABLED, ALLOW_REGISTER) use shell fallback syntax ${NEXT_PUBLIC_FOO:-${PLAIN_FOO}}, so either form works at runtime 10.

2. Server selection — At the end of the script, a conditional selects the server to exec 11:

• EXPERIMENTAL_ENABLE_VINEXT=true → exec node /app/targets/vinext/server.js
• Otherwise (default) → exec node /app/targets/next/web/server.js

Using exec replaces the shell process with the Node process, so Node becomes PID 1 and receives OS signals directly.

Next.js Standalone Server Process Model#

In production the Node process (server.js) is the direct container process (PID 1) — there is no intermediate process manager. The standalone build bundles all required Node modules so no node_modules install is needed at runtime.

Default environment values set in the production stage 12:

Port 3000 is exposed via EXPOSE 3000 13.

copy-and-start.mjs — Dev/Local Use#

web/scripts/copy-and-start.mjs is not used by the Docker image. It is the dev/local next start replacement (described in its header comment as "intended to be used as a replacement for next start") 14.

It:

1. Locates the standalone server.js by checking STANDALONE_ROOT_CANDIDATES (.next/standalone/web then .next/standalone) 15.
2. Copies .next/static and public/ into the standalone root 16 — the step that the Dockerfile handles at build time via explicit COPY instructions 5.
3. Spawns the server as a child process (not exec) via Node's child_process.spawn, inheriting stdio and forwarding the exit code 17. This means the parent script holds the process and the actual server runs as a subprocess — different from the production container where Node is PID 1.

The listening host and port are resolved from pnpm_config_host/pnpm_config_port with fallback to HOSTNAME/PORT 18.