Find where an image's size came from. Paste the output of docker history, ideally with --no-trunc so the commands are not cut off.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Analyze. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
Two layers, both kept, and the second saved nothing at all
IMAGE CREATED CREATED BY SIZE abc123 2 days ago /bin/sh -c apt-get install -y build-essential 280MB <missing> 2 days ago /bin/sh -c rm -rf /var/lib/apt/lists/* 0B <missing> 2 days ago /bin/sh -c #(nop) COPY dir:abc in /app 12MB
Readable by anybody who can pull, and reported here by name only
<missing> 1 day ago |1 NPM_TOKEN=REPLACE_ME /bin/sh -c npm ci 40MB
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
The files are already in an earlier layer. The cleanup adds a layer recording deletions and changes the download size not at all.
Instead:Do the install and the cleanup in one RUN joined with &&, or use a multi-stage build.
It is what every pulled image looks like below the top layer, because parent ids are not transferred by a pull.
Instead:Ignore it. Build locally if you need the intermediate ids for something.
History is extracted size and the registry reports compressed blobs. They measure different things.
Instead:Use history for disk and the manifest for pull time.
A file added in one layer and removed in a later one is still in the image and still downloaded on every pull. The removal only hides it from the filesystem view.
RUN install, RUN build, RUN clean-up produces three layers, and the cleanup layer records deletions without removing the bytes. The same commands joined with && in one RUN produce one layer that never contained the intermediate files. That difference is routinely hundreds of megabytes.
Build in one stage and COPY only the artefact into a clean final stage. Nothing from the build stage is in the final image at all, so there is nothing to clean up and no history to leak.
Intermediate image ids are only kept for images built locally. For anything pulled from a registry the parent ids are not transferred, so every layer below the top shows <missing>. It does not mean anything is absent or corrupt.
docker history reports what the layer occupies on disk. The manifest reports the compressed blob, which is what crosses the network. The two never agree and neither is wrong.
docker history is exactly this data, so anybody who can pull the image can read it. The value is recorded whether or not the file it wrote survived, which is why a later cleanup does not help.
The default output shortens the command column to fit the terminal, which usually removes the part that explains the size, and hides anything further along the line.