What this checks
Paste a Dockerfile and it's checked against the common mistakes and best-practice deviations that build fine but cause real problems later: an unrecognized instruction (a typo like RUNN), a missing FROM, an EXPOSE port outside the valid 1-65535 range, a COPY --from that doesn't match any earlier named build stage (a typo'd stage name), and multiple CMD or ENTRYPOINT instructions in the same stage — only the last one takes effect, and Docker won't warn you that the earlier ones are being silently ignored.
It also flags a set of well-documented Dockerfile best-practice issues: an image with no tag or pinned to :latest (non-reproducible builds), apt-get install without update in the same RUN (a classic Docker build-cache trap — see Docker's own best-practices guide), ADD used where COPY would do, cd inside a RUN instead of WORKDIR, the deprecated MAINTAINER instruction, and a final stage with no USER (running as root).
What it doesn't do
This reads the Dockerfile's instructions structurally — it doesn't build the image, resolve ARG/ENV variable substitution, or know whether a referenced base image or file path actually exists. Package-version pinning inside RUN commands (e.g. apt-get install curl=7.81.0-1) isn't checked, since that varies too much by package manager to flag reliably without false positives.
FAQ
Why flag "apt-get install" without "update" in the same RUN?
If apt-get update runs in one RUN layer and apt-get install runs in a later one, Docker's layer cache can serve the old, cached update layer on a rebuild while your install layer changes — installing against a package index that's no longer current. Keeping both in the same RUN means they're invalidated together.
I have a compose file too
Check it with the Docker Compose Validator — it catches the equivalent class of mistakes (undefined service references, bad port mappings, undeclared volumes/networks) for docker-compose.yml.