We Built LayerX: A Modern Alternative to Dive

Devesh — Sun, 05 Jul 2026 14:12:10 +0000

For years, Dive has been one of the best tools for understanding Docker image layers.

It has helped thousands of developers answer questions like:

Why is my image so large?
Which layer introduced this file?
Where is all this wasted space coming from?

We've relied on Dive ourselves throughout countless debugging sessions. It's an excellent tool and has become a staple in the container ecosystem.

But over time, we found ourselves wanting more.

Not because Dive wasn't good enough—but because our workflows evolved.

That eventually led us to build LayerX.

⭐ GitHub: https://github.com/deveshctl/layerx

Why We Built LayerX

If you've worked with containers long enough, you've probably experienced something like this:

A Docker image suddenly grows by hundreds of megabytes.
A CI pipeline becomes noticeably slower.
Someone accidentally copies build artifacts into the final image.
You need to understand exactly what changed between two releases.

The usual debugging workflow looks familiar:

docker history
docker inspect
dive my-image

Eventually, you figure it out.

But we kept running into the same limitations:

Comparing two image versions wasn't straightforward.
Exporting analysis into automation pipelines required extra scripting.
Working directly with saved image archives wasn't always convenient.
We wanted image analysis to fit naturally into CI/CD.
We wanted richer inspection workflows without leaving the terminal.

Instead of building more helper scripts around existing tools, we decided to build something that solved these problems while keeping the workflow we already liked.

That project became LayerX.

Our Design Principles

Before writing any code, we agreed on three simple principles.

1. Familiar for Existing Dive Users

If someone already knows Dive, they shouldn't have to learn an entirely new workflow.

LayerX should feel immediately familiar.

2. Build Features Developers Actually Need

Not features that look impressive in a README.

Features we repeatedly wished existed while debugging real container images.

3. Make Automation Easy

Image analysis shouldn't stop on a developer laptop.

It should integrate naturally into modern CI/CD pipelines.

What LayerX Adds

LayerX keeps the interactive terminal experience while extending it with workflows we personally found useful.

Some of the highlights include:

Compare two container images — side-by-side diffs with deterministic verdicts
Export analysis as JSON — feed into dashboards, monitoring, and automation
Analyze Docker & OCI archives directly — no daemon required for offline analysis
Inspect any platform — amd64, arm64, arm/v7, and more on any host
Extract files directly from images — no temporary containers needed
Full-text file search — find files across all layers instantly
Waste navigation — jump directly to files consuming the most space
CI-friendly commands and exit codes — integrate naturally into GitHub Actions, GitLab CI, Jenkins

Our goal wasn't to replace Dive.

It was to build on top of the workflow we already loved.

Feature Comparison: LayerX vs Dive

Capability	Dive	LayerX
Interactive layer explorer	✅	✅
File tree inspection	✅	✅
Layer efficiency analysis	✅	✅
Compare images	❌	✅
JSON export	Limited	✅
Archive-first workflow	Partial	✅
Multi-platform inspection	❌	✅
File extraction	❌	✅
CI-friendly workflows	Basic	✅

For a complete comparison, see our migration guide:

📖 Migrating from Dive to LayerX

Feature Spotlight

🔄 Compare Two Images

One feature we kept wishing existed was a clean way to compare image versions.

Instead of manually inspecting two images, simply run:

layerx compare myapp:v1.4.0 myapp:v1.5.0

LayerX highlights:

Changed layers
Added and removed files
Size differences
Efficiency regressions

It's become one of our favorite features during release reviews.

📤 JSON Export for Automation

Need to automate image analysis?

layerx --json report.json nginx:latest

# Query with jq
jq '.layers[] | select(.wasted_bytes > 1e7) | {index, command, wasted_bytes}' report.json

The JSON output makes it easy to:

Generate dashboards and reports
Integrate into CI/CD pipelines
Build custom analysis tools
Feed into monitoring systems

Full schema and recipes available in the JSON export documentation.

📦 Analyze Archives Directly (No Daemon Required)

Sometimes you don't have access to a Docker daemon.

Maybe you're debugging an image from CI. Maybe you're working on an air-gapped machine.

LayerX works directly with image archives:

# Save an image locally
docker save myapp:latest > myapp.tar

# Analyze it anywhere, anytime
layerx myapp.tar

No Docker daemon. No registry. No network access needed.

Perfect for:

Air-gapped environments
CI runners without docker-in-docker
Offline analysis and auditing
Secure scanning before deployment

🌍 Inspect Multi-Platform Images

Modern images frequently support multiple CPU architectures (amd64, arm64, arm/v7, etc.).

LayerX lets you inspect whichever platform you want, on any host:

# Inspect the arm64 variant on your amd64 machine
layerx --platform linux/arm64 nginx:latest

# Compare the same image across architectures
layerx compare \
  --platform linux/amd64 myapp:1.5.0 \
  --platform linux/arm64 myapp:1.5.0

This makes it easy to catch architecture-specific bloat and efficiency regressions before deployment.

📂 Extract Files from Images

Sometimes viewing a file isn't enough.

LayerX lets you extract files directly from container images:

# Press 'x' on any file in the TUI
# Or extract programmatically
layerx extract myapp:latest /etc/config.yml

Why this matters:

Inspect binaries offline with strings, objdump, etc.
Retrieve configuration files without launching temporary containers
Audit file permissions and ownership
Works seamlessly over SSH and tmux

Built for CI/CD Integration

One thing we wanted from the beginning was making image analysis part of the delivery pipeline.

Instead of discovering image bloat after deployment, teams should catch regressions during pull requests.

For example:

layerx ci \
  --lowest-efficiency 0.95 \
  myapp:latest

If configured thresholds aren't met, LayerX exits with a non-zero status:

Exit code 0 — all checks passed
Exit code 1 — a rule failed (gate the build)
Exit code 2 — operational error (surface for review)

This makes it easy to integrate with:

GitHub Actions
GitLab CI
Jenkins
CircleCI
Any CI platform that respects exit codes

Installation

LayerX is a single static Go binary with no runtime dependencies.

macOS (Intel & Apple Silicon)

brew install deveshctl/tap/layerx

Windows

scoop bucket add layerx https://github.com/deveshctl/scoop-bucket
scoop install layerx

Linux (Debian/Ubuntu)

# amd64
curl -LO https://github.com/deveshctl/layerx/releases/latest/download/layerx_linux_amd64.deb
sudo dpkg -i layerx_linux_amd64.deb

# arm64
curl -LO https://github.com/deveshctl/layerx/releases/latest/download/layerx_linux_arm64.deb
sudo dpkg -i layerx_linux_arm64.deb

From Source (requires Go 1.26+)

go install github.com/deveshctl/layerx@latest

Lessons We Learned

Building a container image analyzer turned out to be far more interesting than we expected.

Some of the engineering challenges included:

Supporting both Docker and OCI image formats
Parsing compressed image layers efficiently
Keeping the TUI responsive for very large images (100GB+)
Making clipboard support work over SSH and tmux
Testing across Linux, macOS, Windows and multiple architectures (amd64, arm64, arm/v7)

Those lessons continue to shape the project today.

If You're Already Using Dive

First, thank you to the Dive project.

LayerX wouldn't exist without the ideas Dive introduced to the container ecosystem.

If Dive already fits your workflow perfectly, that's great.

But if you've ever wanted any of these features:

Image comparison — understand what changed between releases
JSON export — automate analysis and reporting
Archive support — work offline without a daemon
Better CI integration — gate builds on image efficiency
Multi-platform inspection — catch architecture-specific issues
Modern container workflows — adapt to how teams build today

we hope LayerX is worth trying.

We've written a complete migration guide to make switching straightforward: