Is it safe to delete node_modules, DerivedData and other developer caches?
Mostly yes: build folders and package caches come back on their own. But a few folders that look like caches hold real work, and deleting those costs far more than disk space. Here's how to tell them apart.
The rule of thumb
- Rebuilds Build output and package caches. Deleting them loses nothing, but the next build or install is slower and may need a download.
- Check first Folders that hold things only you have: simulator data, archives of shipped apps, Docker volumes, models you trained. Look before you delete.
- Quit the tool first. Deleting a cache while Xcode, Docker or a package manager is running can leave it confused.
Folder by folder
| Folder | Kind | What deleting costs | The proper way |
|---|---|---|---|
| node_modules Inside each JavaScript project | Rebuilds | Reinstalls with npm install (or yarn, pnpm). Takes a minute and a download. | Delete it in projects you aren't working on. |
Xcode DerivedData~/ | Rebuilds | The next build is slower while Xcode rebuilds its indexes. | Quit Xcode, then delete the folder (or one project's folder inside it). |
iOS Simulators~/ | Check first | Each simulator holds the apps and data you installed in it. | xcrun simctl delete unavailable removes simulators for runtimes you no longer have. |
Device support files~/ | Rebuilds | Xcode downloads them again the next time you connect that device. | Delete versions for devices you don't use any more. |
Xcode archives~/ | Check first | You need them to read crash reports for versions you shipped. | Keep archives of released versions; delete test builds. |
npm cache~/ | Rebuilds | Packages download again when needed. | npm cache clean --force |
Homebrew downloads~/ | Rebuilds | Only old downloads; installed tools stay. | brew cleanup |
Python packages (uv, pip)~/, pip's cache | Rebuilds | Packages download again when needed. | uv cache clean or pip cache purge |
Python virtual environments.venv inside projects | Rebuilds | Recreate with python -m venv and your requirements file. | Run pip freeze > requirements.txt first if there isn't one. |
Rust build outputtarget inside Rust projects | Rebuilds | The next build compiles everything again. | cargo clean in the project. |
Go modules~/ | Rebuilds | Modules download again when needed. | go clean -modcache |
Gradle caches~/ | Rebuilds | Dependencies download again on the next build. | Delete the caches folder with no builds running. |
| Docker Docker Desktop's disk image | Check first | Holds all images, containers and volumes, including databases. | docker system prune removes stopped containers, unused networks and dangling images. Never delete the disk image file itself. |
Hugging Face models~/ | Rebuilds | Models download again when a script needs them, often many gigabytes. | huggingface-cli delete-cache lets you pick what to remove. |
Ollama models~/ | Rebuilds | Download again with ollama pull. | ollama rm <model> keeps Ollama's index consistent. |
LM Studio models~/ | Check first | Downloaded models can be fetched again, but models you made or converted yourself (in models/local) can't. | Delete from LM Studio's model list; back up your own models first. |
Use the tool's own command when there is one
Commands like brew cleanup, npm cache clean --force or ollama rm know which files belong together. Deleting folders by hand works for build output, but for package managers and model stores the built-in command keeps their bookkeeping consistent.
How Diskscape helps
Diskscape recognises all of these folders, shows how much each one takes on the map, and sorts them into the same three kinds used above. It only looks for project folders like node_modules inside your own folders, never inside apps or system locations, and it warns clearly before you delete anything in the "check first" group.
See it on your own Mac. Diskscape maps your whole disk, finds these folders for you, sorts them by what deleting costs, and warns before you delete anything that holds your own work. It never connects to the internet.