Dockerfile best practices linter with line numbers

It reports a missing WORKDIR, base images that use the mutable latest tag, and consecutive RUN instructions that may create unnecessary layers. Every finding includes a one-based source line, a stable type, and a direct explanation, making the result useful both to a developer reading a file and to an automated check in continuous integration.

Read a small, actionable Dockerfile report

Paste the complete Dockerfile content into the text field and run the check. The response says whether the file passed, gives the number of findings, and lists each issue with a one-based line number, a stable machine-readable type, and a concise message. The linter deliberately concentrates on three frequent maintenance problems instead of pretending to replace a full container security suite. A missing WORKDIR is reported at line 1 because it applies to the file as a whole. A FROM instruction is reported on its own source line when its image explicitly uses the latest tag or omits a tag and therefore resolves to latest. When two RUN instructions are consecutive, the later instruction is reported and points back to the earlier line. Blank lines and comments do not hide that relationship. A clean file returns an empty findings array, which lets a script use valid as a simple pass condition without interpreting prose or filling in missing values. Line continuations are treated as part of one logical instruction, while their reported position remains the first physical source line so it matches an editor and a code review diff.

Understand why these three practices matter

WORKDIR makes the filesystem context explicit for later RUN, COPY, CMD, and ENTRYPOINT behavior. Without it, the build silently inherits a directory chosen by the base image, and a future base-image update can change where files are installed or commands execute. Pinning a FROM image to a versioned tag or immutable digest makes builds easier to reproduce. An untagged image reference and an explicit latest tag can both move to different content even when the Dockerfile itself has not changed. Finally, every RUN normally creates a filesystem layer. Consecutive package installation, cleanup, or setup commands often belong in one shell operation so temporary files can be removed in the same layer and the image history stays easier to understand. The finding is phrased as a recommendation because separate RUN instructions are sometimes intentional, especially when cache boundaries improve an established workflow. This tool does not rewrite commands or claim that every merge is safe. It gives reviewers an exact location and leaves the final decision to someone who understands the build, its caching strategy, and the failure behavior of the shell commands involved.

Place the check before expensive image builds

Run the linter in an editor action, a pre-commit workflow, or an early continuous-integration job before downloading base images and compiling an application. Send the original source text rather than a parsed representation so physical line numbers and continued instructions remain accurate. The algorithm is deterministic: identical input produces identical output, and it does not use the network, a clock, random values, a Docker daemon, or environment-specific state. That makes it suitable for gating generated Dockerfiles as well as files maintained by hand. Treat the report as a basic maintainability signal, not proof that an image is secure or buildable. The linter does not execute shell commands, resolve variables in image names, inspect package versions, validate COPY sources, enforce a non-root USER, or scan image layers for vulnerabilities. A FROM value containing build-time variable expansion may therefore need human review. Combine this fast text check with an actual container build, image vulnerability scanning, policy enforcement, and tests for the resulting process. If the input contains only whitespace or comments, the request fails as invalid input because there are no Dockerfile instructions to assess, which prevents an empty file from being mistaken for a successful review.