Dockerfile Linter
Catch Dockerfile mistakes before they ship — pinned tags, COPY vs ADD, layer caches, root users and more.
Runs in your browser Hadolint-inspired rules Severity-tagged findings
Errors
1
Warnings
6
Info
5
L1DL3006Always tag the base image (avoid implicit :latest)
L2DL4000MAINTAINER is deprecated — use LABEL maintainer=… instead
L3DL3000WORKDIR should use absolute paths
L4DL3020Use COPY instead of ADD for files and directories
L5DL3016Prefer `npm ci` for reproducible installs in production images
L6DL3009apt-get update should be combined with apt-get install in the same RUN to avoid stale cache layers
L7DL3014Use the -y flag with apt-get install
L7DL3015Add --no-install-recommends to keep image small
L7DL3009Append `&& rm -rf /var/lib/apt/lists/*` after apt-get install to shrink the layer
L8DL3045Avoid `COPY . .` without WORKDIR or .dockerignore — bloats the image
L9DL3002Avoid running as root — switch to a non-root user
L11DL3025CMD should use the JSON array form for proper signal handling
Inspired by hadolint best practices. Linting runs entirely in your browser — your Dockerfile is never uploaded.
What it checks
Best-practice rules
Pinned base tags, deprecated MAINTAINER, sudo, apt-get layer-cache, ADD vs COPY, JSON-form CMD/ENTRYPOINT, non-root USER and more.
Errors, warnings, info
Each finding is tagged by severity with a hadolint-style rule code so you can cross-reference your CI pipelines.
Never uploaded
Linting runs locally. Your Dockerfile and any build secrets remain in your browser.
Frequently Asked Questions
Quick answers about the Dockerfile linter.
Need help containerizing or hardening your build pipeline? Talk to NETIUS →