Where a developer machine’s disk actually goes

Dependency trees, build directories and package manager caches, ranked by how much they hold and how cheaply they come back.

Updated 2026-09-20

When a developer machine fills up, the answer is almost never photos. It is a few thousand directories that were downloaded or compiled, are all individually reasonable, and have never once been deleted. Here is the ranking, and the thing that matters about each: how much it holds versus how expensive it is to get back.

1. Dependency directories

node_modules, .venv, vendor/, Pods/, deps/. These are the largest total and the cheapest to restore, because a lockfile describes every byte of them and restoring is a download you have probably already cached. One node_modules is tens to hundreds of megabytes; thirty of them is the single biggest number on most machines.

They are also the safest thing to delete, and the reason is worth stating plainly: you can prove it. Every one of these managers has a command that verifies the lockfile without installing, so "can this be rebuilt" is a question with a real answer rather than a guess. Is it safe to delete node_modules goes through those commands.

2. Build directories

Rust's target/, Gradle's build/ and .gradle/, Maven's target/, SwiftPM's .build/. Individually these are the biggest single directories you own — a Rust workspace's target/ passing several gigabytes is ordinary, and there is a reason for that.

But they are not the same decision as a dependency directory, because getting one back is a compile, not a download. Deleting a 4 GB target/ reclaims 4 GB and costs you a cold build the next time you touch that project. That is a fine trade for something you have not opened since spring and a bad one for last week's work, which is why dev-prune leaves all four of these off unless you turn them on (devp config), and gives them their own idle window when you do.

3. Package manager caches

~/.npm, the pnpm store, ~/.cargo/registry, $GOMODCACHE, ~/.m2/repository, ~/.gradle/caches. Shared, machine-wide, and frequently several gigabytes each.

These are the ones to be careful with, and not for the reason people assume. They are safe — everything in them re-downloads. The problem is that the cache is what makes everything else in this list cheap to delete. Clear node_modules across thirty repositories with a warm npm cache and the restores are near-instant; clear the cache too and every one of those restores becomes a network round trip. Delete dependency directories freely; treat the cache as a separate, occasional decision. Clearing package manager caches safely has the per-manager commands.

4. Everything else

Docker images, iOS simulators and Xcode DerivedData, old toolchain versions from rustup, nvm and pyenv. Genuinely large, genuinely reclaimable, and each has its own vendor command that does it properly — docker system prune, xcrun simctl delete unavailable, rustup toolchain uninstall. Worth a pass once a year; not worth automating.

Doing this on a schedule instead of in a panic

The problem with a manual cleanup is that it happens when the disk is already full, which is the worst moment to be making decisions about what is safe to delete. The alternative is to make it continuous and boring: a background pass that only ever touches repositories that are idle, only deletes what a lockfile can rebuild, and refuses when it cannot prove that.

curl -fsSL https://devprune.vkrishna04.me/install.sh | sh
          devp init ~/Code
          devp run --dry-run

--dry-run deletes nothing and prints the total. That is the number worth looking at before deciding whether any of this is a problem you have.