If you have been using Docker on a Mac for more than a few months, you have probably noticed that Docker Desktop silently accumulates gigabytes of disk space. Running docker system df on Mac is the fastest way to get a clear breakdown of exactly what is taking up that space — images, containers, volumes, and build cache — so you can make informed decisions about what to clean before touching anything permanently.
What docker system df Shows You
Open Terminal and run:
docker system df
You will see output similar to this:
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 23 8 14.72GB 9.31GB (63%)
Containers 4 2 182MB 91MB (50%)
Local Volumes 12 6 3.4GB 1.2GB (35%)
Build Cache 47 0 2.1GB 2.1GB
Each row represents a different category. The RECLAIMABLE column is the key number — it tells you how much space is theoretically recoverable without breaking anything that is currently running.
Images
Docker images are the largest contributor for most developers. Every time you pull a base image (python:3.12, node:20-alpine, postgres:16) or build a local image, Docker stores all its layers on disk. Images accumulate fast because:
- Pulling a new tag does not delete the old one.
- Building with a slightly different Dockerfile creates new intermediate layers.
- Docker Desktop auto-pulls updates in the background for some official images.
Containers
Stopped containers are not automatically removed. Each stopped container retains its writable layer — a diff on top of the image — which can grow if the container wrote logs or temporary files during its lifetime. This is rarely the biggest space hog, but it adds up when you have dozens of old containers from docker run one-offs.
Local Volumes
Named volumes persist across container restarts and live at a path managed by Docker (on Mac, inside the Docker Desktop virtual machine). If your containers wrote database files, uploaded assets, or application state to a volume, those bytes stay even after you delete the container. Volumes deserve careful review before deletion because they often hold data you actually want.
Build Cache
The build cache is usually the safest category to clear. Every docker build stores intermediate layer results so that subsequent builds can skip unchanged steps. Over time, this cache grows significantly. The RECLAIMABLE figure for build cache is almost always 100% of its size — none of it is "active" because it is only used during builds, not at runtime.
Getting More Detail with docker system df -v
The verbose flag gives you a per-item breakdown:
docker system df -v
This outputs three tables — one each for images, containers, and volumes — showing size per item. Use it to identify specific images or volumes that are disproportionately large. For example, a machine learning base image can easily be 8–12 GB by itself.
To sort images by size in the terminal, you can combine with docker images:
docker images --format "table {{.Repository}}\t{{.Tag}}\t{{.Size}}" | sort -k3 -h
Identifying the Real Space Hog: Images vs Volumes vs Build Cache
| Category | Typical size | Safe to prune? | Command |
|---|---|---|---|
| Unused images | Large (GBs) | Yes, if not referenced by a container | docker image prune -a |
| Stopped containers | Small-medium | Yes, if you no longer need their logs/state | docker container prune |
| Unused volumes | Variable | Only if you are certain the data is expendable | docker volume prune |
| Build cache | Medium-large | Yes — safest category to remove | docker builder prune |
Important: Pruning is permanent. Docker does not have an undo. Before running any prune command, verify what will be deleted with docker system df -v and make sure you are not removing a volume containing a database you need.
Step-by-Step: Reclaiming Docker Space on Mac
- Check the summary first. Run
docker system dfand note which category has the most reclaimable space. - Drill into images. Run
docker system df -vand look at the image table. Identify any base images you pulled for experimentation and no longer need. - Review volumes carefully. In the volume table, look for volumes not associated with a running container. Check if those volumes hold anything you want to keep — database files, user uploads — before proceeding.
- Remove stopped containers. Run
docker container prune. Docker will ask you to confirm and tell you how many containers will be removed. - Prune build cache. Run
docker builder prune. This is usually the safest reclaim. Your next build will be slower as it rebuilds the cache, but nothing is permanently lost. - Remove unused images. Run
docker image prune -ato remove all images not referenced by a container (running or stopped). Omit-ato only remove dangling (untagged) images. - Prune volumes only if you are sure. Run
docker volume pruneonly after confirming none of the listed volumes hold data you need. - Run a full system prune as a last resort.
docker system prune -a --volumesremoves everything unused in one shot. Only use this on a development machine where you are comfortable re-pulling all images.
Where Docker Actually Stores Data on Mac
Docker Desktop on Mac runs inside a Linux virtual machine. The raw disk image lives at:
~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw
This file grows as you add images and volumes. Crucially, it does not automatically shrink when you prune Docker objects — the virtual disk claims the space back internally, but the file on your Mac's filesystem may remain large until Docker Desktop compacts it. You can trigger compaction from Docker Desktop's settings under Resources → Disk image size — click the reclaim button after pruning.
If you want to see that file alongside your other large files in a single view, Crumb can map your entire disk visually. Its Visualize tab shows a treemap of disk usage across your Mac — including that Docker.raw file — so you can see at a glance how Docker compares to other space consumers like Xcode archives, iOS simulators, or node_modules directories without having to run du commands against every folder manually.
Tips for Keeping Docker Lean Going Forward
- Use
--rmwith short-lived containers:docker run --rm my-imageautomatically removes the container when it exits. - Prefer Alpine-based images (
node:20-alpinevsnode:20) when you do not need a full Debian/Ubuntu environment. The size difference is often 600 MB vs 50 MB. - Use multi-stage builds to avoid shipping build tools in your final image.
- Set a weekly reminder to run
docker system df— catching growth early is easier than reclaiming 40 GB all at once. - In Docker Desktop settings, enable "Use Virtualization Framework" and "VirtioFS" (macOS 12.5+) — these do not reduce space but improve the accuracy of disk reporting.
Conclusion
Reading docker system df carefully — images, containers, volumes, build cache — gives you a complete picture of where Docker space is going before you delete a single byte. Build cache is almost always safe to remove; volumes deserve the most caution. For a broader view of what is consuming your Mac's disk beyond Docker, download Crumb and use its Visualize tab to map your whole machine in one click — no Terminal required.