Where is the Bun cache location on Mac and how do I clean it safely?

A quick du -sh ~/.bun on a Mac that has been running Bun for a year often returns something north of 9 GB, almost all of it inside install/cache. Bun never tells you, because the number disappears into macOS Storage's gray System Data bar with everything else. This is the same long-tail JS cache pain captured at brtkwr.com when a developer freed 200 GB on a full disk: "After the initial Docker/cache cleanup freed 150GB, going back and asking 'what else?' found another 75GB." Bun cache is one of those "what else" wins.

Where is the Bun cache location on Mac?

Bun's install cache lives at ~/.bun/install/cache by default on macOS. It is a flat directory of subfolders named after each package and version, each containing the decompressed contents of an npm tarball. Bun does not use ~/Library/Caches/, does not write into ~/.cache/, and does not piggyback on the npm cache. It is its own tree, owned by Bun, and only Bun keeps it tidy.

The one command that tells you the truth, regardless of how Bun was installed or what bunfig.toml overrides are in place, is this:

# Print the absolute Bun cache location Bun is using right now
bun pm cache

# And the honest size of that directory specifically
du -sh "$(bun pm cache)"

That second number is the one to trust. Finder's Get Info on ~/.bun will include the Bun runtime binary, the bunx cache, and any global tools you installed with bun add -g, none of which you should be touching as part of a cache cleanup.

Why does the Bun cache get so big?

Three reasons stack up.

First, Bun decompresses tarballs into the cache, so the on-disk size is closer to a node_modules install than to a .tgz archive. A package that ships as a 4 MB tarball can sit as 18 MB of decompressed JavaScript and source maps inside the cache.

Second, Bun keeps every version it has ever installed unless you ask it not to. If your team upgraded vite from 4.3 to 5.0 to 5.1 to 5.2 over the last six months, you have four full copies in the cache, hardlinked into whatever projects still pin them.

Third, Bun's cache is content-addressable per package version, not per file. The pnpm store deduplicates at the file level using hardlinks, so two packages that share an identical LICENSE file cost zero extra bytes. Bun does not do that. Two versions of the same package with one changed line cost you the full decompressed size of both.

The table below is what the install cache footprint looks like on a Mac with a year of mixed monorepo work.

Add those rows and a polyglot JS dev Mac has 20 to 50 GB of install caches before the first node_modules folder. The Bun cache is not the biggest of them in absolute terms, but it is the one nobody is auditing, because Bun is the newest tool in the stack.

How do I check the Bun cache location and size honestly?

A safe audit is three steps. First, ask Bun where the cache really lives. Second, measure that directory directly. Third, list the per-package subfolders so you know which versions are taking the space.

# 1. Confirm the Bun cache location for this shell
bun pm cache

# 2. Honest size of the cache directory itself
du -sh "$(bun pm cache)"

# 3. Top 20 fattest packages in the cache, biggest first
du -sh "$(bun pm cache)"/*/ 2>/dev/null \
  | sort -hr \
  | head -20

The third command is the one that tells you whether the cleanup is worth doing. If the heaviest entries are next, vite, webpack, puppeteer, playwright, or anything bundling a Chromium binary, expect 200 MB to 1 GB per entry. If the top of the list is a long list of 10 MB packages, the cache is healthy and the real disk pig is somewhere else, probably node_modules or Docker.

For the wider audit beyond Bun, see find-all-node-modules-mac for the per-project sweep and pnpm-store-cleanup for the parallel cleanup on the pnpm side.

How do I run bun pm cache rm safely?

bun pm cache rm deletes the entire Bun cache directory. It does not touch any node_modules folder. It does not break a running bun dev. It does not invalidate bun.lockb. The only cost is that the next bun install in every project has to re-fetch each package from the registry.

# Quick before-and-after check
du -sh "$(bun pm cache)"

# Wipe the cache
bun pm cache rm

# Confirm
du -sh "$(bun pm cache)" 2>/dev/null || echo "cache empty"

If you want the rollback safety of Finder Trash instead of a hard delete, move the cache directory to ~/.Trash with a timestamp and let it sit for a week.

# Move-to-Trash style: keeps a 7-day rollback window
CACHE_DIR="$(bun pm cache)"
STAMP="$(date +%Y%m%d-%H%M%S)"
mv "$CACHE_DIR" "$HOME/.Trash/bun-install-cache-$STAMP"

That second pattern is what CleanMyDev does for every cleanup target: it never calls rm -rf, it routes deletions to Finder's Trash with a timestamp and a per-row receipt, so a regret on Tuesday is a five-second restore, not a four-hour reinstall. The skeptical-dev safety argument behind that default is at why-cleanmydev-shows-receipts.

Can I move the Bun cache to an external SSD?

Yes. On a 256 GB or 512 GB MacBook this is often the right call, because the install cache is exactly the kind of data that is large, regenerable, and not latency-sensitive enough to require internal SSD.

There are two ways. The environment variable wins on a per-shell basis and is great for CI.

# Per-shell, also works in CI
export BUN_INSTALL_CACHE_DIR="/Volumes/Externals/bun-cache"
bun install

The bunfig.toml override is what you want for permanent local development. Drop this into the project root, or into ~/.bunfig.toml for a global default.

[install.cache]
dir = "/Volumes/Externals/bun-cache"

After either change, run bun pm cache again to confirm the Bun cache location now points where you expect, then run any bun install to populate it. Once you are confident the new location works, move the old ~/.bun/install/cache to Trash with the timestamped pattern above.

What is the safe Bun cache cleanup order?

The order matters when disk is tight. Each step is reversible from Trash for seven days, and each step recovers a known amount.

1. Confirm the cache location with bun pm cache, measure with du -sh.
2. List the top 20 heaviest package directories. If nothing is over 200 MB, stop, the cache is fine.
3. Move the entire cache to Trash with the timestamped command above. Reclaim is immediate.
4. Run du -sh ~/Library/pnpm/store/v3 ~/.npm/_cacache ~/Library/Caches/Yarn 2>/dev/null to see whether the other install caches deserve the same treatment.
5. Restart any editor that watches the cache, so its file-watcher rebuilds cleanly.
6. On the next bun install, expect a slower cold start. Subsequent installs are normal speed.
7. After seven days, empty Trash if nothing regressed.

This is the same safety floor pnpm-store-cleanup uses for the parallel cleanup on pnpm and it is the floor CleanMyDev uses across every JS cache and AI cache target it ships with.

What does CleanMyDev do for Bun cache that the CLI does not?

bun pm cache rm is one button: delete everything. CleanMyDev gives you the full picture before you click anything. It maps Bun, npm, pnpm, Yarn classic, Yarn Berry, Playwright browser binaries, and every per-project node_modules on the same screen, with per-row size, last-modified date, and risk label. You tick the rows you want to reclaim, you see the cumulative number update live, and the deletions land in Finder Trash with a timestamp so a Monday morning regret is a single restore.

If you have been chasing the System Data gray bar for a week and you are tired of writing one-off shell scripts per tool, grab CleanMyDev for $9.99 lifetime on the pricing page. One purchase, no subscription, no telemetry, covers the Bun cache and every other JS, AI, and Xcode cache discussed across this blog.

Related reading

• npm-cache-location-mac for the npm side of the same audit.
• pnpm-store-cleanup for the pnpm store equivalent.
• find-all-node-modules-mac for the per-project sweep that complements an install-cache cleanup.