Docker is eating your Mac's disk: what prune really deletes
Docker.raw is 60 GB, docker system prune -a frees 40 of them — and takes things with it that nobody can get back. The four accounts behind the number, and which command empties which.
On a Mac running Docker Desktop, the single largest lump of disk is almost always the same file: ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw. It grows to 40, 60, sometimes 100 GB, and a cleaning app sees exactly one number in it.
That number is the sum of four separate accounts, and adding them up is the mistake.
What Docker says about itself
The answer is not in the file system, it is in the tool:
docker system df -vThe call is read-only and returns four lines — Images, Containers, Local Volumes, Build Cache — each with SIZE and RECLAIMABLE. That split is what decides the cost of clearing up:
| Account | What is in it | What deleting costs |
|---|---|---|
| Build cache | intermediate layers of past builds | time on the next build |
| Images | pulled and locally built images | a re-download — or a lost build |
| Containers | writable layers of running/stopped containers | anything written in-container and not mounted |
| Local volumes | databases, uploads, state | real data, unrecoverable |
The commands, in the order they start to hurt
docker builder prune # build cache only. Costs time, nothing else.
docker image prune # only unused, untagged (dangling) images.
docker system prune # + stopped containers, unused networks.
docker system prune -a # + EVERY image without a running container.
docker volume prune # anonymous volumes.
docker volume prune -a # named ones too. Those are usually data.The step from line three to line four is one flag. It is also the difference between "I wait two minutes on the next build" and "the image I built three months ago, whose Dockerfile no longer exists, is gone".
The step from line five to line six is a flag as well — and behind it live Postgres volumes.
Why we never suggest the blanket command
Docker does not distinguish between an image pulled from a registry and one built here. To the daemon they look the same. A tool watching from outside therefore cannot know that difference — and so must not claim it.
BalaneDisk shows the four accounts separately, with three verdicts:
- safe — build cache, dangling images
- look first — images, container layers
- contains data — named volumes
and hands you the matching command instead of a button. You run it, in the terminal, knowing what it takes with it.
The rest of the truth about Docker.raw
Three sizes belong to this one file, and all three are correct:
- 01Allocated size — the ceiling Docker Desktop was given in its settings.
- 02Actually occupied — the blocks macOS has really handed out (sparse file).
- 03Used inside — what the Linux VM is using of it.
After a prune, (3) drops immediately and (2) only once Docker returns the free space to macOS. Anyone watching Finder alone reads that as a failed clean-up. It is just an image file that has not shrunk yet.
Short version
- Never start with
-a.docker builder prunefirst — it costs nothing but time. - Review named volumes one at a time, never as a herd.
Docker.rawshrinks late. That is not a bug.- And the folder in Finder is the wrong lever: for a cache its own tool manages, the command is the right one.
- What is Docker.raw and why is it so large?
- Docker.raw is the virtual disk of the Linux VM that Docker Desktop runs on a Mac. It is a sparse file: it only occupies what has actually been written, it grows as you use it, and it does not shrink automatically when you delete something inside the VM.
- Why doesn't Docker.raw get smaller after a prune?
- Because the space is freed inside the VM while the image file keeps its size outside. Docker Desktop returns it to macOS on the next restart or via "Clean / Purge data"; recent versions run a TRIM automatically.
- Is docker system prune -a dangerous?
- It deletes no named volumes, but it does delete every image without a running container — including ones you built here and never pushed to a registry. Those are gone. It only becomes dangerous to data at docker volume prune -a.