Lint a Dockerfile before it reaches review.

Seventeen rules, DF001 to DF017, each one a mistake that still builds: an untagged or :latest base image, a COPY --from that names a stage which does not exist yet, ADD where COPY belongs, an unverified remote download, a relative WORKDIR, apt-get update stranded in its own layer, a package cache left inside the image, a secret written into image history by ENV or ARG, a final stage that runs as root, cd instead of WORKDIR, curl piped into a shell, a second CMD that silently wins, a JSON exec form that is not valid JSON, sudo in a build step, MAINTAINER, and a COPY . that defeats the dependency-install cache. Every rule has its own subsection on this page with a before-and-after snippet.

No, and it is not trying to be. hadolint is a binary you install, and it pairs its own rules with everything ShellCheck reports about the shell inside your RUN lines — excellent in CI, and the right answer when you can mandate a toolchain. This is the case hadolint does not cover: a Dockerfile you want checked right now, from a browser, on a machine where you cannot install anything, without sending the file to a server. Seventeen rules instead of a long tail, each with a fix, and an explicit list further down of what it refuses to flag.

No. The parser and all seventeen rules are JavaScript running in your tab — there is no server, no API call and no logging, so 0 bytes are uploaded. That matters more here than for most tools: Dockerfiles carry internal registry hostnames, private package indexes, build arguments and occasionally a credential someone should not have committed.

Because each RUN is a separate layer with a separate cache entry. When you later edit only the install line, Docker reuses the cached update layer — which may be weeks or months old — and runs the install against that stale package index. The result is either a version you did not expect or a 404 for a package that has since been superseded. Joining them into one RUN makes the index and the install share a cache entry, so they can never disagree.

Nothing, until the publisher pushes. :latest is a moving pointer, and an untagged FROM means :latest, so the base image your build used last month and the one it uses tonight can be different major versions with no change on your side — and nothing in the file records which one you actually tested. Pin a tag you have tested. If you need byte-identical rebuilds, add the digest (@sha256:…) as well. This linter asks for a tag and never demands a digest: that trade-off is yours to make.

Because Docker does not reject it — it silently does something else. The exec form is only used when the argument parses as JSON, and JSON requires double quotes. With single quotes the whole thing falls back to shell form, so Docker runs /bin/sh -c "['nginx']" and the brackets and quotes become part of the command. Nothing warns you at build time; the container just fails to start, or starts a shell that is not the process you meant to be PID 1.

Not directly, and it says so rather than guessing. A .dockerignore is a separate file, so a linter that only reads the Dockerfile cannot know whether node_modules, .git and your build output are being shipped into the build context. What it can do is spot the pattern that makes a missing .dockerignore expensive — a COPY . before the dependency install, which is DF017 — and put the .dockerignore advice in that rule's fix text.

Both were considered and deliberately dropped. EXPOSE is documentation: it publishes nothing by itself, so a missing one breaks nothing and an extra one costs nothing. HEALTHCHECK is ignored outright by Kubernetes, which is where most of these images actually run, so flagging it would train this audience to ignore the linter. The full list of what stays silent, with the reason for each, is in the "What it deliberately does not flag" panel above the FAQ.

Up to 200,000 characters — roughly four thousand lines of dense text, which is two orders of magnitude beyond any real Dockerfile. Past that it refuses with a message rather than freezing your tab, because an input that big is a build log or a bundled archive, not a Dockerfile. Findings are capped too, at 20 per rule and 200 in total, and the panel states the cap and the real count whenever it bites.