Layer-blame attributes Docker image bytes to specific packages

This review examines layer-blame, a new tool for Docker image layer attribution, comparing its functionality against existing tools like docker history and dive. We detail its value proposition for image optimization.

TL;DR

Best for: Identifying package-level bloat in Docker images, integrating into CI/CD pipelines for automated size monitoring, and debugging unexpected image growth. Skip if: You require an interactive file browser for exploring image contents, or your primary need is only high-level layer size information without package attribution. Bottom line: layer-blame provides unique, package-level byte attribution for Docker images, effectively filling a critical gap left by existing tools and offering actionable insights for image optimization.

METHODOLOGY

This v0 review draws on the founder's published claims in a dev.to blog post, accessed on May 25, 2026. Independent benchmarks are pending. Update cadence: re-tested when claims diverge from observed behavior.

The tool under review is layer-blame, as described in the source signal. The specific version is not explicitly stated in the blog post, so we assume it reflects the current public release at the time of publication. This review covers the tool's core functionality as described by the founder, its stated purpose, and the concrete output examples provided for Alpine and Python images. We analyze its mechanism for package-level byte attribution and its positioning relative to docker history and dive.

What is NOT covered in this v0 review includes independent performance benchmarks on various image sizes, long-term workflow integration experiences, or an exhaustive analysis of edge cases beyond the Alpine and Python examples presented. Our assessment is based solely on the founder's claims and public artifacts linked in the source.

WHAT IT DOES

Package-level byte attribution

layer-blame operates on the principle of git blame but applies it to Docker image layers. When pointed at a docker save tarball, it analyzes each layer and attributes every byte to its originating package. For example, on a stock Alpine image, it can report that "4.8 MB libcrypto3 pkg" is the largest contributor to a layer's size, providing a clear, actionable target for optimization.

Non-interactive reporting

Unlike interactive tools such as dive, layer-blame is designed to produce a non-interactive report. This output format is suitable for pasting into pull requests or integrating directly into continuous integration (CI) pipelines. The tool's output is structured to highlight the largest contributors, making it easy to identify bloat without manual exploration.

Package database integration

The tool achieves its package attribution by joining each layer's added files against the image's own package databases. It supports apk for Alpine-based images and dpkg for Debian/Ubuntu-based images. This direct integration with the image's package management system allows for precise byte-to-package mapping.

Identifies non-package files

A key insight layer-blame provides is its ability to distinguish between bytes belonging to installed packages and those that are build artifacts or other files. In the python:3.12-slim example, it correctly identifies that large contributors in certain layers are specific files like /usr/local/lib/libpython3.12.so.1.0, rather than a dpkg package. This indicates when an image compiles software from source, making its weight attributable to build outputs, not just installed packages.

WHAT'S INTERESTING / WHAT'S NOT

What's interesting about layer-blame is its direct approach to solving a long-standing pain point in Docker image optimization. The tool explicitly addresses the gap between docker history (which provides layer sizes) and dive (which offers interactive file browsing). Neither of these existing tools directly answers the question, "which package put those bytes here?" layer-blame fills this with concrete, package-level attribution, a feature users have requested from dive for years, as evidenced by dive#291.

The ability to attribute bytes to specific packages like "4.8 MB libcrypto3 pkg" or "22.5 MB libc6 pkg" is a meaningful improvement over simply knowing a layer is 95 MB. This level of detail is actionable for developers looking to slim down images. Furthermore, its capacity to identify when bytes are build artifacts rather than installed packages (e.g., compiled Python binaries) is crucial for understanding the true composition of slim or custom-built images. The non-interactive report format is a smart design choice, making it easy to integrate into automated workflows and PR checks, moving beyond manual inspection.

What's not covered or could be expanded upon is the tool's support for package managers beyond apk and dpkg. Many images use rpm (Fedora/CentOS), pacman (Arch Linux), or conda (data science images). The current scope limits its applicability. There's also no mention of how layer-blame handles multi-stage Docker builds, where layers from different stages might contribute to the final image in complex ways. While it identifies non-package files, the mechanism for attributing these to a specific source (e.g., which RUN command created them) isn't detailed, which could be useful for debugging complex build steps. Finally, the blog post does not provide any performance metrics, leaving open questions about its speed on very large or deeply layered images.

PRICING

layer-blame is presented as an open-source tool, implying it is free to use. (Pricing snapshot date: 2026-05-25)

VERDICT

layer-blame is a highly focused and valuable utility for any developer or team serious about optimizing Docker image sizes. It directly addresses the critical need for package-level byte attribution, a capability that docker history and dive do not provide. For teams struggling with bloated images and performing the ritual of guessing package origins, layer-blame offers a precise, data-backed answer. It is best suited for integration into CI/CD pipelines to proactively monitor and report on image size contributions, especially for images built on Alpine or Debian/Ubuntu. While it doesn't replace interactive tools for file browsing, it complements them by providing the missing piece of package-level blame. We recommend layer-blame for anyone needing to systematically debug and reduce Docker image bloat.

WHAT WE'D TEST NEXT

Our next steps would involve benchmarking layer-blame against a diverse set of Docker images, including those with many layers and very large total sizes, to assess its performance characteristics. We would also test its compatibility and accuracy with images built using other common package managers like rpm or pacman. Investigating its behavior with complex multi-stage Dockerfiles and custom build systems would be crucial to understand its limits. Finally, we would explore how layer-blame could be integrated into various CI platforms (e.g., GitHub Actions, GitLab CI) to provide automated, actionable feedback on image size changes within pull requests.