CI "No space left on device" - Free Runner Disk

By Kaveh Alemi·Latchkey

A write failed with ENOSPC - the runner’s filesystem is full. The error comes from the kernel, so it can surface from any step that writes: a download, an extract, a compile, or an artifact upload.

What this error means

A step fails mid-write with No space left on device. It can appear while extracting an archive, writing a build output, caching dependencies, or saving an artifact. Re-running on a fresh runner - or after cleanup - succeeds with no code change.

tar: write error: No space left on device
# or
write /home/runner/work/.../bundle.js: no space left on device
##[error] Process completed with exit code 1.

Common causes

Accumulated caches, layers, and artifacts

On a reused or long-lived runner, dependency caches, container layers, and old artifacts pile up across jobs until the disk fills.

A single job writes more than the disk holds

Large checkouts, generated assets, datasets, or build outputs can exhaust a small runner disk within one job, even on a clean runner.

How to fix it

See where the space went

Check free space and the biggest consumers before deleting anything.

df -h
du -xh / 2>/dev/null | sort -rh | head -20

Reclaim space

Prune the usual offenders. On a CI runner this is safe because the next job starts fresh.

docker system prune --all --force --volumes
sudo rm -rf /usr/share/dotnet /opt/ghc /usr/local/lib/android
df -h

Write less per job

1. Use a shallow clone (fetch-depth: 1) so the checkout is smaller.
2. Stream or clean up large downloads instead of keeping them on disk.
3. Move image-heavy or dataset-heavy jobs to runners with bigger disks.

How to prevent it

• Add a cleanup/prune step at the start of jobs on long-lived runners.
• Monitor df -h in CI to catch creeping disk usage early.
• Use larger-disk runners for image- or data-heavy pipelines.

Frequently asked questions

Related guides

References

• GitHub Actions documentation