Which rules does this linter check?

It ports the most actionable hadolint rules: unpinned or latest base images (DL3006/DL3007), apt-get and apk hygiene (DL3009/DL3015/DL3019), using cd instead of WORKDIR (DL3003), ADD vs COPY (DL3020), running as root (DL3002), missing HEALTHCHECK (DL3057), shell-form CMD/ENTRYPOINT (DL3025), sudo (DL3004) and unguarded download pipes (DL4006).

Does my Dockerfile leave my browser?

No. The linter is pure JavaScript that runs locally. Your Dockerfile, including any private base-image registry names or build arguments, is never uploaded or logged.

Why does it warn about running as root?

By default a container process runs as root, which means a container escape grants root on the host namespace. Adding a non-root USER before the final CMD or ENTRYPOINT follows the principle of least privilege and is a baseline hardening step.

What is wrong with ADD for local files?

ADD has implicit behaviour — it auto-extracts local tar archives and can fetch remote URLs without verification. COPY does exactly one predictable thing: copy files into the image. Use COPY for local files and reserve ADD for the rare case where you genuinely want tar extraction.

Can it replace hadolint in CI?

It is a fast preview that catches the same common mistakes, but it does not implement every hadolint rule or its shellcheck integration. Keep hadolint in your CI pipeline for full coverage; use this tool for quick interactive checks while you edit.

Dockerfile Linter — Gera Tools

The Dockerfile Linter checks a pasted Dockerfile against widely-used best-practice and security rules — the same kinds of issues hadolint flags — and explains each finding so you can fix it. Everything runs in your browser.

How it works

The linter first tokenises the Dockerfile into instructions, joining lines that end with a backslash continuation and skipping comment lines. It then applies a rule set to each instruction and to the file as a whole:

Base image pinning — warns on untagged images and on the latest tag, which is not reproducible.
Package manager hygiene — flags apt-get install without --no-install-recommends, apt-get update in its own layer, missing apt list cleanup, and apk add without --no-cache.
Layer and path correctness — cd inside RUN (use WORKDIR), relative WORKDIR paths, and ADD where COPY is the safer choice.
Security — running as root at the final stage, use of sudo, and piping a curl/wget download straight into a shell without pipefail.
Runtime correctness — shell-form CMD/ENTRYPOINT (use the JSON exec form so signals are forwarded) and a missing HEALTHCHECK.

Example

A line like the following:

RUN apt-get update && apt-get install curl

triggers a warning to combine update and install in one layer and to add --no-install-recommends, plus a note to clean /var/lib/apt/lists in the same RUN so the image stays small.

Notes

Severities are advisory: error marks things that are almost always wrong, warning marks strong best practices, and info marks size or hardening optimisations. This linter is a quick preview — keep hadolint in CI for full rule coverage and shellcheck integration.