What this linter does
A Dockerfile that technically builds is not the same as a Dockerfile that should be shipped. The image can have a few hundred MB of leftover apt cache that nobody uses. It can run as root with no HEALTHCHECK, so K8s never knows the container is broken. It can use `:latest` tags that change under your feet. It can use `ADD` where `COPY` would be safer. None of these stop the build, but every one of them causes pain in production.
This linter runs hadolint-style rules in your browser. Paste your Dockerfile and you get a per-line list of issues with rule ID, severity, description, and a fix hint. About 20 rules from the standard hadolint catalog (`DL3000`, `DL3007`, `DL3008`, ...) plus a few custom checks for USER not set, HEALTHCHECK missing, and image not pinned by digest.
Everything runs client-side. No upload, no build, no Docker daemon contact. The output is the same kind of feedback you would get from running `hadolint Dockerfile` locally, only inside the browser tab.
How to use it
- Paste your Dockerfile in the input panel, or pick one of the samples at the top to see the output format.
- Read the error / warning / info counts at the top right. Click any issue to see the line number and fix hint. Each issue carries a rule ID like `DL3007` that you can search for full hadolint documentation.
- Common warnings the linter flags: `:latest` tag (`DL3007`), `apt-get install` without pinned versions (`DL3008`) and **without `rm -rf /var/lib/apt/lists/*` (`DL3009`), `MAINTAINER` which is deprecated (`DL4000`), `ADD` for local files where `COPY` is safer (`DL3020`), `CMD` in shell form instead of JSON exec form (`DL3025`), `RUN cd ...`** instead of `WORKDIR` (`DL3003`).
- Security checks: container runs as root when no `USER` is set, `privileged: true`-style patterns, image not pinned by digest, `HEALTHCHECK` missing on the final stage.
- Use the "fixed" panel below the issues to see a best-effort rewrite of the simple cases: `MAINTAINER` becomes `LABEL maintainer`, `ADD` becomes `COPY` when the source is local. More complex fixes (pinning versions, adding HEALTHCHECK, splitting RUN) need a human read.
- Click Copy on the "fixed" panel to grab the rewritten version, or Copy on the input panel to put the original in your clipboard.
- When the linter says "all clean", you have a Dockerfile that follows the well-known best practices. There may still be project-specific things to fix (image size, layer ordering for build cache), but the basics are covered.
When this is useful
Seven concrete situations where Dockerfile linting before `docker build` saves real headaches:
- Reviewing a teammate's PR with a new Dockerfile. The linter gives a quick objective list: pin versions, drop `:latest`, add cleanup, add a non-root user. Code review focused on logic, not on every common pitfall.
- First-pass cleanup of a legacy Dockerfile. Many old Dockerfiles use `MAINTAINER`, `ADD` for local files, `apt-get install` without cleanup, and a final image two times bigger than it could be. The linter highlights the easy wins.
- Optimizing image size. `DL3009` (apt list cleanup) and `DL3015` (`--no-install-recommends`) together can shrink images by 100+ MB. `DL3059` (merge consecutive RUNs) reduces layer count which matters at scale.
- Security pass. `CUSTOM_USER` flags every stage that ends up running as root. Combined with `CUSTOM_HEALTH` for the final stage, this is the minimum baseline checks for hardening before shipping.
- Pinning versions for reproducibility. `DL3007` (no `:latest`), `DL3008` (apt versions), `DL3018` (apk versions), `DL3028` (gem versions), `CUSTOM_DIGEST` (image by sha256). Together they make builds deterministic.
- Teaching juniors what hadolint catches. The rule IDs map 1:1 to the public hadolint catalog so anyone can look them up and learn the reasoning behind each rule.
- Quick check in the browser before pushing. `docker build` takes minutes; the linter is instant. Fast feedback loop while iterating on the Dockerfile.