DEV Community

Devesh
Devesh

Posted on

We Built LayerX: A Modern Alternative to Dive

#docker #go #opensource #devops

LayerX terminal user interface showing two-pane split view: left pane displays Docker image layers with size and efficiency metrics, right pane shows the file tree with color-coded changes (green for added, yellow for modified, red for removed files)

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Windows 

scoop bucket add layerx https://github.com/deveshctl/scoop-bucket
scoop install layerx
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

From Source (requires Go 1.26+) 

go install github.com/deveshctl/layerx@latest
Enter fullscreen mode Exit fullscreen mode

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:

📖 Migrating from Dive to LayerX

What's Next?

We're actively working on:

  • Better comparison capabilities
  • Performance improvements for massive images
  • Additional export formats
  • More CI integrations
  • Continued improvements driven by community feedback

As always, we're listening to feature requests and pull requests.

We'd Love Your Feedback

LayerX is completely open source, and we're actively maintaining it.

Whether you find a bug, have a feature idea, or simply want to share your workflow:

If you find the project helpful, consider giving it a ⭐. It genuinely helps other developers discover the project.

Thanks for reading, and happy container debugging! 🚀

Quick Links

Top comments (0)