Docker, containers & VMs

How to Find What's Using All Your Docker Disk Space on Mac

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

  1. Check the summary first. Run docker system df and note which category has the most reclaimable space.
  2. Drill into images. Run docker system df -v and look at the image table. Identify any base images you pulled for experimentation and no longer need.
  3. 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.
  4. Remove stopped containers. Run docker container prune. Docker will ask you to confirm and tell you how many containers will be removed.
  5. 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.
  6. Remove unused images. Run docker image prune -a to remove all images not referenced by a container (running or stopped). Omit -a to only remove dangling (untagged) images.
  7. Prune volumes only if you are sure. Run docker volume prune only after confirming none of the listed volumes hold data you need.
  8. Run a full system prune as a last resort. docker system prune -a --volumes removes 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 --rm with short-lived containers: docker run --rm my-image automatically removes the container when it exits.
  • Prefer Alpine-based images (node:20-alpine vs node: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.

Reclaim your disk in one click

Crumb audits your whole Mac, tells you what's safe to delete, and frees the space in seconds — private, local, and Apple-notarized.

Download Crumb for macOS

Frequently asked questions

What does docker system df show on Mac?
It shows a summary table of disk space used by Docker images, containers, local volumes, and build cache — including how much of each category is reclaimable without affecting running workloads.
Is it safe to run docker system prune on Mac?
docker system prune removes all stopped containers, unused networks, dangling images, and build cache. Adding -a also removes unused images, and --volumes removes unused volumes. It is safe on a dev machine where you can re-pull images, but check docker system df -v first to make sure you are not deleting volumes with data you need.
Why doesn't Docker's disk file shrink after pruning?
Docker on Mac stores data inside a virtual machine disk image (Docker.raw). Pruning reclaims space inside that image, but the file itself may not shrink on your Mac's filesystem until you use Docker Desktop's 'Reclaim disk space' option under Resources settings.
How do I find which Docker image is taking the most space?
Run docker system df -v to see per-image sizes, or run docker images --format "table {{.Repository}}\t{{.Tag}}\t{{.Size}}" to list all images with their sizes. Sort by size to find the largest ones.
What is Docker build cache and is it safe to delete?
Build cache stores the intermediate layers from previous docker build runs so subsequent builds can skip unchanged steps. It is the safest Docker category to delete — run docker builder prune to remove it. Your next build will be slower as it rebuilds the cache, but no persistent data or running containers are affected.