Skip to content
compiler.dev
Start free

No Space Left on Device in GitHub Actions: Fixes

Last updated

The error No space left on device means the runner's disk filled up during your job, usually in a Docker build, a large dependency install or a big artifact step. GitHub's standard Linux runners list 14 GB of SSD storage, so a job that downloads images, builds a large project and caches it can run out. Below are the causes in order of how often they happen, with fixes you can paste. The disk figure comes from the GitHub-hosted runners reference, checked October 2026.

The exact message

You will see one of these in the failing step:

System.IO.IOException: No space left on device
ENOSPC: no space left on device, write
write /var/lib/docker/...: no space left on device
OSError: [Errno 28] No space left on device

The wording changes with the tool, but the cause is the same: the filesystem has no free blocks (or no free inodes). The same text can also appear on a self-hosted runner, where the disk is yours to size.

Check what is using the disk

Add this step before the failing one, and again after, to see what grew:

- name: Disk usage
  if: always()
  run: |
    df -h
    sudo du -xh / --max-depth=2 2>/dev/null | sort -rh | head -20
    docker system df

If df -h shows free space but the error persists, check inodes with df -i. Millions of tiny files in node_modules can exhaust inodes first.

Causes, most likely first

1. Docker images, layers and build cache

Every docker pull, docker build and service container writes to /var/lib/docker. Multi-stage builds with large base images are the usual culprit. Remove what you no longer need between steps:

- name: Free Docker space
  run: |
    docker image prune -af
    docker builder prune -af
    docker system df

Use docker system prune -af --volumes only if no later step needs the volumes. The Docker pruning docs explain what each command removes. Smaller base images (-slim, -alpine) and a .dockerignore file also cut usage. More on build caching in Docker layer caching in CI.

2. Preinstalled toolchains you never use

The hosted Ubuntu image ships with many SDKs. If your job does not use Android, .NET or Haskell, deleting them frees several GB. These paths are commonly removed, but they are image details that GitHub can change, so verify with du first:

- name: Free disk space
  run: |
    sudo rm -rf /usr/share/dotnet
    sudo rm -rf /usr/local/lib/android
    sudo rm -rf /opt/ghc
    sudo rm -rf /opt/hostedtoolcache/CodeQL
    df -h /

Deletion takes a minute or two, so only do it when you hit the limit. Do not remove tools your job calls later. The list of preinstalled software is in the runner-images repository.

3. Build output, caches and artifacts

Large target/, build/ or .gradle directories, plus restored caches, all land on the same disk. Clean intermediate output as you go, and avoid restoring a cache larger than you need (see cache limits). In Gradle, run ./gradlew --stop and delete build caches you do not need. In Rust, splitting the build into jobs helps more than cargo clean.

4. Too much in one job

Checking out a large monorepo, building every image and running every test in one job puts all disk use on one machine. Split the work into several jobs, or use a test sharding matrix, so each job writes less. Use a shallow clone with fetch-depth: 1 when you do not need history.

5. Logs and temp files from tests

Test suites that write videos, core dumps or verbose logs can add GBs. Write them to a directory you upload and delete, or turn down the verbosity.

Fixes when cleanup is not enough

  • Larger runner. GitHub's larger runners have more resources than standard ones; check the current sizes on the larger runners page. They are always charged per minute, even for public repositories.
  • A different runner provider. compiler.dev runs the same job on an 8 vCPU / 16 GB machine with a fresh VM per job, which also helps when disk trouble comes with memory pressure (see exit code 137). The change is one line, runs-on: [self-hosted, Linux, compiler-ci]; see pricing.
  • Self-hosted runner. You choose the disk, but you also own cleanup. Add a scheduled job that runs docker system prune on the host.

How to prevent it

  1. Log df -h at the start and end of every heavy job so growth is visible over time.
  2. Pin smaller base images and use multi-stage Dockerfiles that copy only the final artifact.
  3. Prune Docker between build stages in jobs that build more than one image.
  4. Keep caches focused on package download directories, not whole build trees.
  5. Split large jobs. A job that needs 20 GB is probably two jobs.

Related errors: hosted runner lost communication often appears when a runner is starved of resources, and cache not found appears when large caches get evicted.

FAQ

How much disk space does a GitHub Actions runner have?

GitHub lists 14 GB of SSD storage for standard Linux runners such as ubuntu-latest, for public and private repositories, as of October 2026. Run df -h in a step to see the real free space, which is lower because the OS and tools use part of it.

Is it safe to delete /usr/share/dotnet and /usr/local/lib/android?

Yes, if your job does not use them. The runner is a fresh VM, so deletion only affects the current job. Do it before your build starts, and do not delete anything a later action needs.

Why does Docker fill the disk so quickly?

Layers from pulled images, intermediate build layers and build cache are all stored locally. A few large images easily exceed several GB. Prune, or use smaller images.

Can I add more disk to a hosted runner?

Not as a documented setting for standard runners. Use a larger runner, a self-hosted runner or a provider whose machines have bigger disks.

Related