Why does Docker.raw show 60 GB but docker system df says less?

Docker.raw is a sparse disk image that grows to its maximum size but does not shrink when you delete images inside the VM. Pruning frees space inside the VM; Docker Desktop compacts the file on restart or via Settings → Resources → Disk image size → Reclaim space. Until then, Finder still reports the allocated size.

Is it safe to run docker system prune?

Yes, without --volumes. The default prune removes stopped containers, dangling images, and unused networks — all regenerable. It does not touch volumes, which is where databases usually live. Always run docker system df first so you know what you are reclaiming.

Can I delete Docker.raw to free space?

No. Deleting Docker.raw by hand destroys every image, container and volume at once and can corrupt Docker Desktop. Use docker prune commands instead, then let Docker compact the disk image. The same applies to OrbStack and Colima VM data — prune through docker, never rm the VM disk.

Does OrbStack or Colima use the same cleanup commands?

Yes. Both expose the standard docker CLI and the same prune subcommands. DevCleaner detects docker at /usr/local/bin/docker, /opt/homebrew/bin/docker, ~/.orbstack/bin/docker and Docker.app's bundled binary. The daemon must be running for prune commands to work.

Docker taking 100GB? Clean it safely

Why Finder shows 100 GB but you can't find the files

Docker Desktop does not store images as normal files in your home folder. Everything lives inside a virtual machine disk image — a single file that macOS reports at its allocated size even when much of it is empty inside the VM.

Check the usual suspects:

du -sh ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw 2>/dev/null
du -sh ~/.orbstack 2>/dev/null
du -sh ~/.colima 2>/dev/null

On a machine that's been building images for a year, Docker.raw routinely reports 40–100 GB in Finder. OrbStack and Colima keep their own VM data under ~/.orbstack and ~/.colima — same problem, different path.

Context: Docker is one ecosystem in our broader developer disk-space guide. This article goes deep on containers only; the hub article covers Xcode, npm, Homebrew and the rest.

What Docker stores (and what each costs to delete)

Start Docker Desktop (or OrbStack / Colima) and run:

docker system df

The RECLAIMABLE column is what prune commands can actually free. A typical breakdown:

Category	What it is	Typical size	Risk	Clean command
Build Cache	Layer cache from `docker build` / BuildKit	5–40 GB	SAFE	`docker builder prune -f`
Dangling Images	Untagged leftover layers from old builds	2–20 GB	SAFE	`docker image prune -f`
Unused Images	Tagged images not used by any container	10–60 GB	WARNING	`docker image prune -af`
Stopped Containers	Exited containers and their writable layers	1–15 GB	WARNING	`docker container prune -f`
Unused Volumes	Named volumes not attached to any container	1–50 GB	DANGER	`docker volume prune -f`

For a machine-readable breakdown (what DevCleaner reads):

docker system df --format "table {{.Type}}\t{{.Size}}\t{{.Reclaimable}}"

Safe cleanup: start here

These two are pure caches — Docker rebuilds them on the next docker build or docker compose build:

docker builder prune -f
docker image prune -f

Together they often reclaim 10–30 GB with zero downside for day-to-day work. If you haven't pruned in months, this alone can bring Docker.raw back under control.

A broader safe sweep (still no volumes):

docker system prune -f

This removes stopped containers, dangling images and unused networks. It does not touch tagged images you might still want or any volumes.

Check-first cleanup: images and containers

When you need more space, prune unused images — but know the cost:

docker image prune -af

Every image not currently referenced by a running or stopped container gets deleted. The next docker compose up or docker pull re-downloads or rebuilds them. Fine for images you can reproduce; painful for a 8 GB base image on a slow connection.

Stopped containers keep their writable layer (anything written inside the container filesystem since it was created). Prune them only if you don't need that state:

docker container prune -f

Before pruning containers: list what you're about to lose. docker ps -a shows every container. If one holds migration output, seed data or a one-off experiment you care about, remove it individually with docker rm <id> only after you've confirmed you don't need it.

Volumes: where your databases live

This is the category that ruins weekends. Docker volumes are not caches — they're persistent storage. Your Postgres data, Redis dumps, Elasticsearch indices and uploaded files typically live in named volumes mounted at /var/lib/postgresql/data and similar paths inside containers.

docker volume ls
docker volume prune -f   # lists candidates first; only proceed if you're sure

docker volume prune deletes volumes not referenced by any container — including stopped ones you removed in the previous step. That orphaned Postgres volume from a project you deleted six months ago? Gone forever, no undo.

Never add --volumes to docker system prune reflexively. docker system prune -af --volumes is the nuclear option. Our hub guide calls this out for a reason: volumes are the one Docker category that is not regenerable.

OrbStack and Colima

If you switched from Docker Desktop to a lighter backend, the cleanup commands are identical — it's still Docker under the hood:

Backend	VM data location	docker binary
Docker Desktop	`~/Library/Containers/com.docker.docker/Data/vms/`	`/usr/local/bin/docker` or Docker.app bundle
OrbStack	`~/.orbstack`	`~/.orbstack/bin/docker`
Colima	`~/.colima`	`/opt/homebrew/bin/docker` (with Colima context)

Prune through docker, not by deleting folders. OrbStack compacts its disk more aggressively than Docker Desktop; Colima's disk lives in ~/.colima/_lima/colima/datadisk. In all three cases, docker system df is the source of truth — Finder only shows the outer VM file size.

After a heavy prune, restart Docker Desktop and use Settings → Resources → Advanced → Reclaim disk space (or restart OrbStack) to shrink the sparse image. Until compaction runs, macOS may still report the old allocated size.

What not to do

Don't delete Docker.raw by hand — you lose everything and may need to reset Docker Desktop entirely.
Don't prune while a build or migration is running — mid-build cache deletion fails the build; mid-migration volume deletion loses data.
Don't assume "unused" means "unimportant" — a stopped docker compose stack's volumes are still "in use" until you remove the containers that reference them.

Prune with sizes shown first

DevCleaner reads reclaimable space straight from docker system df — Build Cache, Dangling Images, Unused Images, Stopped Containers and Unused Volumes each get their own row, rated Safe / Warning / Danger. Risky categories are never pre-selected; volumes sit behind an explicit opt-in. Works with Docker Desktop, OrbStack and Colima as long as the daemon is running.

Download DevCleaner — free ↓

free · no account · 4 MB · macOS 14+

FAQ

Why does Docker.raw stay huge after pruning?: The sparse disk image doesn't shrink automatically. Pruning frees space inside the VM; compaction (Docker Desktop's "Reclaim disk space" or a restart) maps that back to macOS. Until then, du on Docker.raw still shows the old allocation.
How much can I realistically reclaim?: First cleanup on a year-old install: often 20–60 GB from build cache and dangling images alone. Unused images add more if you're willing to re-pull. Volumes can be huge but are only safe to prune when you're certain they're orphaned.
Is docker system prune -a safe?: Safe for images and containers you can recreate — not safe for volumes. The -a flag removes all unused images, not just dangling ones. Skip --volumes unless you've read the list and have backups.
Do I need Docker running to clean?: Yes. Prune commands talk to the daemon. If Docker isn't running, docker system df fails and DevCleaner shows sizes as unavailable — start the backend first.

Docker Taking 100GB? Clean It Safely