Docker's disk file only shrinks after you prune what is inside it
The virtual disk grows with every image, layer and volume and never shrinks on its own. What each prune command removes, and which one deletes data.
Docker on a Mac stores everything inside one large file, and that file grows as you build and never shrinks by itself. Deleting images from inside Docker frees space inside the file, not on your disk, which is why people report cleaning up 30 GB and seeing no change.
Find out what is inside before removing anything
docker system df
docker system df -vThe first command gives four lines: images, containers, local volumes and build cache, each with a reclaimable figure. The second lists them individually. Read the reclaimable column, because it separates what is genuinely unused from what is in use by a container you have running.
What each prune command actually removes
| Command | Removes | Risk |
|---|---|---|
docker builder prune | Build cache | None. Rebuilds are slower |
docker image prune | Dangling images | None |
docker image prune -a | Every image not used by a container | Redownload or rebuild |
docker container prune | Stopped containers | Anything written inside them |
docker volume prune | Volumes no container references | Data. This is the dangerous one |
docker system prune -a --volumes | All of the above | Everything above at once |
The volume row is the one to slow down on. A named volume is where a database keeps its data, and a volume is unreferenced the moment its container is removed rather than when the data stops mattering. docker volume ls first, always.
Reclaiming the space on the actual disk
After pruning, the virtual disk file is still the size it was. Docker Desktop has a setting to reclaim it, and recent versions do it automatically on a schedule. The manual route is in Settings, Resources, where the disk image size and location are shown, and there is an option to reduce it.
The blunt version, when the file has grown beyond what any pruning fixes, is to reset Docker's disk image entirely. That deletes every image, container and volume, and it is the only reliable way to return a badly grown file to a few gigabytes. What the disk file is and where it lives covers that path in detail.
The habit that keeps it small
- Run
docker builder pruneweekly. Build cache is the fastest growing part and the safest to remove. - Use
docker image prune -aafter finishing a project, not during one. - Name your volumes, so
docker volume lsis readable when you come to prune. - Check
docker system dfbefore assuming Docker is the problem. Sometimes it is 3 GB and the disk is full for another reason.
Common questions
Why does deleting Docker images not free space on my Mac?
Because Docker stores everything inside a single virtual disk file, and removing images frees space inside that file rather than on your drive. The file has to be compacted or reset separately, which Docker Desktop does from Settings, Resources.
What is the difference between docker system prune and prune with volumes?
Without the volumes flag, prune removes stopped containers, unused networks, dangling images and build cache, all of which are rebuildable. Adding --volumes also removes volumes no container references, and those hold real data such as databases.
Is docker builder prune safe?
Yes. It removes cached build layers only, so the next build is slower and nothing is lost. It is usually the largest easy win, since build cache grows with every image you build and nothing removes it automatically.
How do I see what Docker is using disk space for?
Run docker system df for a summary of images, containers, volumes and build cache with a reclaimable figure for each, and docker system df -v to list them individually. Check this before pruning, since the reclaimable column separates unused data from what is in use.