Dockerfile Lint and Format Online: A Practical Hadolint Guide
Catch Docker anti-patterns and format Dockerfiles before CI with browser-based lint and format tools.
Why lint and format a Dockerfile before CI?
A Dockerfile builds your image layer by layer. A forgotten `USER root`, a floating `latest` tag, or cascading `RUN` steps bloat the image, hurt BuildKit cache hits, and fail Hadolint in CI — often too late. Formatting and linting before you open the PR cuts pipeline noise and keeps the team on the same conventions. On FastMinify you can lint a Dockerfile online (Hadolint-style DL rules) and format a Dockerfile online — fully in the browser. The full cluster lives on the online DevOps tools hub, next to Terraform, Compose, and `.env`.
Common DL rules and pre-PR workflow
A few codes show up in almost every team. Fixing them early avoids a wall of Hadolint warnings in CI.
Pin Hadolint (image or binary) and fail the pipeline on your severity policy. The browser remains a fast filter outside the monorepo.
Lint vs format vs build
Format, lint, and `docker build` complement each other. In review: format, lint, then let CI build.
Goal
When to use it
A simple sequence avoids fixing style after lint in a loop.
When the browser tool is enough
You do not need to clone the monorepo to fix three instructions pasted from Slack.
Limits: what the browser does not replace
As soon as you need team config (ignores, severity), deep shell analysis in RUN, or multi-stage builds with BuildKit secrets, the CLI and CI remain mandatory.
A service often ships with Compose, `.env`, and HCL. Dockerfile format/lint + Compose/env validate + Terraform format cover the daily DevOps path.
CLI and ecosystem
Hadolint and dockerfile-utils remain the enterprise standard. FastMinify tools complement exploration and one-shots.
Hadolint
Reference Dockerfile linter with DL rules and CI integration.
Pros:
Cons:
dockerfile-utils / formatters
Style normalization (casing, spacing) in the editor or CLI.
Pros:
Cons:
BuildKit / buildx
Modern build engine: cache, multi-platform, secrets.
Pros:
Cons:
Dockerfile anatomy: instructions and layers
A Dockerfile is a sequence of instructions (`FROM`, `RUN`, `COPY`, `WORKDIR`, `USER`, `CMD`…). Instructions that mutate the filesystem create layers. Order matters for cache: frequent changes (app code) should come after stable layers (OS packages). For neighbouring YAML (`compose.yml`), validate structure before `docker compose up`.
FastMinify's linter applies a <strong>documented subset</strong> of Hadolint DL rules (wiki IDs). It does not run ShellCheck inside every `RUN`, does not build the image, and does not talk to a remote registry. In CI, Hadolint CLI (or the GitHub Action) remains the team source of truth.
Lint and format: two distinct intents
The linter reports issues with DL codes (e.g. DL3007 for `latest`, DL3002 for final root user) and Hadolint wiki links. Ideal for pasting a Dockerfile and fixing it before the PR. Try the online Dockerfile linter.
The formatter normalizes instruction casing and spacing for stable diffs — without changing build semantics. Use the online Dockerfile formatter before committing a hand-edited file.
A Dockerfile rarely ships alone. Also validate Docker Compose online and check `.env` files before a local deploy.
Conclusion
Linting and formatting a Dockerfile before CI avoids wasted round-trips on DL rules and style. Use the browser for snippets and a first Hadolint-style filter, then Hadolint CLI and `docker build` for pipeline truth. Continue with Compose, `.env`, and Terraform on the same DevOps hub.
Related Articles
Format and validate HCL/Terraform before `terraform plan`. Browser-based tools, IaC best practices and common pitfalls.
Optimize your WordPress site with JavaScript, CSS and HTML minification. Plugin comparison, configuration and tips for an ultra-fast WordPress.
Learn how to integrate JavaScript and CSS minification into your CI/CD pipelines. Concrete examples with GitHub Actions and GitLab CI for optimized deployments.