Dockerfile Linter

How to use it

1. Paste or type a Dockerfile into the editor; the lint re-runs as you type, and an empty editor stays empty rather than guessing at a file.
2. Read the findings list top to bottom — each row names the line, the severity, the rule ID and what the rule saw.
3. Select a row to jump the editor caret to the offending line; the one-line fix that rule asks for is printed directly under the row.
4. Switch to Report (JSON) when you want the same result as machine-readable data to paste into a build log or an issue.
5. Check the exit code under the verdict card: 0 means no rule fired, 1 means at least one did, at any severity.

Paste a Dockerfile and this workbench checks it against 27 best-practice rules that carry hadolint-compatible IDs — DL3008, DL3059, DL4006 and the rest — then anchors every finding to the line that caused it. The lint runs in this tab, so the file never leaves the device. Devxcode is not affiliated with or endorsed by the hadolint project.

How it works

The first pass reads the file the way a builder reads it, not the way a regular expression does. Line continuations are joined before any rule runs, and the continuation character follows an `# escape=` parser directive when one is present. Comment and blank lines that fall inside a continuation are dropped, `FROM … AS name` records a stage alias, exec (JSON array) form is distinguished from shell form, and heredoc bodies — `<<EOF`, `<<-EOF`, quoted delimiters — are collected wherever they appear in the file rather than only at the end.

The second pass walks the parsed instructions. Shell-bearing RUN steps are cut into simple commands at `&&`, `;` and `|`, and each segment is word-split by the shared quote-aware tokenizer this repo already uses for its curl and compose tools. Command words are matched on their basename, so `/usr/bin/apt-get update` is examined exactly like `apt-get update`. When a segment cannot be tokenized — an unbalanced quote, usually — the shell-level rules for that one instruction are skipped and a note says so; the rest of the file is still linted.

Each rule that fires produces a record of `{code, line, column, level}` plus a plain-language sentence and the fix the rule wants. Column is always 1: findings anchor to the instruction, not to a character offset inside it. Findings are ordered by line, then by rule-table order, so two rules on the same instruction always print in the same sequence. The severity filter above the list is a view filter only. Any finding at all — including an info-level one such as DL3059 — makes the exit code 1; zero findings make it 0, and the filter never changes that number.

Known differences, stated plainly. This workbench checks 27 best-practice rules plus two shell checks, which is a subset of the upstream rule catalogue rather than all of it, so a clean result here means "none of these 27 fired". Heredocs are parsed anywhere in the file. Shell inspection is deliberately limited to two conservative cases, SC1010 and SC3014, because a false positive from a general shell analyser is worse than a missed one. Rule messages are written for this page; the IDs, severities and exit codes are what stay compatible.

Examples

FROM debian:12
RUN apt-get update && apt-get install -y --no-install-recommends curl && rm -rf /var/lib/apt/lists/*
CMD ["bash"]

line 2  warning  DL3008  An apt-get install package has no version, so rebuilds can pick up a different release.
exit code 1 · 3 instructions · 1 stage · 27 rules checked

FROM debian:latest
RUN echo step-one
RUN echo step-two
CMD ["bash"]

line 1  warning  DL3007  This base image is pinned to latest, so the build changes whenever the tag moves.
line 3  info     DL3059  This RUN follows another RUN with nothing between them, so the build makes two layers.
exit code 1 · 4 instructions · 1 stage · 27 rules checked

FROM golang:1.22-alpine AS build
WORKDIR /src
COPY main.go /src/main.go
RUN CGO_ENABLED=0 go build -o /out/server main.go

FROM alpine:3.19
COPY --from=build /out/server /usr/local/bin/server
USER 65534:65534
ENTRYPOINT ["/usr/local/bin/server"]

No findings.
exit code 0 · 8 instructions · 2 stages · 27 rules checked

FROM debian:12
RUN curl -fsSL https://example.com/install.sh | sh
CMD ["bash"]

line 2  warning  DL4006  This RUN pipes one command into another without pipefail, so a failure on the left is ignored.
exit code 1 · 3 instructions · 1 stage · 27 rules checked

Every example on this page is executed against the same engine that powers the tool, on every build.

Common errors

This Dockerfile is 262147 characters, over the 262144-character (256 KiB) limit for this tool. Lint a smaller file, or split it.

The refusal names the size it measured and the cap it applies, both in characters. Nothing is linted in this state and no partial list is shown. Splitting a generated multi-stage file at a stage boundary, or linting the stage you are editing, is the usual way through.

This report lists the first 200 findings of 260; fix some and lint again to see the rest.

The list is capped at 200 rows and the note appears only when a 201st finding genuinely went unlisted, so the count it quotes is real. The exit code is still computed from the whole set, and the severity filter is a good way to work through a long list in passes.

Shell-level rules were skipped for the instruction on line 2: its quoting could not be resolved.

An unbalanced quote inside a RUN makes its word boundaries ambiguous, so the rules that read command words are skipped for that one instruction rather than guessed at. Everything else in the file is still linted, and the instruction-level rules still apply to that line.

Keyboard shortcuts

/

Focus the Dockerfile pane

⌘/Ctrl + S

Download the active tab's artifact

⌘/Ctrl + C

Copy the active artifact with an empty selection

⌘/Ctrl + Shift + C

Copy the active artifact

t

Cycle the color theme

? or ⌘/Ctrl + /

Open this shortcut list

Esc

Close dialogs