Is It Safe to Delete Docker.raw on Mac? What You Lose and How to Do It Right

If you've ever opened up your disk usage analyzer and stumbled on a multi-gigabyte file buried deep in ~/Library/Containers/com.docker.docker/Data/vms/0/, you've probably asked yourself: is it safe to delete Docker.raw on Mac? The short answer is yes — but only if you know what you're doing. Delete it carelessly while Docker is running, or without understanding what lives inside it, and you'll lose container images, volumes, and data that Docker may not be able to recreate. This guide walks through exactly what Docker.raw is, how large it typically gets, and the correct procedure for removing or trimming it safely.

What Is Docker.raw (and Why Is It So Big)?

Docker Desktop on macOS can't run Linux containers natively because macOS doesn't have a Linux kernel. Instead, Docker spins up a lightweight Linux VM using Apple's Virtualization framework (on Apple Silicon, macOS 13+) or HyperKit (on older Intel Macs). That VM needs its own virtual disk, and that disk lives on your host filesystem as a single raw disk image file named Docker.raw.

On macOS Sequoia and the upcoming Tahoe release, the file is almost always found at:

On older Docker Desktop versions (pre-4.x) or Intel Macs running the HyperKit backend, you might instead find a .qcow2 or .vmdk image at a slightly different sub-path, but the concept is identical: it's a virtual hard drive for Docker's Linux VM.

The file has a maximum size cap set in Docker Desktop's preferences (default is 64 GB), but the actual space used on disk can drift upward over time as you pull images, build layers, and run containers. Because Docker.raw is a sparse file on APFS, the number you see in Finder may look far smaller than what du -sh reports — or vice versa depending on the tool. Running du -sh ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw in Terminal gives you the most accurate on-disk footprint.

What Lives Inside Docker.raw

Everything Docker manages on your Mac is stored inside this virtual disk — not on your Mac's real filesystem directly. That includes:

• Container images: Every image you've pulled with docker pull or built with docker build.
• Containers: Stopped containers and their writable layers.
• Named volumes: Docker-managed volumes created with docker volume create or declared in docker-compose.yml. These often hold database files, application state, or generated assets.
• Build cache: Intermediate layers cached by BuildKit to speed up future builds.
• The Linux VM OS itself: A small Alpine-based root filesystem that Docker Desktop boots.

Deleting Docker.raw is equivalent to wiping that entire virtual disk. Docker will recreate a fresh, empty one the next time it starts — but everything above is gone permanently unless you've backed it up or pushed images to a registry.

How Much Space Does Docker.raw Actually Take?

The answer varies dramatically by workload. Here's a representative size breakdown to set expectations before you decide whether deletion is worth it:

Before reaching for the nuclear option of deleting the whole file, it's worth running Docker's own pruning commands to reclaim space without losing anything you still need.

Try Pruning Before Deleting

Docker accumulates dangling images (layers with no tag) and unused build cache silently. A few targeted commands can recover gigabytes in minutes:

• docker system prune — removes stopped containers, unused networks, dangling images, and dangling build cache. Safe to run at any time.
• docker system prune -a — additionally removes images not referenced by any running or stopped container. This is more aggressive; any image you haven't used recently will be deleted and must be re-pulled.
• docker volume prune — removes all volumes not attached to at least one container. This can delete database data — confirm carefully before running.
• docker image prune -a — targets images only, leaving containers and volumes intact.

After pruning, Docker Desktop's disk image doesn't automatically shrink on disk — APFS reclaims the space as sparse file holes, but du won't reflect a smaller number right away. To actually compact the file, open Docker Desktop, go to Settings → Resources → Advanced, and click Reclaim disk space (available in Docker Desktop 4.x and later). This runs a compaction pass inside the VM that can reduce the physical file size by several gigabytes.

How to Safely Delete Docker.raw: Step-by-Step

If you've decided you want a clean slate — perhaps you're uninstalling Docker entirely, or you simply never use it and want the disk space back — follow these steps in order.

1. Quit Docker Desktop completely. Click the Docker whale icon in the menu bar and choose Quit Docker Desktop. Wait for it to fully stop. If you delete Docker.raw while Docker is running, the VM will crash and your disk image may be corrupted rather than cleanly removed.
2. Back up any volumes you want to keep. If you have named Docker volumes with data you need (databases, generated files), export them first:
   docker run --rm -v myvolume:/data -v $(pwd):/backup busybox tar czf /backup/myvolume.tar.gz /data
3. Push any images you want to keep. If you've built custom images that aren't in a registry, push them now:
   docker push yourrepo/yourimage:tag
4. Delete the file via Finder or Terminal. In Terminal:
   rm ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw
   Or navigate to that path in Finder and move it to the Trash.
5. Optionally remove the rest of Docker's container data. The directory ~/Library/Containers/com.docker.docker/ also holds Docker Desktop preferences and extension data. If you're fully uninstalling, Docker Desktop's own uninstaller (accessible from the Troubleshoot section in settings) handles this more cleanly than manual deletion.
6. Restart Docker Desktop. The next launch will create a fresh, empty Docker.raw — typically around 200–500 MB — and you'll be starting from a clean environment.

What About Other Docker-Related Disk Hogs?

Docker.raw is usually the biggest offender, but Docker Desktop scatters a few other caches and log files around your Mac worth knowing about:

• ~/Library/Containers/com.docker.docker/Data/log/ — VM and daemon logs. Generally small but can grow on systems with verbose logging enabled.
• ~/Library/Application Support/Docker Desktop/ — extensions, backups of settings. Usually under 500 MB.
• ~/Library/Preferences/com.docker.docker.plist — Docker Desktop preferences file.

If you're auditing disk space more broadly, developer tools tend to pile up quickly in parallel with Docker. Xcode's DerivedData at ~/Library/Developer/Xcode/DerivedData/ and npm's module trees are common companions to a Docker-heavy machine. A tool like Crumb can audit all of these at once and show you what's safe to remove before you delete anything.

Will Docker Re-Download Everything After Deletion?

Yes — but only the images you actually use again. Docker is pull-on-demand: it fetches an image the first time you run docker run or docker pull for it, and caches it locally. Most base images (like node:20-alpine or postgres:16) are available from Docker Hub and pull in seconds to minutes depending on your connection. What you won't recover automatically:

• Custom images you built locally and didn't push to a registry.
• Named volumes containing application state (databases, file uploads, etc.).
• Any containers you wanted to keep (though best practice is to treat containers as ephemeral).

If your workflow already uses a docker-compose.yml and pushes images to a registry, starting fresh after deleting Docker.raw is typically a ten-minute docker compose up --build away.

Keeping Docker.raw Under Control Going Forward

Rather than letting the file balloon and then deleting it every few months, a few habits keep it manageable:

• Run docker system prune weekly, or add it to a post-deploy script.
• Set the disk image size limit in Docker Desktop to a value you're comfortable with (Settings → Resources → Advanced → Virtual disk limit). Lowering it forces Docker to be more aggressive about pruning old layers when space is tight.
• Use multi-stage builds in your Dockerfiles to minimize the layers that end up in the final image.
• Tag and push images to a registry (Docker Hub, GitHub Container Registry, AWS ECR) rather than relying on the local cache as a backup.

For a broader look at where developer tool caches are quietly consuming your Mac's storage, see our guide on what is taking up space on your Mac — it covers build caches, language package managers, and VM images in one place.