The usual way to catch a cache-busting Dockerfile is to read it top to bottom during code review and notice anything that looks wrong. That works well for the textbook case — a five-line Dockerfile with COPY . . sitting right above RUN npm ci. It works much less well the moment catching the mistake requires tracking state across the whole file: which manifest was copied where, whether an install command ever got an isolated copy at all, or whether a later instruction silently depends on an earlier one several lines up.
Reviewing a Dockerfile by eye is free and needs no tool: read it start to finish and flag anything that looks off. It works well on short, single-stage Dockerfiles where the mistake is right next to its cause.
This checker tracks, per build stage, every manifest copy and every install command it has seen so far and reports exactly which instruction pairs violate the ordering — the bookkeeping a read-through has to do silently, in your head, across however many lines and stages the file has.
| Question | Where to answer it |
|---|---|
Is a COPY . . sitting right above the install command, in an otherwise short Dockerfile? | Either one. A read-through catches this at a glance, and so does this checker. |
| Was the manifest ever copied on its own, anywhere in the file, or only ever inside a broad copy? | This checker. Answering this by eye means cross-referencing every COPY's source list against every install command's ecosystem across the whole file. |
Does a later RUN apt-get install quietly rely on an earlier, separately-cached apt-get update? | This checker. Neither line looks wrong read on its own — the split is only visible across the two. |
| Does a broad copy in an unrelated build stage matter here? | This checker, which resets its state at every FROM. By eye, "there's a COPY . . somewhere in this file" can read as a red flag regardless of which stage it is actually in. |
| Is anything I enter uploaded anywhere? | Neither. A read-through involves no tool at all, and this checker runs entirely in your browser. |
COPY . . before npm install obvious just from reading the file?When the whole Dockerfile is five lines and the COPY . . is right above the install, yes. It stops being obvious the moment the file has multiple stages, several COPY instructions for different purposes, or the manifest copy and the broad copy are separated by other instructions — catching it by eye then means tracking, in your head, which lines named which files and in what order, across the whole file, which is exactly the kind of bookkeeping a deterministic scan does better than a read-through.
Two things this checker reports that a read-through has no natural way to surface. First, whether an install command ever has an isolated manifest COPY anywhere in the file, as opposed to only ever seeing the manifest bundled inside a broad copy — that requires tracking every COPY's sources against every install command's ecosystem, not just scanning for an obviously misplaced line. Second, whether a RUN apt-get update earlier in the file is the only update backing a RUN apt-get install several lines later — a split that looks completely ordinary read top to bottom, because nothing about either line looks wrong in isolation.
Yes, more than it first appears. Each FROM starts a fresh build stage with its own cache lineage, so a broad copy in an earlier stage that is never cache-sensitive (a throwaway builder stage, say) says nothing about a later stage's own instruction order — but by eye, seeing COPY . . anywhere in the file can read as a red flag regardless of which stage it is in. This checker resets its state at every FROM for exactly that reason.
There is nothing to upload either way — reviewing a file by eye involves no tool at all, and this checker runs entirely in your browser against the text you paste in. The CLI makes no network call either; it only reads files already on your own disk.