Docker Tools That Pay for Themselves

Updated 2026-03-27 · SPUNK13 · Back to spunk.bet

These are the Docker tools that return their setup time within a week, mostly by cutting image size and build time — which are the two things that quietly cost you on every deploy.

dive: find the wasted layers

docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive myimage:latest opens a layer-by-layer browser showing which files each layer added and how much space is wasted by files added in one layer and deleted in a later one. That pattern — apt-get install followed by rm -rf /var/lib/apt/lists/* in a separate RUN — is invisible in docker images and often accounts for a hundred megabytes. dive also reports an efficiency score and can fail CI below a threshold with CI=true dive --ci myimage.

hadolint: a linter for your Dockerfile

docker run --rm -i hadolint/hadolint < Dockerfile catches the classics: unpinned base image tags, apt-get install without --no-install-recommends, missing USER so the container runs as root, ADD where COPY belongs, and cd in a RUN instead of WORKDIR. It runs in under a second and every rule maps to a real problem.

BuildKit cache mounts: the biggest single build-time win

Package manager caches are normally thrown away between builds. Cache mounts persist them without putting them in the image:

# syntax=docker/dockerfile:1
FROM node:22-slim
WORKDIR /app
COPY package*.json ./
RUN --mount=type=cache,target=/root/.npm npm ci
COPY . .

Combined with copying the manifest before the source — so a code change does not invalidate the dependency layer — this typically takes a rebuild from a minute to a few seconds. Use --mount=type=secret for build-time credentials rather than build args, which are visible in the image history forever.

Multi-stage builds and distroless bases

Build in a full image, ship only the artifact. A Go binary in gcr.io/distroless/static is a few megabytes against several hundred for a build image. For interpreted languages, -slim variants over the default and Alpine where the libc difference is acceptable. The payoff is not disk — it is pull time on every deploy and every node, and a smaller attack surface because there is no shell in the image.

Trivy: vulnerability scanning that fits in CI

trivy image --severity HIGH,CRITICAL --exit-code 1 myimage:latest scans OS packages and language dependencies and fails the build on serious findings. It also scans Dockerfiles and IaC for misconfiguration and detects committed secrets. Scan the base image before you adopt it — choosing a base with fewer preinstalled packages removes more vulnerabilities than any amount of patching later.

Compose and the small quality-of-life wins

• docker compose watch syncs source into a running container and restarts on change, replacing hand-rolled bind-mount setups.
• docker system df then docker system prune -a --volumes — build caches routinely consume tens of gigabytes on a developer machine.
• docker buildx build --platform linux/amd64,linux/arm64 builds multi-architecture images in one command, which matters now that developer laptops and servers frequently differ.
• docker slim build analyses a running container and strips everything unused; the size reduction can be dramatic, though it needs testing because it can remove something used only on a rare code path.
• A HEALTHCHECK instruction, so orchestrators know the difference between running and working.

The arithmetic

An image going from 900 MB to 120 MB saves pull time on every deploy, every autoscale event and every CI job. On a service deploying a few times a day across several nodes, that is minutes of pipeline time daily and a measurable reduction in registry storage and egress. The tooling above takes an afternoon to set up once.