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 sparse file whose logical capacity can be much larger than its allocated blocks on macOS.

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.

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:

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

The amount recovered depends on unused cache and shared layers. These actions can require a rebuild or re-download; measure with docker system df before and after rather than assuming a fixed number of gigabytes.

A broader cleanup that also deletes stopped containers and their writable state (review these first):

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

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 ls --filter dangling=true   # inspection only
# Inspect a chosen volume and its project before removal:
docker volume inspect <volume-name>
# Destructive; asks for confirmation (not a dry run):
docker volume prune

docker volume prune removes unused anonymous volumes by default. --all includes unused named volumes. A volume is unused when no container references it; deleting stopped containers can therefore make important database volumes eligible. The -f flag suppresses confirmation, it never previews candidates. Verify ownership and backups before any volume removal.

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:

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 pruning, allow time for Docker Desktop to return freed space to the host. Compare du -sh, ls -klsh and filesystem free space. Logical capacity can stay large after successful cleanup; behavior depends on disk format and Docker version. See Docker.raw still huge after prune and the official Mac FAQ.

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.

FAQ

Why does Docker.raw stay huge after pruning?

Its logical maximum capacity can remain large even when allocated host usage falls. Docker Desktop can reclaim host space after pruning, depending on format and version. Compare allocated size and free space; do not assume Finder’s logical length equals occupied space.

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.

References and scope

Reviewed for DevCleaner 1.14.5 on October 4, 2026. Paths depend on tool version and configuration. Size ranges are illustrative, not measured savings or a recovery guarantee. Check the installed tool’s version/help before running cleanup commands.

• Docker volume pruning and confirmation
• Build-cache scope
• Docker Desktop host disk space