Which package is bloating your Docker image?

mk668a Posted on May 25 Which package is bloating your Docker image? # docker # go # opensource # devops layer-blame is git blame for image layers — it names the package responsible for every byte. Here's what it prints when you point it at a stock Alpine image: $ docker save alpine:3.20 -o alpine.tar $ layer-blame alpine.tar Image total: 8.4 MB across 1 layers · package attribution: 100% Layer 0 8.4 MB ADD alpine-minirootfs-3.20.10-aarch64.tar.gz / 4.8 MB libcrypto3 pkg ← largest line highlighted 911.7 KB libssl3 pkg 906.0 KB busybox pkg 706.5 KB musl pkg 327.1 KB apk-tools pkg Enter fullscreen mode Exit fullscreen mode Every byte in that layer now has an owner. libcrypto3 is 4.8 of the 8.4 MB. That's the whole pitch: it's git blame , but the blamed thing is the package responsible for a layer's size. The gap it fills You already have two tools for image size, and between them there's a hole. docker history tells you that a layer is 95 MB. It will not tell you what's in it. dive (~54k⭐) lets you browse what's in it — file by file, interactively. It answers what is in a layer. Neither answers the question you actually walked up with: "which package put those bytes here?" So the standard ritual is: read docker history for the fat layer, open dive , eyeball the tree, and guess. People have asked dive for package-level breakdown directly — see dive#291 , open for years. layer-blame JOINs each layer's added files against the image's own package databases — apk for Alpine, dpkg for Debian/Ubuntu — and attributes every byte to a package. It's not a browser. It's a non-interactive report you can paste into a PR or wire into CI. dive for browsing, layer-blame for attribution. They're complementary. Where do Python's 137 MB actually go? This is the example that sold me on building it. python:3.12-slim is famously chunky. Here's the breakdown: $ docker save python:3.12-slim -o py.tar $ layer-blame --top 5 py.tar Image total: 137.7 MB across 4 layers · package attribution: 69%