Developer storage cleanup

Go Build Cache Taking Too Much Disk Space

If go env GOCACHE points to a cache that has grown into tens or hundreds of gigabytes, treat it as regenerable build cache first. Measure it, make sure no build is running, then clean the Go cache without touching repositories, modules, or local databases.

What Is Usually Safe

The Go build cache is normally regenerable. Cleaning it may make the next build slower, but it should not delete your source code. The risky part is confusing build cache with module cache, project directories, Docker volumes, or generated artifacts that you still need.

go env GOCACHE GOMODCACHE GOPATH

gocache="$(go env GOCACHE)"
du -sh "$gocache" 2>/dev/null
find "$gocache" -maxdepth 2 -type f -print0 2>/dev/null \
  | xargs -0 du -h 2>/dev/null | sort -rh | head -30

du -sh "$(go env GOMODCACHE)" 2>/dev/null
df -h "$gocache" "$PWD" 2>/dev/null

Cleanup Order

1. Stop active go test, go build, IDE indexing, and CI jobs on the machine.
2. Measure GOCACHE and GOMODCACHE separately so you know what is cache versus downloaded modules.
3. Clean build cache first with go clean -cache.
4. If test artifacts are the issue, also consider go clean -testcache.
5. Only clean module cache with go clean -modcache if you are willing to re-download dependencies.
6. Run the build again and watch whether cache growth is one-time or recurring.

go clean -cache
go clean -testcache

du -sh "$(go env GOCACHE)" 2>/dev/null
df -h "$(go env GOCACHE)" "$PWD" 2>/dev/null

Do Not Delete First

• Do not remove your project directory because go test generated a large cache.
• Do not delete Docker volumes or database folders just because a Go build failed with ENOSPC.
• Do not run go clean -modcache on a slow or offline network unless you accept re-downloading modules.
• Do not wipe $GOPATH blindly; it can contain source checkouts or tools on older setups.