Docker Desktop disk space on Mac: what Docker.raw really holds

Docker Desktop disk space on a Mac goes into one file: ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw. It's the disk of the Linux virtual machine your containers run in, and every image, container, volume and build cache entry lives inside it.

That file is sparse. Finder can show it as hundreds of gigabytes, because its size is the most the disk may grow to, while the space it really takes is often a small fraction of that. Docker Desktop's own Settings › Resources › Advanced page shows both numbers.

To get space back, remove what you don't need inside Docker: stopped containers, unused images and volumes you're sure about in the Dashboard, and the build cache, which Docker trims on its own and its command-line tool clears. Docker then returns the freed space to your Mac, sometimes after a few minutes.

Never move Docker.raw to the Trash. It takes every image, container and volume with it, including databases you keep in volumes, and Docker Desktop simply makes a new, empty disk. The sections below go through each part of the file, what the Dashboard can remove, and the settings that keep it in check.

Where Docker Desktop keeps its data on a Mac

Docker on Linux keeps containers and images in a folder on the computer's own disk. Docker Desktop can't, because a Mac doesn't run Linux containers natively. It runs a small Linux virtual machine and gives that machine one large disk image file in your Library folder.

What is Docker.raw?

Docker.raw is that virtual machine's whole hard disk, stored as a single raw disk image. Inside the virtual machine it looks like an ordinary Linux disk, and Docker's engine stores its images, containers, volumes and build cache on it. From the Mac's side, it's one file.

The catalog entry for Docker.raw describes it the same way: the disk where Docker Desktop keeps your images, containers, volumes and build cache. That's why it's the right place to look when Docker seems to take a lot of space, and the wrong thing to delete.

What else does Docker Desktop keep outside it?

Most of the space is inside Docker.raw, but not all of it. A few other places belong to Docker Desktop, and one of them can be large.

Location	What it holds	Typical size
~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw	The virtual machine's disk: images, containers, volumes, build cache	From a few GB to the limit you set
~/.docker/models	Models pulled with Docker Model Runner, outside the disk image	Depends on the models you pull
~/Library/Containers/com.docker.docker/Data/log	Docker Desktop's own logs	Usually small
~/.docker	Settings, contexts, command-line plugins	Usually small
/Applications/Docker.app	The app itself	A couple of GB
Your project folders	Files you share with containers through bind mounts	Whatever your projects hold

Files you share with a container from your Mac, such as a project folder mounted into it, stay where they are on your Mac. They aren't inside Docker.raw, and removing Docker data never touches them.

Which Storage settings category counts Docker?

macOS doesn't know what Docker.raw is. In System Settings › General › Storage, it usually lands in System Data, which Apple describes as files that don't fall into the other categories. Apple adds that you can't manage the contents of that category from Storage settings.

So a jump in System Data after a week of building images is often Docker. The Storage settings path is the same in macOS 27 Golden Gate and macOS 26 Tahoe. Before macOS Ventura, the same view was under Apple menu › About This Mac › Storage.

Real size versus apparent size: why Docker.raw looks so big

The most common Docker storage scare isn't a real problem. Someone opens their Library folder, sees a file of 200 or 500 GB, and assumes Docker has eaten their disk. Usually it hasn't.

What is a sparse file?

A sparse file has a size, and it has the space it takes on disk, and the two can be very different. The size says how large the file may become. The space on disk counts only the parts that have actually been written.

Docker.raw is created at the full size of its disk limit, but nothing is written into most of it. APFS, the Mac's file system, stores only the written parts. As you pull images and create containers, more of the disk gets written, and the space it takes on your Mac grows toward the limit.

How do you see the real size?

There are three places to check, and one of them is Docker's own:

1. In Docker Desktop, open Settings, click Resources, then Advanced. Docker's documentation says this page shows where the disk image is, its maximum size and the space it actually takes.
2. In Finder, select Docker.raw and choose File › Get Info, or press Command-I. The size line shows the file's full size and, in parentheses, the space it takes on disk. The figure in parentheses is the one that counts.
3. In the Dashboard, the Images view's header shows how much space your images use, which is usually the largest part.

To reach the file in Finder, choose Go › Go to Folder, paste the folder path from the table above without the file name, and press Return. Look, but don't move or rename anything there.

A worked example

On one developer's Mac we checked while writing this, Docker.raw had a size of about 494 GB. That's the disk usage limit Docker Desktop had set for it. The space it took on disk was about 34 GB, roughly 7 percent of its size.

Nothing was wrong. The 494 GB was the most it could ever grow to, and the 34 GB was the images, containers and volumes on it. If that Mac had been short of space, 34 GB would have been the number to work with, and the parts of it worth removing were inside Docker.

Why do Finder, Storage settings and Docker disagree?

Each tool measures something slightly different, and none of them is broken. It helps to know which one answers the question you're asking.

Where you look	What it shows for Docker.raw	Good for
Finder's list view	Often the full size, the disk limit	Nothing about real usage
Finder's Get Info	The full size, and the space on disk in parentheses	The real footprint
Docker Desktop, Resources › Advanced	The maximum size and the space it takes	The real footprint and the limit
Docker Desktop, Images view	The total size of your images	What's using the disk inside
Storage settings	Part of System Data	Seeing that System Data grew

Docker's own figures and Finder's figure for the file won't match exactly. Docker counts what's inside its disk; Finder counts the blocks the file holds on your Mac, which can include space Docker freed but hasn't handed back yet.

Does backing it up or copying it change anything?

Time Machine doesn't back up the virtual machine unless you ask it to. Docker Desktop's Settings › General has Include VM in Time Machine backups, and Docker's documentation lists it as off by default. Most people should leave it off: images download again, and data you care about belongs in a backup you control.

Other tools that keep their folders out of backups are listed in the post on developer folders and Time Machine.

Copies are another trap. If you duplicate a large disk image on APFS, Finder's Get Info can't tell how much the copy shares with the original, so its "on disk" figure can be wrong for clones. There's no reason to copy Docker.raw by hand anyway; Docker Desktop has a setting to move it, covered below.

What's inside the disk: images, containers, volumes and build cache

Freeing space well means knowing what each kind of Docker data is, because they differ a lot in what it costs to lose them. Images come back with a download. Volumes may be the only copy of a database.

Images

An image is the read-only template a container starts from: an operating system's files, your app's dependencies, your build output. Images are made of layers, and images built on the same base share those layers, so two images of 1 GB each may take far less than 2 GB together.

Docker Desktop's Images view sorts them three ways. An In use image is used by a container, running or stopped. An Unused image isn't used by any container. A Dangling image is an older build left without a name when you built a new version with the same tag.

Dangling images are the easiest win on a Mac where you build images often. Each rebuild of the same tag can leave the previous version behind, and they pile up quietly.

Containers

A container is a running, or stopped, copy of an image, plus a thin writable layer on top. Anything the container writes outside a volume goes into that layer. Docker's storage documentation says data written there doesn't persist when the container is removed.

Stopped containers keep their writable layer until you delete them. A test container you ran once and forgot can hold gigabytes of temporary files, downloaded packages or a database it created inside itself.

Container logs

Docker captures what each container prints and keeps it in a log file inside the virtual machine. By default it uses a format with no log rotation, and Docker's own documentation warns that chatty containers can fill a lot of space this way.

The log belongs to the container, so deleting the container deletes its log. The Clear terminal button in a container's Logs tab only clears what's on screen; it doesn't shrink the file.

Volumes

A volume is storage Docker manages for containers, kept separately so it survives when a container is removed. Databases, uploaded files and caches that a container should keep usually live in volumes. Docker's documentation is plain about it: deleting a volume deletes all its data.

Some volumes have names you or a Compose file gave them. Others are anonymous, created automatically by an image that asks for one, with a long random ID for a name. Anonymous volumes from old containers are a common leftover.

Build cache

When you build an image, Docker's builder keeps the results of each step, so the next build can skip steps that haven't changed. That build cache can be large, and much of it overlaps with the layers of the images you built.

Docker Desktop doesn't let it grow forever. Docker's documentation says its default builder keeps the cache to about 20 GB, and removes cache that hasn't been used in a build for more than 60 days. Clearing it costs time, never data: the next builds just take longer.

Kubernetes, extensions and hidden image stores

Three less obvious things also live on the same disk:

• Kubernetes. If you turned on Docker Desktop's built-in cluster, its system images and containers are on the disk too. Stopping the cluster removes its containers.
• Extensions. Docker extensions come as images, and those images take space like any other.
• The other image store. Docker Desktop now uses the containerd image store by default. Docker's documentation says images and containers from the inactive store stay on disk but are hidden until you switch back.

That last one explains a puzzle some people hit: the Images view shows little, yet Docker.raw takes far more. If you've switched image stores, the old store's images are still there.

Kind	What it holds	Comes back by itself?	Where to remove it
Dangling images	Old builds left without a name	Not needed	Images view, sorted by Dangling
Unused images	Images no container uses	Download or build again	Images view, sorted by Unused
Stopped containers	Their writable layer and logs	No; data in them is lost	Containers view
Volumes	Databases, uploads, persistent files	No	Volumes view, after exporting
Build cache	Results of earlier build steps	Yes, as you build	No button for the default builder
Models	Docker Model Runner's models	Download again, unless you packaged them	Models view

How to free Docker Desktop disk space on a Mac from the Dashboard

Docker Desktop's Dashboard can remove almost everything that takes space, one kind at a time, and the Images view shows how much a deletion frees before you make it. Work in this order: containers first, because an image can't be deleted while a container still uses it.

Start with containers you no longer need

1. Open Docker Desktop's Dashboard and click Containers.
2. Make sure Only show running containers is turned off, so stopped containers appear.
3. Select the checkboxes of containers you don't need. Compose projects are grouped; selecting a project selects all its containers.
4. Use Delete in the bulk actions toolbar.

Before you delete a container, ask whether it wrote anything you need outside a volume. If it did, start it and download those files to your Mac from its Files tab, because that data goes with the container.

Delete unused and dangling images

1. Click Images. The header shows how many images you have and the space they use.
2. Sort by Dangling first. These are old builds; select them all.
3. Then sort by Unused, and select images you don't expect to need soon.
4. Before you click Delete, read the toolbar: it shows how much space deleting the selection would free.

To see which containers hold on to an image, use View container usage in its row. An image used by a stopped container can't be deleted until that container is gone.

Images you pulled from a registry download again the next time you run them. Images you built yourself rebuild from your Dockerfile. An image you built and never pushed, from code you no longer have, is the one kind worth keeping a copy of.

Volumes: export first, then delete

1. Click Volumes, and filter by Unused to see volumes no container uses.
2. Check the Size and Created columns, and the name, to work out what each one is.
3. For anything you might want later, open the volume's Exports tab and use Quick export to save it to a local file. Docker requires you to be signed in for exports.
4. Select the volumes you're sure about, click Delete, then Delete forever.

A volume in use can't be deleted, even by a stopped container. If you'd rather keep a volume but empty it, Empty volume in its More volume actions menu deletes its data and keeps the volume.

What about the build cache?

Docker Desktop's Dashboard has no button to clear the default builder's cache. The Builds view shows build history, and Settings › Builders shows each active builder's disk usage, but neither empties the default builder's cache.

There are two routes. The garbage collection described above trims it on its own, so it rarely grows past about 20 GB. Docker's command-line tool can also clear it in one go, and that command removes build cache only.

Removing an extra builder you created, in Settings › Builders, also removes that builder's cache.

What does Docker's prune do, and what does it leave?

Docker's command-line tool has a family of prune commands, and much of the advice online is about them. There's no window for them; they're typed in Terminal. It's still worth knowing what each removes, so you can compare them with the Dashboard.

Docker's cleanup	What it removes	What it leaves
System prune	Stopped containers, unused networks, dangling images, unused build cache	Volumes and every tagged image
System prune with its all option	The same, plus every image no container uses	Volumes
Image prune	Dangling images	Every tagged image
Container prune	All stopped containers	Running containers
Volume prune	Unused anonymous volumes	Named volumes, unless asked
Builder prune	Dangling build cache; with its all option, all unused cache	Images, containers, volumes

Docker's documentation says volumes aren't pruned by default, because they hold data. The Dashboard's Volumes view is the safer way to remove them, one at a time, after you've exported anything you need.

Why didn't my Mac get the space back?

Four things explain most cases:

• It takes a few minutes. Docker's documentation says it might take a few minutes for the space to come back to your Mac after a cleanup.
• Files deleted inside a running container. Docker says space isn't freed automatically when files are deleted inside running containers; deleting images is what frees it.
• A Time Machine local snapshot. If you back up with Time Machine, a recent local snapshot can hold on to blocks Docker just released until the snapshot expires. Apple notes that even excluded items appear in local snapshots.
• Hidden images in the other image store. They take space but don't show in the Images view.

The Time Machine local snapshots guide explains how those snapshots work and how long they last.

The disk usage limit, and moving the disk image

Docker Desktop lets you set how large its disk may grow and where it lives. Both settings are in Settings › Resources › Advanced, and both are better used before the disk is full than after.

What does the disk usage limit do?

Disk usage limit sets the most disk space Docker's engine can use. It's the size Finder shows for Docker.raw. Older versions of Docker Desktop, and some of Docker's pages, call the same slider Disk image size.

Docker doesn't document a fixed default, and it differs from Mac to Mac. Check yours on the Advanced page. Recent versions also show the disk space used and the limit in the bar along the bottom of the Dashboard.

Is lowering the limit a way to shrink Docker.raw?

Not a gentle one. Docker's documentation says that when you reduce the maximum size, the current disk image is deleted, so all containers and images are lost. Volumes live on the same disk, so treat them as lost too.

It's a way to start over with a smaller ceiling, which can make sense on a Mac with little free space. Export the volumes you need first, note the images you'll want to pull again, then lower the limit and click Apply.

Why does Docker.raw stay the same after I lower the limit?

Some people lower the limit and find Docker.raw no smaller. First check what you're comparing: Finder's list can show the limit, Get Info shows the space taken, and a fresh disk takes little space until it fills.

On Docker's forums, a user on Docker Desktop 4.40 found the limit ignored. Another member traced it to Docker VMM, the beta virtual machine manager, reported it to Docker, and found that a 4.42 build fixed it.

If a limit doesn't seem to apply, check which manager is chosen in Settings › General › Virtual Machine Manager, and update Docker Desktop.

How do you move Docker.raw to an external drive?

1. In Docker Desktop, open Settings › Resources › Advanced.
2. Under Disk image location, click Browse and choose a folder on the other drive.
3. Click Apply.

Docker's documentation warns not to move the file in Finder, because Docker Desktop can lose track of it. If the folder you choose already has a disk image, Docker asks whether to use it or replace it.

Use a fast drive formatted as APFS, and keep it connected whenever Docker runs. Containers read and write that disk constantly, so a slow USB stick or a network drive makes everything crawl.

Situation	Use	What you lose
Docker grew from old images and builds	The Dashboard's Images and Containers views	Images you'll pull again
A volume holds old data	Export it, then Delete forever	The volume's data, if not exported
The startup disk is small	Disk image location, to a fast external drive	Nothing
You want a lower ceiling	Disk usage limit	Every container, image and volume
Docker is broken or you want a clean slate	Clean up data, in Troubleshoot	Every container, image and volume

Clean up data and factory reset: the heavy options

Docker Desktop's Troubleshoot menu has buttons that free all of Docker's space at once. Open it from the Docker menu in the menu bar, the whale icon, or the question mark at the top right of the Dashboard. Each one costs more than it looks.

What does Clean up data remove?

Docker's documentation describes Clean up data as a disk image reset that destroys all Docker containers and images on the Mac while keeping your settings. Because volumes live on the same disk, plan as if they go too.

It's the supported version of deleting Docker.raw: same result, but Docker Desktop stays consistent. Use it when you really want everything gone, after exporting volumes you need.

What does Reset to factory defaults do?

Reset to factory defaults returns every Docker Desktop option to how it was when it was first installed. Docker's documentation describes it in terms of settings. Treat it as a fix for a broken installation, not as a storage tool.

What about Reset Kubernetes cluster?

Reset Kubernetes cluster deletes all stacks and Kubernetes resources. If you turned Kubernetes on to try it and no longer use it, stop the cluster in Docker Desktop's Kubernetes view, which removes its containers. You don't need to reset it to save space.

When does starting over make sense?

A clean slate is reasonable when everything Docker holds can be rebuilt: your images come from registries or Dockerfiles you still have, and your databases are test data. On many developers' Macs that's true, and a reset takes less time than picking through hundreds of images.

It's the wrong move when a volume holds the only copy of something: a local database with months of work, uploaded files, or a model you trained. Export those first, or don't reset. Removing Docker Desktop altogether is a bigger step, with its own leftovers outside the disk image.

Why you should never delete Docker.raw

Advice to delete Docker.raw comes up often, usually from someone who saw a huge number in Finder. It's the one move to avoid, for three reasons.

What happens if you move Docker.raw to the Trash?

Every image, container and volume goes at once, because they're all inside it. The next time Docker Desktop starts, it creates a new, empty disk. Any database or file you kept in a volume is gone unless you exported it.

Moving it to the Trash doesn't even free space until you empty the Trash. By then the data is gone for good, and nothing in Docker Desktop brings it back.

Why does it look like it frees hundreds of gigabytes?

Because of the sparse file. Deleting a file whose size is 494 GB but which takes 34 GB frees 34 GB. People sometimes expect the larger number, then find their free space barely moved, after losing every container.

The same 34 GB, or most of it, usually comes back through the Dashboard, without touching the volumes you want to keep.

Is it safe to delete the com.docker.docker folder in Containers?

No, for the same reasons and a few more. ~/Library/Containers/com.docker.docker holds Docker.raw, Docker Desktop's logs and the files it needs to run. Removing it takes the disk with all your data, and Docker Desktop's working files with it.

The Containers folder itself, which holds every sandboxed app's data, shouldn't be touched at all.

Keep Docker from filling your Mac again

Docker grows because builds and pulls are cheap and cleanup is manual. A few settings make the growth predictable, and a short habit keeps it small.

Limit container logs

Since the default log format doesn't rotate, a container that prints a lot can grow its log without limit. Docker's documentation recommends its local log driver, which rotates logs by default, or rotation options for the default one.

In Docker Desktop, this lives in Settings › Docker Engine, an editor for Docker's engine configuration. Docker's documentation notes that the change applies to containers created after Docker restarts, so recreate long-running containers to pick it up.

Lower the build cache limit

The same Docker Engine settings hold the builder's garbage collection limit, defaultKeepStorage, which Docker Desktop sets to 20 GB. Docker's documentation says to decrease it if you need to preserve space. A lower limit means fewer cached build steps and slower builds, never lost data.

Set the disk usage limit before you need it

A Mac with a 256 GB or 512 GB disk benefits from a modest limit set early. When Docker reaches it, Docker runs out of room inside its own disk, and your Mac's startup disk keeps its free space for everything else.

Make cleanup part of the work

A few habits, each through the Dashboard:

1. When you finish with a Compose project, delete it from the Containers view rather than leaving it stopped.
2. Once a month, sort Images by Dangling and delete them all.
3. Check Volumes for unused anonymous volumes, the ones with random names.
4. In the Models view, remove models you no longer run.

Docker Model Runner's models are worth a separate look, since they sit outside Docker.raw in ~/.docker/models. The Docker Model Runner models entry explains them. Docker removes models permanently, not to the Trash, and models you packaged yourself exist only there unless you pushed them.

• Docker.raw, space really used10–100 GB · Usually safe
• Build cache, default limit20 GB
• OrbStack, Colima and other VMs10–150 GB · Review first

Typical ranges on Macs that use these tools, from the research behind the app's catalog. The build cache figure is Docker Desktop's default garbage collection limit, from Docker's documentation. Many Macs have far less.

OrbStack, Colima and other ways to run containers

Docker Desktop isn't the only way to run containers on a Mac, and the others store data in similar ways. The same rules apply: look at the real size, and clean up through the tool.

OrbStack

OrbStack keeps its Docker data and Linux machines in one sparse disk image in its group container, and Finder can show it as several terabytes. The OrbStack data entry explains it: the image takes only the space your data uses, and shrinks on its own as you delete containers, images, volumes and machines in OrbStack.

Colima, Lima and Podman

Colima runs Docker inside Linux virtual machines it manages with Lima, and keeps each profile's machine and disks in ~/.colima/_lima. It gives unused space back when it starts. Podman keeps its virtual machine in its own folder too. Remove containers, images and volumes in each tool; their virtual machines can hold data you made.

Can you run more than one at once?

You can install several, but each keeps its own disk, so the same images can be stored two or three times. If you moved from Docker Desktop to another tool, clean up Docker Desktop's data through its Dashboard, or remove Docker Desktop, rather than leaving an old disk behind.

How the app does it

Wombit measures Docker.raw by the space it takes on disk, not the size it claims, so a 494 GB file that takes 34 GB counts as 34 GB.

Select it in the map or the list, and the inspector says what it is and why deleting the file is the move to avoid. The Docker.raw guide has the short version.

Cleanup lists Docker.raw as Usually safe, so it never starts checked and never counts in the safe-to-remove total. The app never moves the file to the Trash. When you check it, the app runs Docker's own build cache cleanup after the review sheet, with Docker Desktop running.

The review sheet shows that size as "up to", because the command frees only part of the disk, and it says that what a command removes can't be put back. Images, containers and volumes stay: remove those in Docker Desktop's Dashboard, as above.

Docker Model Runner's models, OrbStack's data and Colima's machines are Review first. They're explained, with each tool's own steps, and left to those tools.

• ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw

  Docker Desktop disk image (Docker.raw)

  The virtual disk where Docker Desktop keeps all your images, containers, volumes and build cache.

  Usually safe · Runs docker --context desktop-linux builder prune --force

• ~/.docker/models

  Docker Model Runner models

  AI models pulled or packaged with Docker Model Runner, kept on your Mac outside Docker's disk image.

  Review first · Explained only: the app shows you how

• ~/Library/Group Containers/HUAQ24HBR6.dev.orbstack/data

  OrbStack data

  The disk image that holds OrbStack's containers, images, volumes and Linux machines.

  Review first · Explained only: the app shows you how

• ~/.colima/_lima

  Colima virtual machines

  The Linux virtual machines Colima runs containers in, with their disks and container data.

  Review first · Explained only: never removed

Seeing what Docker takes, and why, is free. Running its cleanup is part of PRO, one payment of $4.99 with lifetime access. Every Pro tool's review is free to open, so you see what would go and why before you buy.