GitHub Actions "No space left on device": 6 fixes that work
⏱️ 2 min read
GitHub-hosted runners have roughly 14GB of usable disk, and modern builds eat it embarrassingly fast: Docker layers alone can take 10GB before your first test runs. Here's what actually frees space, in order of payoff.
1. Clean as you build
For Docker builds, run docker system prune -a -f --volumes after the step that needs it, not in a separate job — the cache lives on the same runner only if you use GHA's cache backend, otherwise layers you keep cost you disk twice.
2. Trim your image
If your build pulls a base image, build with --pull and delete dangling layers before the next build: docker image prune -f. Better: switch to multi-stage builds so your final image doesn't ship the compiler.
3. Stop caching what you don't use
actions/cache restores to the runner's disk. Caching node_modules AND ~/.npm AND build artifacts triple-counts the same bytes. Cache the minimal key that gives you the speedup.
4. Use larger runners or containers for the heavy steps
A 30GB+ runner for the Docker-heavy job removes the constraint entirely. If the bill matters, split the workflow: fast tests on standard runners, the image build on one beefy job.
5. Free space before you start
Preinstalled toolchains (Android SDKs, .NET, CodeQL) take ~25GB of the runner. A cleanup step that removes the SDKs you don't use can double your free space on day one — many popular actions do exactly this.
6. Move the build off the runner
Push a tarball to a build service, or run Docker builds with BuildKit's cache-from/cache-to registry backends so layers never live on the runner's disk at all.
Reproducing disk-pressure bugs locally before they cost you CI minutes: the same logic on a disposable server — droplet here — with a realistic disk size beats guessing on the runner.