April 8, 2026 · 9 min read

How to Free Up Mac Storage as a Developer (Xcode, Docker, node_modules)

Developer tools are the biggest silent consumers of Mac disk space. Here's how to find and remove Xcode simulators, Docker images, node_modules, Rust artifacts, and more.

If you’re a developer and your Mac is running low on storage, you already know the usual advice doesn’t cut it. “Empty your Downloads folder” isn’t going to help when you have 80 GB of Docker images and a dozen React projects with untouched node_modules folders from 2023. For a general-purpose cleanup guide, see How to Free Up Storage on Your Mac — this article covers the developer-specific culprits in depth.

This guide covers the actual culprits for developers — and how to deal with them without breaking your workflow.

Why Developer Machines Fill Up Faster

A typical developer Mac accumulates storage from sources that non-developers never encounter:

Xcode simulators — each iOS/watchOS/tvOS simulator can be 4–8 GB, and Xcode accumulates dozens
Derived Data — Xcode’s build cache grows to 20–50 GB on active projects
Docker images and volumes — unused images pile up silently, easily reaching 50–100 GB
node_modules — a single React project might be 500 MB; twenty projects means 10+ GB of duplicated packages
Cargo build artifacts — Rust’s target/ directory can be 5–30 GB per project
Python virtual environments — if you don’t use a shared env manager, venvs multiply fast
Git repositories with large histories or LFS objects — some repos carry significant stored objects

The standard macOS storage overview (Apple Menu → System Settings → General → Storage) won’t surface these. They hide in Library folders and project directories that macOS labels vaguely as “Developer” or “Documents.”

To see exactly what’s eating your disk, use a dedicated disk analyzer. DreamDisk scans in as little as 5 seconds and gives you an interactive visual breakdown — click any folder to drill into it and immediately see what’s inside. It’s the fastest way to orient yourself before you start deleting.

Xcode: The Biggest Offender

Xcode is the single largest hidden consumer of storage on most developer Macs. Here’s where the junk lives:

Simulators

Xcode downloads simulator runtimes for every platform you’ve tested on. Each one is 4–8 GB.

To clean them up:

Open Xcode → Settings → Platforms
Remove any simulator runtime you no longer need (old iOS versions, watchOS, tvOS)
You can always redownload them when needed

You can also delete them from the command line:

xcrun simctl delete unavailable

This removes simulators for platforms you’ve since removed, which Xcode doesn’t clean up automatically.

Derived Data

Xcode’s build cache — called Derived Data — can easily reach 20–50 GB on a machine with several active projects. It’s completely safe to delete; Xcode just rebuilds it on the next build (which will be slower once).

Delete it in Xcode: Settings → Locations → Derived Data → arrow icon → delete contents

Or from Terminal:

rm -rf ~/Library/Developer/Xcode/DerivedData/

Docker: The Silent Accumulator

If you use Docker, it’s almost certainly holding onto gigabytes of images, stopped containers, and volumes you forgot about.

Quick cleanup

docker system prune

This removes stopped containers, unused networks, dangling images, and build cache. It’s conservative — it won’t delete named images or volumes in use.

Aggressive cleanup

docker system prune -a --volumes

This also removes all unused images (not just dangling ones) and all unused volumes. Use this if you’re comfortable re-pulling images you need.

See what Docker is using

docker system df

This shows exactly how much space images, containers, volumes, and build cache are consuming. Often eye-opening.

Docker’s storage lives in a VM disk image on macOS, typically at: ~/Library/Containers/com.docker.docker/Data/vms/

DreamDisk will show you this as a large file — it’s the virtual disk that Docker writes into.

node_modules: Distributed Across Every Project

JavaScript projects are notorious for this. Each project’s node_modules folder is independent and often gigabytes in size, with heavy overlap across projects.

Find all node_modules on your machine

find ~ -name "node_modules" -type d -prune 2>/dev/null | xargs du -sh 2>/dev/null | sort -hr | head -20

This shows your top 20 largest node_modules folders by size. On most developer machines, the total is 20–80 GB.

Delete them safely

For any project you’re not actively working on:

rm -rf path/to/project/node_modules

Run npm install (or pnpm install, yarn) when you return to the project. The code is safe — node_modules is always regeneratable from package.json.

For a more automated approach, npkill lets you interactively find and delete node_modules folders:

npx npkill

Rust: The target/ Directory

Rust compiles everything from scratch and stores all artifacts in the target/ directory. On an active Rust project, this grows to 5–30 GB. On a machine with multiple Rust projects, the total is often 50–100 GB.

Clean individual projects

cargo clean

Run this inside a Rust project to delete its target/ directory. Like node_modules, this is completely regeneratable.

Find all target/ directories

find ~ -name "target" -type d -maxdepth 5 2>/dev/null | xargs du -sh 2>/dev/null | sort -hr | head -20

Rust’s build artifacts are among the largest per-project files on a developer machine. If you haven’t touched a Rust project in months, cargo clean it.

sccache

If you work on multiple Rust projects and don’t want to keep rebuilding from scratch, consider sccache (a shared compilation cache). It reduces redundancy across projects rather than just accumulating.

Python: Virtual Environments

If you create venvs with python -m venv without a central manager, they multiply across your filesystem.

Find large venv directories:

find ~ -name "pyvenv.cfg" -type f 2>/dev/null | xargs -I{} dirname {} | xargs du -sh 2>/dev/null | sort -hr | head -20

Consider switching to pyenv + virtualenvwrapper or uv to centralize environment management. For old projects you no longer touch, delete their venv directories — regenerate with pip install -r requirements.txt if you return.

Git: Large Object Storage

Some repositories contain large binary files tracked directly in git, or use Git LFS. These can consume significant disk space.

Check a repository’s size:

du -sh .git

For repositories with large .git directories, git gc --aggressive can sometimes recover space by repacking objects. For LFS, git lfs prune removes locally cached objects that have already been pushed to the remote.

A Faster Workflow: Scan First, Delete Second

The approaches above are targeted — but if you’re not sure where your biggest wins are, scan your disk visually first.

DreamDisk’s sunburst chart makes it immediately obvious which directories are consuming the most space. You can navigate directly into ~/Library/Developer/, see the Xcode breakdown visually, then drill into Docker’s VM image, then find the largest project directories — all in one fluid workflow.

As you explore, drag files and folders into the Junkyard to queue them for deletion. When you’re done, review the list and delete everything at once. It’s faster than running du commands and switching between Terminal and Finder.

Summary: Developer Storage Cleanup Checklist

Source	Command / Method	Typical Recovery
Xcode simulators	Xcode → Settings → Platforms	10–40 GB
Xcode Derived Data	`rm -rf ~/Library/Developer/Xcode/DerivedData/`	10–50 GB
Docker images/volumes	`docker system prune -a --volumes`	10–100 GB
node_modules	`npx npkill`	20–80 GB
Rust target/ dirs	`cargo clean` per project	20–100 GB
Python venvs	Delete unused venv directories	5–20 GB
Xcode archives	`~/Library/Developer/Xcode/Archives/`	2–20 GB

A single cleanup session using this checklist typically recovers 50–200 GB on a developer machine that hasn’t been cleaned in over a year.

For an ongoing habit: run a disk scan every couple of months, check Docker and Xcode specifically, and cargo clean or delete node_modules for any project you haven’t touched in 3+ months.

Related reading: