If you've ever opened Docker Desktop's settings, seen a Disk image size slider, moved it down, and then checked ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw only to find it exactly the same size as before — you haven't done anything wrong. That slider does not do what it looks like it does, and understanding why is the key to actually reclaiming the space.
What the Disk image size setting actually controls
Docker.raw is the virtual disk backing the lightweight Linux VM that Docker Desktop runs on macOS (macOS has no native container runtime, so Docker needs a small Linux environment to host one). The Disk image size setting under Settings → Resources → Advanced sets the maximum size that virtual disk is allowed to grow to — a ceiling, not a target.
Raising the slider lets Docker.raw grow larger if you need to. Lowering it after the file has already grown past your new limit does nothing retroactively — Docker Desktop cannot instantly shrink a virtual disk that already contains data past that threshold, and in most versions the UI will simply refuse to let you set the limit below the file's current size until you free that space some other way.
Why deleting files inside Docker doesn't free space outside it
This is the conceptual crux. Docker.raw is a disk image — a container-within-a-container, in a sense — formatted with its own filesystem, holding the Linux VM's OS plus every Docker image, container, and volume. When you delete an image or run docker system prune, you are freeing space inside that virtual disk's own filesystem. Whether that freed space then also shrinks the outer Docker.raw file on your actual Mac disk depends on whether something explicitly tells the virtual disk format to compact itself — deleting a file inside a disk image, like deleting a file inside a ZIP archive, does not automatically make the archive itself smaller unless the format supports incremental compaction and something triggers it.
Docker Desktop does have some background reclamation logic for this in recent versions, but it isn't instant, isn't guaranteed on every prune, and isn't something you can force with a UI button in most versions short of the two hammers below.
Reset to factory defaults: the reliable option
Docker Desktop → Troubleshoot → Reset to factory defaults (the exact path varies slightly by Docker Desktop version, sometimes under a gear or bug icon) discards Docker.raw entirely and recreates it fresh, empty, at its minimum size. This is the most reliable way to actually shrink the file, because it isn't shrinking anything — it's starting over.
The cost: every image you've pulled, every container you've created, and every named volume's data is gone. This is fine if your images can simply be re-pulled and your containers recreated from Dockerfiles or compose files you still have — which describes most development setups. It is not fine if you have data sitting in a named volume that only exists on your machine, such as a local database you've been using for months without a backup strategy.
Back up volumes before resetting
If you have a named volume you actually need, copy its contents out before resetting. One reliable pattern: mount the volume into a temporary container alongside a bind mount to somewhere on your actual Mac filesystem, and copy the data across:
docker run --rm -v my_volume:/from -v ~/docker-backup:/to alpine sh -c "cp -a /from/. /to/"
Adjust my_volume and the destination path for your case. After the reset, if you need that data back inside a fresh volume, reverse the process — create the new volume, then copy the backed-up files back in with the same pattern.
For a database specifically, it is usually cleaner to use the database's own export tool (pg_dump, mysqldump, and equivalents) rather than a raw file copy, since that gives you a portable backup independent of Docker's volume format entirely.
Troubleshoot → Clean / Purge data: the lighter option
Before reaching for a full factory reset, Docker Desktop's Troubleshoot menu also offers a Clean / Purge data option that is less destructive than a full reset in some versions — worth trying first, since its exact scope (whether it touches the VM disk allocation or only container/image data) has varied across Docker Desktop releases. If it doesn't shrink Docker.raw noticeably, factory reset is the fallback that reliably does.
Alternatives that manage the VM disk differently
If shrinking Docker.raw is a recurring frustration rather than a one-time cleanup, it's worth knowing that Docker Desktop is not the only way to run containers on macOS. Colima and OrbStack are both popular alternatives that also run a Linux VM under the hood (the underlying requirement doesn't go away) but manage that VM's disk with different defaults and, in some cases, better automatic reclamation behaviour. Switching is a bigger decision than a cleanup tip — it changes your daily workflow and tooling compatibility — but worth researching if this is a recurring pain point rather than a one-off.
A practical decision path
- Check
docker system dfand rundocker system prune -a --volumesfirst — this is free and sometimes enough. - Check
Docker.raw's actual size afterward withdu -sh. If it hasn't moved, continue. - Try Troubleshoot → Clean / Purge data.
- If the file is still large and you're willing to lose local images and volume data, back up anything in named volumes you need, then run Reset to factory defaults.
- Re-pull images and recreate containers from your Dockerfiles or compose files as needed.
Where VolumeLens fits in
Docker.raw is often one of the single largest files on a developer's Mac, and because it lives inside a nested container path, it's easy to lose track of exactly how large it's grown. VolumeLens shows it plainly, sized to scale against everything else on your disk, so you know before you start whether a Docker reset is worth the disruption. Check the pricing for what's included in the free scan versus the Insights tier that recognises Docker's footprint automatically.