CI Cache Directory Bloat Filling Runner Disk

By Kaveh Alemi·Latchkey

Caches make builds fast - until they grow without bound and fill the disk. On reused runners, dependency, layer, and build caches accumulate stale entries that nothing ever evicts.

What this error means

Builds run fine for a while, then start failing with No space left on device. The culprit is a steadily growing cache directory (~/.cache, ~/.gradle, ~/.m2, BuildKit cache, ~/.cargo) that keeps every version it has ever seen.

No space left on device
# investigation:
$ du -sh ~/.cache ~/.gradle ~/.m2 /var/lib/docker 2>/dev/null
18G   /var/lib/docker
7.2G  ~/.gradle
3.1G  ~/.cache

Common causes

Caches accumulate every version forever

Dependency and build caches add new entries on each run but rarely evict old ones. Over many jobs, obsolete versions and layers dominate the cache size.

Reused runners never start clean

On a self-hosted or long-lived runner the cache persists across jobs by design. Without a size cap or prune, it grows until it fills the disk.

How to fix it

Find and measure the big caches

du -sh ~/.cache ~/.gradle ~/.m2 ~/.cargo /var/lib/docker 2>/dev/null | sort -rh

Prune and bound the caches

1. Prune build-tool caches (docker builder prune, go clean -cache, npm cache clean --force).
2. Add a size limit or retention policy where the cache tool supports it.
3. Key hosted caches (actions/cache) on a lockfile hash so stale entries roll off instead of stacking.

How to prevent it

• Bound or periodically prune caches on long-lived runners.
• Key caches on lockfile hashes so they self-rotate.
• Track cache directory sizes alongside df -h in CI.

Frequently asked questions

Related guides

References

• GitHub Actions documentation