Why it matters
A Dockerfile that works can still be slow to build, large to ship and risky to run. Running as root, copying the whole repo before installing dependencies, or leaving the apt cache behind are easy mistakes that cost minutes on every build and megabytes on every deploy.
This linter parses the Dockerfile properly, follows each build stage, and checks rules in the spirit of hadolint, written for this site. Each finding has the line, why it matters and the change to make.
How it works
- InputA Dockerfile
- In your browserChecked with over 40 rules
- OutputFindings by line, with the fix
Where it fits in a designer's workflow
- Plan
- Design
- Build
- Test
- Launch
By the numbers
Show the numbers as a table
| Severity | Count |
|---|---|
| Error | 3 |
| Warning | 11 |
| Note | 9 |
How to use it
- Paste your Dockerfile, or use the example.
- Choose which levels of finding to show.
- Work through the findings by line.
- Re-paste the fixed file to check again.
FAQ
Is this hadolint?
No. It's this site's own rule set, inspired by hadolint and Docker's best-practice guide. It doesn't run shellcheck on RUN lines.
Why pin the base image?
A tag like node:latest changes under you. Pin a version, or better a digest (node:20@sha256:…), so builds are repeatable.
Why flag secrets in ENV?
ENV and ARG values are stored in the image history, where anyone with the image can read them. Use build secrets (RUN --mount=type=secret) instead.
Is my Dockerfile uploaded?
No. It's checked in your browser.
