Docker Desktop on macOS has an unusual relationship with disk space: everything it manages — images, containers, volumes, build cache — lives inside a single virtual disk file, and the tooling for cleaning up inside that disk is quite good, while the tooling for shrinking the disk file itself afterward is genuinely limited. Understanding the split matters, because running the right cleanup command and still seeing no change in Finder is one of the most common points of confusion for Docker users on Mac.

The four things taking up space

Docker Desktop tracks disk usage in four categories, visible under Docker Desktop → Settings → Resources → Advanced, or from the command line:

docker system df
  • Images — every image you've pulled or built, including intermediate layers from multi-stage builds.
  • Containers — the writable layer for each container, including stopped ones you haven't removed.
  • Volumes — named volumes, which persist data outside a container's lifecycle (databases are the most common use).
  • Build cache — layers cached by docker build (or docker buildx) so unchanged steps in a Dockerfile don't get rebuilt every time.

Run docker system df -v for a per-item breakdown, which is the fastest way to find the one image or volume that's disproportionately large.

docker system prune, escalated

The base command:

docker system prune

removes stopped containers, dangling images (layers with no tag, usually left over from rebuilds), unused networks, and the build cache — but it deliberately leaves anything still referenced by a tag, and leaves all volumes alone regardless of whether they're in use, since volumes often hold data people don't want deleted casually.

The escalated version:

docker system prune -a --volumes

removes all images not currently used by a running container (not just dangling ones — this includes tagged images you pulled once and haven't used since), and removes all volumes not attached to a running container. This is a meaningfully more aggressive command, and it is the one that actually recovers most of the space Docker has accumulated over months of pulling images for different projects.

Before running the --volumes version, be certain you don't have a stopped container whose data you need in an unattached volume — a local Postgres container you spun up for a project you haven't touched in weeks, for instance. docker volume ls shows every volume; cross-reference against docker ps -a (which shows stopped containers too) before pruning if you're not sure.

Why the disk usage in Finder doesn't match what you just freed

Here is the part that catches almost everyone: after running docker system prune -a --volumes and confirming with docker system df that Docker itself now reports very little space in use, the actual file on your Mac's disk — the virtual machine's disk image — often does not shrink to match.

Docker Desktop on macOS runs a lightweight Linux virtual machine to host the container runtime (macOS cannot run Linux containers natively), and everything Docker manages lives inside that VM's virtual disk file, Docker.raw, located at ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw. This file grows as you use Docker, but shrinking it back down after deleting the data inside is a separate operation that the filesystem doesn't do automatically — deleting a file inside a virtual disk frees space inside that disk, not on your Mac's actual disk, unless something explicitly reclaims it.

Newer Docker Desktop versions do periodic or triggered reclamation of this kind, but it is not instantaneous or guaranteed after every prune, which is why du -sh on Docker.raw right after a big prune can still show the file at its previous size.

What actually shrinks Docker.raw

This is significant enough that it has its own detailed guide — the short version is that the Disk image size slider in Docker Desktop's settings sets a ceiling, not a target, and moving it down does not shrink an already-large file. The reliable way to reclaim the space is Troubleshoot → Clean / Purge data, or in more stubborn cases, a full Reset to factory defaults, which discards the entire virtual disk and starts fresh — meaning every image and volume needs re-pulling or recreating afterward.

If you rely on Docker daily and can't afford to lose everything, export anything you need first: docker save for images you don't want to re-pull, and a volume backup (mounting the volume into a temporary container and copying its contents out) for any data in a named volume.

Build cache from BuildKit can grow independently of everything else

If your Dockerfiles use multi-stage builds or you've enabled BuildKit (the default backend in current Docker Desktop versions), it's worth knowing that build cache is tracked and pruned separately from images and containers, and it can grow substantially on its own for projects with frequent rebuilds. Every layer BuildKit has ever cached for a docker build — including layers from builds that failed partway through, or from a Dockerfile that was later changed so the cached layer is no longer reachable from any current build — counts against the total until pruned.

docker builder prune -a

clears all of it, not just dangling entries, which is the more thorough equivalent of docker builder prune on its own (which, like docker system prune, is conservative by default). For CI runners building the same images repeatedly, keeping this cache warm across builds is usually the whole point — clear it only when you specifically suspect a corrupted cache layer or want to force a fully clean rebuild for verification purposes.

Keeping it from growing back unmanaged

A few habits keep Docker's footprint predictable rather than surprising:

  • Run docker system prune -a --volumes periodically rather than waiting for disk pressure to force the question — monthly is reasonable for active Docker users.
  • Use docker image prune -a on its own if you specifically want to clear old images without touching volumes.
  • Be deliberate about docker build layer caching on projects with large dependency installs (a Dockerfile step that reinstalls node_modules on every build inflates the build cache fast); docker builder prune clears just the build cache.
  • Consider whether every project genuinely needs Docker Desktop's full VM versus a lighter alternative like Colima or OrbStack, which manage their own virtual disks with different growth and reclamation behaviour.

Where VolumeLens fits in

Docker.raw is one of the largest single files most developers have on their Mac, and because it lives inside a container path most tools don't surface clearly, it's easy to forget it's there until disk space runs out. VolumeLens shows it as exactly what it is — one large file at a specific path, sized honestly — right alongside every other folder competing for space, so you know when it's worth reaching for Docker's own cleanup commands. See what Insights recognises beyond Docker, including the Xcode and Homebrew caches that often sit on the same machine.