Dive is a simple but powerful way to understand what is inside your Docker or OCI images. It lets you browse each layer, see added and removed files, measure wasted space, and score your image efficiency so you can cut size, speed up pulls and deploy faster.
What is Dive
Dive is an open source terminal UI for analyzing container images. It reads layers from Docker Engine, Podman, or archives, then shows a side by side view of layers and filesystem contents. You immediately see which Dockerfile steps create the biggest layers and where cleanup is missing.
Thanks Lior who made me discover this tool.
Why image size matters
- Faster CI and deployments due to smaller pulls and pushes
- Lower bandwidth and registry storage usage
- Reduced attack surface by removing tools not needed at runtime
- Better developer experience when iterating frequently
Quick install
You can install Dive from GitHub releases or package managers. Common options:
- macOS:
brew install dive
- Debian or Ubuntu: download the
.deb
from the releases page and install withsudo apt install ./dive_*.deb
- Fedora or RHEL: use the
.rpm
release withsudo rpm -i dive_*.rpm
- Container only: run the official image and mount your Docker socket or analyze an image archive
Basic usage
# Inspect an existing image
dive your-image:tag
# Build then analyze in one go
dive build -t your-image:tag .
# Non interactive CI output
CI=true dive your-image:tag
# Choose a different source if needed
dive --source podman your-image:tag
What the interface shows
- Layers list: each Dockerfile step and its size
- File tree: browse the combined filesystem at any layer depth
- Changes: additions, modifications, deletions between layers
- Efficiency score: how much of the image is real content vs waste
- Wasted bytes: duplicates, cache leftovers, files added then removed later
How to reduce image size using Dive findings
- Use a minimal base image: alpine, slim, or distroless if appropriate
- Add a .dockerignore: exclude build directories, local artifacts, tests, and temporary files
- Combine RUN commands: install and cleanup in the same layer to avoid leaving caches behind
- Use multi stage builds: compile in one stage, copy only the final binary or assets into a tiny runtime stage
- Avoid COPY . . when it is too broad: copy only what you really need
- Prune package manager metadata: for example remove
/var/lib/apt/lists
,/var/cache/apk
, or build caches - Put frequently changing layers later: improves cache reuse and rebuild speed
Example Dockerfile before and after
Before
FROM node:20
WORKDIR /app
COPY . .
RUN npm install
RUN npm run build
CMD ["node", "server.js"]
After using Dive insights
# Build stage
FROM node:20 as build
WORKDIR /app
# copy only files needed to install dependencies first
COPY package*.json ./
RUN npm ci
# then copy the rest
COPY . .
RUN npm run build
# Runtime stage
FROM node:20-slim
WORKDIR /app
ENV NODE_ENV=production
COPY --from=build /app/dist ./dist
COPY --from=build /app/package*.json ./
RUN npm ci --omit=dev && npm cache clean --force
# optional: add user and drop root if possible
CMD ["node", "dist/server.js"]
With Dive you will see fewer and smaller layers, no node modules from development in the final image, and package caches removed.
CI integration
Gate your builds with a small configuration file. Example:
# .dive-ci
rules:
lowestEfficiency: 0.90
highestWastedBytes: 20000000
highestUserWastedPercent: 5
# In your pipeline
CI=true dive your-image:tag
# Non zero exit code if thresholds are violated
FAQ
- What does Dive actually analyze
- It analyzes each layer of a Docker or OCI image, showing the files added or removed, total size per layer, and an efficiency score.
- Can I use Dive with Podman
- Yes. Use the
--source podman
option or analyze from an image archive. - Does Dive modify images
- No. It is read only. It helps you decide what to change in your Dockerfile.
- How is efficiency calculated
- Efficiency compares required unique content to waste like duplicates, cache artifacts, and files that persist across layers unnecessarily.
- Is there a way to fail a build if the image is too large
- Yes. Set
CI=true
and thresholds in a.dive-ci
file so Dive returns a failing status when limits are exceeded. - What are common sources of wasted space
- Package caches, temporary files, duplicate dependencies, artifacts left from building, and files that are copied broadly from the host.
- Should I always use Alpine
- Not always. Alpine is small but can cause compatibility issues. Slim or distroless can be better for some stacks. Test carefully.
- How does .dockerignore help
- It shrinks the build context so large or irrelevant files never enter the image, which directly reduces layer size for COPY steps.
- Can Dive analyze image tar archives
- Yes. Export an image to a tar archive and use the appropriate source flag to analyze it.
- What is the quickest win to reduce size
- Use multi stage builds to keep only the runtime artifacts and clean package caches in the same layer where they were created.