jarvisbox

Dockerfile Linter

Paste your Dockerfile below and get instant feedback on best-practice violations and common mistakes. Runs entirely in your browser — your config is never uploaded.

100% client-side · no upload

Results

Click "Lint Dockerfile" to see results.

How to use the Dockerfile linter

  1. Paste your Dockerfile into the editor on the left.
  2. Click Lint Dockerfile to analyse it.
  3. Review each warning — hover over any rule name for a quick explanation.
  4. Fix the issues in your editor and re-lint until no warnings remain.
  5. Add Hadolint to your CI pipeline for automated enforcement on every pull request.

Common use cases

Related tools: GitHub Actions Linter · NGINX Config Formatter · .env Formatter · All DevOps Tools

Frequently Asked Questions

What rules does the Dockerfile linter check?
The linter checks for: FROM as the first instruction, pinning image tags (avoid latest), using COPY over ADD for local files, combining RUN instructions to reduce layers, setting a non-root USER, using WORKDIR instead of cd, avoiding sudo, specifying EXPOSE for used ports, and labelling images with LABEL.
Is my Dockerfile sent to a server?
No. All linting runs entirely in your browser using JavaScript. Your Dockerfile — including any secrets or hostnames it may reference — never leaves your device.
Why should I avoid the latest tag?
The latest tag is mutable: it resolves to a different image digest each time you pull. Pinning to a specific version (e.g. node:20-alpine) makes builds reproducible and prevents unexpected breakage when the upstream image is updated.
Why combine RUN instructions?
Each RUN instruction creates a new layer in the image. Chaining commands with && reduces the total layer count, which shrinks image size and speeds up pulls. Clean up package caches in the same RUN layer to avoid bloat.
Why use COPY instead of ADD?
ADD has extra behaviour — it extracts archives and can fetch remote URLs — which makes it unpredictable for simple file copies. COPY is explicit: it only copies local files and directories, making Dockerfiles easier to reason about.
Why set a non-root USER?
Running containers as root amplifies the blast radius of a container escape exploit. A non-root USER instruction ensures processes inside the container run with minimal privileges, which is a basic defence-in-depth measure.
Does this linter replace Hadolint?
No — it complements it. This tool is for quick in-browser checks during development. Hadolint covers more rules and should be added to your CI pipeline for authoritative enforcement.
What is the difference between ENTRYPOINT and CMD?
ENTRYPOINT defines the executable that always runs; CMD provides its default arguments. Together they let you build a container that behaves like a CLI: docker run myimage --flag overrides CMD but keeps the ENTRYPOINT binary.
Report a problem with this tool