DEV Community: DiskInsight

Docker.raw: Why Is My Mac Out of Space When Docker Is Empty?

DiskInsight — Wed, 21 Oct 2026 11:40:02 +0000

You pull one image, run it for an afternoon, and four months later your Mac is out of space even though docker ps shows nothing running. The culprit is Docker.raw — the file Docker Desktop uses as its virtual hard disk.

It only ever grows, and nothing you do with docker rmi shrinks the file. Here's the actual mechanism and the safe ways to reclaim the gigabytes.

What Docker.raw is

Docker Desktop on Apple Silicon runs Linux VMs inside a single dynamic disk file. Every image, container, volume, and build layer you've ever had is stored in that one file:

~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw (Apple Silicon)
Inside Docker Desktop's Data/vms/0/data/ directory (x86, usually .raw too)

Docker.raw is a sparse/dynamic disk: it grows when you use space, but by design it doesn't reclaim space when you delete a container. The freed blocks stay reserved inside the file. So even after docker system prune -af, your disk is still full — Docker thinks you're fine because inside its VM the space is free.

Confirm it's your problem

du -sh ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw

docker system df shows the VM image's size, but du on the .raw file shows the actual on-disk footprint. If Docker.raw is 40 GB while docker image ls is 3 GB — that's the black hole.

The safe shrink (no data loss, Docker-way)

1. Prune what's actually cruft

docker system prune -af
docker builder prune -af
docker volume prune -f

This frees space inside the VM. The .raw file still won't shrink yet.

2. Reclaim the file (the part people miss)

In Docker Desktop settings there's the manual lever: Docker Desktop → Settings → Resources → Advanced → Disk image size.

Option A — resize/recreate the VM (effective): change the Disk image size to a smaller value → Apply & Restart. Docker recreates Docker.raw at the new size (often shrinking the file). Or remove the file while Docker is fully quit and let Docker recreate it empty — but that destroys your images, containers, and volumes.

Option B — the direct one-liner for the brave: quit Docker fully, then:

# only if Docker Desktop is QUIT, and you accept images/volumes are recreated
rm -f ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw

Again: this deletes the VM contents. Re-pulling images rebuilds the file.

3. Do not fall for "docker system prune" alone

docker system prune -af frees space inside the VM. It doesn't shrink Docker.raw. The file only shrinks via the disk-image-size control, or by recreating the VM. Layering these two is what actually returns gigabytes to your Mac.

Prevent it next time

Set a hard disk-image cap in Docker Desktop settings that's smaller than "maximum".
Prune regularly: docker system prune -af && docker builder prune -af weekly-ish.
Remove big unused images: docker images → untagged ones (<none>) hold the most.
Remember Homebrew isn't the only thing that grows — DerivedData and node_modules grow too.

See it on the map first

The most satisfying way to fix a silent 40 GB before it becomes an "out of space" crisis: see your disk as folders, sorted by bytes. DiskInsight renders that — every folder, every cache, hidden or not — so Docker.raw shows up as a giant block you can click and inspect before touching anything. Everything is staged to the Trash for your review; nothing is deleted behind your back. 100% local, no telemetry.

Bottom line

Docker.raw is a dynamic disk that grows and never shrinks by itself. docker system prune frees space inside it. To actually get gigabytes back on your Mac:

docker system prune -af && docker builder prune -af
Reduce Disk image size in Docker Desktop settings (or recreate the VM if you accept images are gone).
Keep the cap low so it stops re-bloating.

DiskInsight is a local macOS disk analyzer with nine visualizers; scanning is free forever, and a one-time Pro unlock adds duplicate cleanup, a dev cache cleaner (Xcode, npm, CocoaPods, Gradle) and a full app uninstaller. Nothing is uploaded, no account, no telemetry.

More: https://diskinsight.com

The node_modules Black Hole: Recursively Finding and Cleaning Projects

DiskInsight — Tue, 20 Oct 2026 08:37:09 +0000

Somewhere on your Mac there are dozens of node_modules folders, and you haven't thought about most of them in months. Each one is 200 MB–2 GB of installed packages — including the ones for projects you deleted, archived, or rage-quit two laptops ago.

This is the single biggest "quiet" disk eater for anyone who's ever run npm install. Let's find them all, safely delete the dead ones, and stop them from re-growing.

First, measure: how bad is it?

find . -name "node_modules" -type d -prune 2>/dev/null | head -50

That lists the folders. For the actual byte counts (the number that matters), do this from a big directory like ~/Developer, ~/Projects, or your home folder:

find . -name "node_modules" -type d -prune -exec du -sh {} + 2>/dev/null | sort -rh | head -20

You'll see the map: a handful of heavy projects, a graveyard of old ones. A typical developer who's shipped a few projects has 10–50 GB tied up here.

What's safe to delete?

Everything under node_modules is disposable. That's the whole point — it's re-downloadable packages, not your code. Your actual work lives in the project's src/, package.json, package-lock.json / yarn.lock / pnpm-lock.yaml.

Rules of thumb:

Delete the whole folder when a project is archived on GitHub/GitLab — rm -rf project/node_modules reclaims everything.
Only reinstall if you need it — you'll swap it in from git before you work on it again.
Never delete a project folder believing its node_modules is your work — your code is separate.

For an individual project:

cd ~/Projects/old-thing
rm -rf node_modules
npm ci

That drops it to the locked package set — and if the lockfile is gone, npm install quietly does the same.

The recursive one-liner (delete nothing blindly)

If you want to strip node_modules from a whole tree of projects in-place (not delete the projects), this is the surgical version:

find . -name "node_modules" -type d -prune -ok rm -rf {} \; 2>/dev/null

The -ok asks before every deletion — boring but safe. Drop -ok and swap to -exec rm -rf {} + only when you've visually inspected the du -sh list above and know exactly what you're targeting.

Also on the Node disk-bloat list

node_modules isn't alone. The other Node space-suckers:

~/.npm/_cacache — npm's global cache. Safe to clear.
~/.yarn/cache and ~/.cache/yarn — Yarn 2+ hard-link cache.
~/.pnpm-store — pnpm's content-addressable store.
~/.cache/node / the node-gyp cache.

npm cache clean --force
yarn cache clean
pnpm store prune

brew cleanup also handles some old node-install cruft, but the npm/Yarn/pnpm moves above are the real ones.

Why it comes back (and how to stop it)

Because every fresh npm install rebuilds the folder. Tricks for keeping disk usage sane:

Aggressive .gitignore discipline — if node_modules gets committed, every clone on this machine rips a fresh copy.
pnpm instead of npm — pnpm dedupes via a global store + hard links, so 30 projects create disk weight for one, not 30.
Archive, don't hoard — old projects you're not touching belong in git, not wearing 2 GB of installed packages.

See it, then clean what matters

A disk analyzer makes this trivial — sort by size, and the dead Node projects jump to the top in seconds. The point isn't to delete by magic; it's to see the map and decide.

DiskInsight scans your disk, ranks every folder by byte cost (including hidden node_modules, DerivedData, sim caches), and stages anything you choose to the Trash — no irreversible deletion, no rm -rf of the wrong tree. 100% local, no telemetry.

The 30-second fix

Run the find + du -sh one-liner to see the damage.
npm cache clean --force (safe, immediate win).
rm -rf the node_modules of archived projects only.
If you host old repos, delete their local clones — git keeps your reality.

Node disk bloat is the most fixable developer disk problem on macOS, bar none.

More: https://diskinsight.com

How to Find the Largest Files on Your Mac (Fast, Free Methods)

DiskInsight — Tue, 20 Oct 2026 08:36:20 +0000

"Where did my free space go?" almost always resolves to a handful of giant files: an old disk image, a 4K video, a Photos library, a .pkg you downloaded twice. Finding the top 20 gives you 80% of the win.

Here are the fastest methods on macOS - one app-legit, one terminal, one visual - with exactly how much they cost in effort.

Method 1 - Finder (no install)

Open Finder, hit ⌘F (Find), set search location to This Mac.
Add filters: File size → "is greater than" → type 1 GB.
Sorted by size, top results first. Whatever the giant is, it's here.

Repeat with This Mac = "is greater than" 0.5 GB if 1 GB cut out the interesting stuff.

Method 2 - Terminal (precise, instant)

The workhorse. From a folder or your home, list the heaviest files:

# top 30 biggest files under the current dir
find . -type f -size +1G -exec du -h {} + 2>/dev/null | sort -rh | head -30

# same, but any size, sorted top-down
du -a . 2>/dev/null | sort -rn | head -30 | awk '{print $1, $2}'

And to find the folders that hide the files (the only "big folder, small files" paradox):

du -sh ~/Library/Developer 2>/dev/null
du -sh ~/Pictures 2>/dev/null
du -sh ~/Downloads 2>/dev/null

Method 3 - A disk map (see the structure, not just a list)

Files hide inside folders. The terminal list shows you videos/week4-4k.mov - a treemap shows you why ~/Pictures is 40 GB at a glance (one giant library vs 20,000 photos).

Every folder rendered as a rectangle sized by bytes
Zoom from drive → folder → a single file
Hidden & contained folders (~/Library/Application Support, ~/Library/Containers) counted for real

That's what I built DiskInsight to do: nine views, one scan, byte-exact - see it, decide, stage to Trash, never auto-delete. 100% local, no telemetry, one-time price.

What you'll typically find (and what's safe)

.dmg/IPSW installers in ~/Downloads - safe to delete once installed
~/Pictures/Photos Library - review before deleting
Movies: the 4K editing originals - archive to an external drive
~/Library/Developer - Xcode DerivedData & simulators
~/Library/Caches - everything worth clearing
Docker.raw - the never-shrinking blob

The honest rule: caches and installers are always re-downloadable; your Documents/Desktop/Pictures are not. Delete accordingly.

The 30-second version

Finder ⌘F → This Mac → size > 1 GB. There's your top-10.
If a folder hides the space, du -sh the top-family folders.
Check ~/Library/Developer and ~/Library/Caches if you build apps.

And when a list isn't enough, visualize: see the disk the way math sees it - rectangles scaled by bytes, ranked, inspectable, reversible.

I'm building DiskInsight - a local macOS disk analyzer with nine visualizers (treemap, sunburst, flame graph, bubbles, mind map, age map, top sizes, list, folders). Scanning is free forever; a one-time Pro unlock adds duplicate cleanup, a dev cache cleaner (Xcode, npm, CocoaPods, Gradle) and a full app uninstaller. Nothing is uploaded, no account, no telemetry.

More: https://diskinsight.com