This skill provides rules and patterns for writing and reviewing production-quality Dockerfiles. Apply it when the main task is image-build quality: multi-stage builds, cache behavior, non-root execution, build context hygiene, and runtime image size.
\nActivate this skill when:
\n.dockerignore file to a projectDo not use this skill when:
\ncompose.yamlUse multi-stage builds when the project has a build step or when build-time dependencies differ from runtime. Separate build-time dependencies from the runtime image.
\nFROM ... AS build, FROM ... AS runtime).distroless, alpine, or slim variants.COPY --from=build.COPY --link when copying from a prior stage or adding static files — it improves cache reuse by making the COPY independent of previous layers.See references/multi-stage-builds.md for language-specific patterns (Go, Node, Python, Java).
Order Dockerfile instructions from least-frequently-changed to most-frequently-changed.
\npackage.json, go.mod, requirements.txt) and install steps before copying application source code. Bind-mount the manifest into the install step instead of COPY-ing it, so it never enters a layer: RUN --mount=type=bind,source=package.json,target=package.json --mount=type=bind,source=package-lock.json,target=package-lock.json npm ci. This is safe for install commands that only read the manifest (npm ci, pip install -r, go mod download); if a step also needs to write the manifest back into the image, COPY it instead.RUN --mount=type=cache,target=/go/pkg/mod go build ...RUN --mount=type=cache,target=/root/.npm npm ciRUN --mount=type=cache,target=/root/.cache/pip pip install ...RUN --mount=type=cache,target=/var/cache/apt,sharing=locked --mount=type=cache,target=/var/lib/apt,sharing=locked apt-get update && apt-get install -y ... — no rm -rf /var/lib/apt/lists/* needed, since the cache lives outside the image layer. sharing=locked is required because apt needs exclusive access to its cache directories.references/layer-caching.md links the source): RUN --mount=type=cache,target=/etc/apk/cache,sharing=locked apk add ... — drop --no-cache so downloaded packages land in the mounted cache directory instead of being discarded.latest in production.RUN commands with && to reduce layer count, but keep logically distinct steps separate for cache granularity.See references/layer-caching.md for detailed cache invalidation rules and cache mount patterns.
Never bake credentials into the image. Use BuildKit secrets and SSH mounts so credentials are available only during the specific RUN step that needs them, and never persist in any layer or docker history output.
ARG or ENV. Both end up in the image layers and are inspectable via docker history.COPY credential files into the build context: .npmrc, .pypirc, .netrc, pip.conf, Maven settings.xml, .env, cloud credentials (~/.aws/credentials, ~/.config/gcloud/, service-account JSON files, ~/.azure/), secret-manager tokens (~/.vault-token), package-registry tokens (~/.cargo/credentials.toml), TLS keys (*.pem, *.p12), kubeconfig, SSH keys (id_rsa, id_dsa, id_ed25519, id_ecdsa). Even when the final stage does not copy them forward, they live in intermediate layers and the build cache.RUN command in a way that persists it to a layer or emits it to build logs. Access the secret file (e.g., /run/secrets/<id>, or directly via the mount target=) — never echo \"$(cat /run/secrets/X)\", never substitute it into a shell argument that will be logged with --progress=plain.RUN --mount=type=secret for package manager registry credentials:\nRUN --mount=type=secret,id=npmrc,target=/root/.npmrc,required=false \\\n --mount=type=cache,target=/root/.npm \\\n npm ci --omit=dev\nRUN, never written to a layer. Use required=true when the build will always need the credential (e.g., all packages come from a private registry, so missing the secret should fail the build immediately); use required=false only when the secret is optional (the build can succeed with public packages alone).RUN --mount=type=ssh for fetching private Git repositories or modules. The build container has no known_hosts by default — populate it inside the same RUN:\nRUN --mount=type=ssh \\\n mkdir -p -m 0700 /root/.ssh && \\\n ssh-keyscan github.com >> /root/.ssh/known_hosts && \\\n git clone git@github.com:org/private-repo.git\nStrictHostKeyChecking=no as a shortcut — it disables host-key verification entirely. ssh-keyscan accepts whatever host key the server presents each time the step runs; nothing is pinned between builds. For stronger assurance, compare it against the provider's published host key fingerprints, or write the published key into known_hosts instead of scanning.# --ssh default forwards this shell's SSH agent (SSH_AUTH_SOCK); list every key the build can use:\nssh-add -l\n\ndocker buildx build \\\n --secret id=npmrc,src=$HOME/.npmrc \\\n --ssh default \\\n .\nRUN --mount=type=ssh step can use every key that ssh-add -l lists, so expose only the key this build needs. In an interactive terminal, run ssh-agent bash to start a shell with a dedicated agent, then run ssh-add <key-file>, confirm that ssh-add -l lists only that key, and run the build in that shell. A tool that starts a new shell for each command loses that agent between commands, so ask the user to run these steps. Alternatively, pass an unencrypted key file, such as a dedicated deploy key, directly with --ssh default=<key-file>; BuildKit rejects passphrase-protected keys in this form, so load those into an agent instead..dockerignore exclusions of .env and credential files are defense in depth, not the primary mechanism — keep them, but do not rely on them as your only protection.See references/multi-stage-builds.md for per-language patterns (npm, pip, Maven, Go GOPRIVATE).
Always generate a .dockerignore alongside the Dockerfile. Exclude:
.git/, .github/, .vscode/, .idea/node_modules/, __pycache__/, .venv/, vendor/ (when rebuilt in the build stage)*.md, LICENSE, docs/.env files and any secretsSee assets/dockerignore-example for a comprehensive template.
Always configure the final image to run as a non-root user.
\nRUN addgroup --system --gid 1001 appgroup && \\\n adduser --system --uid 1001 --ingroup appgroup appuser\nCOPY --from=build --chown=appuser:appgroup /app /app--chown with COPY --link, always use the numeric UID:GID you assigned (e.g., --chown=1001:1001 if you used --uid 1001 --gid 1001 above), not named users. --link creates an independent layer where named users from prior RUN instructions are not available.USER appuser instruction after all file operations and before ENTRYPOINT/CMD.USER nonroot:nonroot.FROM scratch (Go static binaries), distroless, or Alpine-based images for the runtime stage.rm -rf-ing the cache in the same layer — see \"Layer caching\" above. The cache mount keeps the package cache out of the image layer entirely, so no cleanup step is needed..dockerignore aggressively to minimize the build context.# syntax=docker/dockerfile:1 directive as the first line to enable BuildKit features.WORKDIR before any COPY or RUN instructions — never rely on the default /.ENTRYPOINT with exec form ([\"binary\"]) over shell form.EXPOSE to document the listening port.LABEL org.opencontainers.image.source=...docker-project-foundations.docker-compose-patterns.docker system prune, docker rm -f, image/network/builder pruning) and a cross-product index of destructive-command guardrails, use docker-destructive-guardrails.references/multi-stage-builds.md — Language-specific multi-stage patterns for Go, Node.js, Python, and Javareferences/layer-caching.md — Deep dive on layer ordering, cache invalidation, and BuildKit cache mountsassets/Dockerfile.go — Multi-stage Go build with distroless runtime and non-root userassets/Dockerfile.nodejs — Multi-stage Node.js build with proper layer caching and non-root userassets/Dockerfile.python — Python build with virtual env, layer ordering, and non-root userassets/dockerignore-example — Comprehensive .dockerignore templatescripts/verify-build.sh — Builds the Dockerfile in the current directory, then reports image size and configured user. Run it from the project root (the directory that contains the Dockerfile), with the script path resolved under this skill's directory:\nbash \"<skill-dir>/scripts/verify-build.sh\" [--help] [IMAGE_NAME]\n<skill-dir> with the absolute path of the folder that contains this SKILL.md; the scripts/ path is relative to that folder, not to the project. Do not change into the skill directory first: the script builds whatever is in the current directory. If the skill directory cannot be resolved, run docker build -t verify-build-test ., then docker images verify-build-test and docker inspect verify-build-test --format '{{.Config.User}}'. Exit status is 0 when all Docker commands succeed or help is requested, the failing Docker command's non-zero status when verification fails, and 2 for invalid arguments.checks/verification.md — Detailed verification runbook for manual review.