A single Next.js dev server grew a 48GB cache on this machine. Here is exactly how we found it — and got it all back.

Every command below is scoped to caches that rebuild themselves. Nothing here touches your source code, your git history, or your data. Read the caption under each snippet before you run it — the order matters, and one step will surprise you.

🔍 Quick Scan: Find Out What's Actually Full

bash

# Check real free space (macOS splits system and data volumes)
df -h /System/Volumes/Data

# Size up your project's usual suspects
du -sh .next node_modules 2>/dev/null
du -sh ~/Library/Caches 2>/dev/null

bash

# Drill into the biggest folder to find the real culprit
du -sh .next/* 2>/dev/null | sort -rh | head -10
du -sh .next/dev/* 2>/dev/null | sort -rh | head -10

.next/dev/cache: Turbopack dev cache — grows unbounded across long dev sessions (can hit 50GB+)
.next/cache: Build cache from production builds (1-5GB)
node_modules: Dependencies — huge across many projects (0.5-2GB each)
~/.npm: npm's global download cache (2-10GB)
~/Library/Caches: App and toolchain caches (5-20GB)

⚠️ Safety First: Before You Delete Anything

Only delete folders named cache — never a folder you can't identify
Commit and push any uncommitted work first
Expect slower first compiles after cleanup — caches rebuild on demand
Never run rm -rf with sudo on paths you didn't verify with du first

🧹 Step-by-Step Cleanup Commands

bash

# From your project root — clear Next.js / Turbopack caches
rm -rf .next/cache
rm -rf .next/dev/cache

bash

# Package manager caches (all safe — re-downloaded as needed)
npm cache verify        # compacts and garbage-collects first
npm cache clean --force # nuclear option

# If you use pnpm or yarn:
# pnpm store prune
# yarn cache clean

bash

# Find every node_modules across old projects (review the list first!)
find ~/Developer ~/Projects -name "node_modules" -type d -prune 2>/dev/null | xargs du -sh | sort -rh

# Delete only for projects you're not actively working on:
# rm -rf ~/Projects/old-project/node_modules

👻 The Hidden Gotcha: Deleted Files That Don't Free Space

This is the step that surprises everyone. If your dev server is running while you delete its cache, macOS keeps the space allocated until the process closes its file handles. On this machine, 51.7GB stayed "used" after deletion — held hostage by a running npm run dev.

bash

# Detect deleted-but-still-open files and total their size
lsof +L1 2>/dev/null | awk '$NF ~ /\.next/ {sum += $7} END {printf "held by running processes: %.1f GB\n", sum/1e9}'

bash

# Restart the process that holds the handles — space frees instantly
# 1. Stop your dev server (Ctrl+C in its terminal)
# 2. Start it again
npm run dev

# Verify the space came back
df -h /System/Volumes/Data

🔧 System-Level: Time Machine Local Snapshots

bash

# Local snapshots can silently retain deleted data
tmutil listlocalsnapshots /

# Ask macOS to thin them down (frees purgeable space)
# sudo tmutil thinlocalsnapshots / 20000000000 4

📱 What to Expect After Cleanup

First dev compile: Slower while Turbopack rebuilds its cache (one-time cost)
First production build: Longer without .next/cache
npm installs: Re-download packages that were cache-cleaned
Immediate benefit: 50GB+ of reclaimed storage on a busy dev machine

bash

# Verify your savings
df -h /System/Volumes/Data
du -sh .next 2>/dev/null

🤖 Automation Tip

bash

#!/bin/bash
# dev-cache-cleanup.sh - Run monthly, from your project root
echo "Cleaning web dev caches..."
rm -rf .next/cache .next/dev/cache
npm cache verify
echo "Restart your dev server to release held space."
echo "Cleanup complete!"

“The disk wasn't full. The dev server just refused to let go.”
— unparty-app