Dockerfile Linter and Best-Practice Checker

About the Dockerfile Linter and Best-Practice Checker

Paste a Dockerfile and get line-by-line findings, each with the reason and a link to Docker’s documentation:

• Base images without a pinned tag or digest, :latest, and build arguments in FROM that are not declared or leave an invalid image name.
• Root: a final image with no USER, or USER root.
• Packages: apt-get install without -y, without apt-get update in the same RUN, without --no-install-recommends or without removing /var/lib/apt/lists; apt-get update alone in its own layer; apk add without --no-cache; yum and dnf without -y and clean all; pip caches.
• Risky steps: ADD where COPY is clearer, downloads without --checksum, curl … | sh, pipes without pipefail, sudo, chmod 777.
• Secrets in ENV and ARG, which stay in the image for anyone who pulls it.
• Commands: shell-form CMD and ENTRYPOINT (your program misses SIGTERM), exec forms that are not valid JSON, a CMD that a shell-form ENTRYPOINT ignores, repeated CMDs.
• Docker’s build checks: the deprecated MAINTAINER, legacy ENV key value and LABEL key value, relative WORKDIR, EXPOSE with host ports, stage-name casing and duplicates, constant --platform values, COPY --from names that are a typo of a stage, and files that your .dockerignore excludes.

The page also writes a fixed Dockerfile with the safe changes made, shown as a diff, suggests a multi-stage build where build tools end up in the image you ship, and writes a .dockerignore for what you build. The rules are MySmartCoPilot’s own, written from Docker’s documentation. Nothing is uploaded. Without a pass the result is a free preview: every count with the first problems, and the first lines of the fixed Dockerfile, the diff and the .dockerignore. The whole report and every copy and download unlock with a Pro pass.

Where the rules come from

Rules that do the same job as one of Docker’s build checks keep its name — JSONArgsRecommended, SecretsUsedInArgOrEnv, UndefinedArgInFrom, CopyIgnoredFile and the others — so you can match them with the output of docker build --check .. The others follow Docker’s building best practices (apt-get, pipes, ADD or COPY, USER, WORKDIR, pinning base images) and the Dockerfile reference (exec and shell form, HEALTHCHECK, here-documents). Secret names are recognised the way BuildKit recognises them: words such as password, secret, token, key or auth as a whole word of the name (DB_PASSWORD, GITHUB_TOKEN, API_KEY_ID), unless another word of it is public, file or version (PUBLIC_KEY, SECRET_FILE).

Multi-stage builds

When one stage installs compilers or runs npm run build, go build, mvn package or similar, everything it needed stays in the image you deploy. A multi-stage build builds in a first stage and copies only the result into a small runtime image: FROM node:24 AS build … RUN npm run build, then FROM node:24-slim with COPY --from=build /app/dist ./dist. The linter points this out; the restructuring is yours.

Limitations

• The linter reads the Dockerfile only: it does not pull base images, so it cannot see the USER, ENV or HEALTHCHECK a base image sets, nor check that packages and files exist.
• Commands inside RUN are read as text (including here-documents), not run in a shell, so unusual scripts may be read too strictly or not strictly enough.
• The fixed Dockerfile only makes mechanical changes; build it and test it before you replace yours.

Privacy

Everything happens in your browser. What you enter or open here is not uploaded or stored by MySmartCoPilot.