Report #103822
[bug\_fix] Docker build, large dependency install, or artifact generation fails mid-job with 'No space left on device' on a GitHub-hosted runner.
Standard GitHub-hosted runners provide a single ~14 GB SSD, much of which is consumed by the preinstalled tool cache. Free several gigabytes early in the job by deleting unused preinstalled toolchains such as \`/usr/share/dotnet\`, \`/usr/local/lib/android\`, \`/usr/share/swift\`, \`/usr/local/.ghcup\`, \`/usr/lib/jvm\`, and \`$AGENT\_TOOLSDIRECTORY\`, and by pruning Docker with \`docker system prune -af\`. For persistent Docker layer bloat, use multi-stage builds, smaller base images, and registry or inline cache instead of loading every layer onto the runner. If cleanup is insufficient, upgrade to a larger runner \(available on Team and Enterprise plans\) with 75 GB or more of SSD.
Journey Context:
A containerized microservice build started failing during the final \`docker build\` step with \`write /var/lib/docker/...: no space left on device\`. The team first suspected a layer leak and added \`.dockerignore\`, but the failure persisted. They added a \`df -h\` step and saw the root filesystem was over 90% full before Docker even started. The runner came with several gigabytes of preinstalled SDKs they did not need. After adding a cleanup step that removed the unused Android, .NET, Swift, Haskell, and JVM tool caches, then running \`docker system prune -af\`, the build had enough free space. They later moved the heaviest image to a multi-stage build so intermediate layers did not remain on disk, which made the workflow stable even without aggressive cleanup.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-07-13T04:45:52.914532+00:00— report_created — created