GitLab CI "no space left on device" (Runner Disk Full)
By Kaveh Alemi·Latchkey
A step failed because the runner ran out of disk. Accumulated Docker images, caches, build outputs, or artifacts filled the volume mid-job.
What this error means
A build, checkout, or artifact step dies with "no space left on device" / "write error: No space left on device". It often starts intermittently on a busy runner and worsens over time.
gitlab-ci
tar:write error: No space left on deviceERROR:Job failed: exit code 2# orfailed to register layer:write /usr/lib/...: no space left on device
Diagnose it: which rule matched, and on which runner?
GitLab evaluates rules: top to bottom and the first match wins, including one that sets when: never. A job that does not run, or runs when you did not expect it to, is nearly always matching an earlier rule than the one you are reading.
.gitlab-ci.yml
# validate the definition against the projectcurl -s --header "PRIVATE-TOKEN:$TOKEN" \"https://gitlab.com/api/v4/projects/$CI_PROJECT_ID/ci/lint" \--data-urlencode "content=$(cat .gitlab-ci.yml)"# what the job actually seesscript:- env | grep -E "^CI_(PIPELINE_SOURCE|COMMIT_REF_NAME|RUNNER)" | sort
Common causes
Runner host disk filled
Long-lived runners accumulate dangling Docker images, build caches, and old artifacts until the volume is full. The next job fails on the first large write.
A single job writes too much
A job that unpacks huge images, generates large build outputs, or downloads big datasets can exhaust even a freshly cleaned disk.
How to fix it
Reclaim disk on the runner host
Prune unused Docker data and stale build directories.
Runner host
docker system prune -af --volumes
df -h
# remove old build dirs under the runner's builds_dir if safe
Reduce per-job footprint
Use smaller base images and multi-stage builds to shrink layers.
Limit cache and artifact sizes; expire old artifacts sooner.
Schedule periodic cleanup, or use ephemeral runners that start with a clean disk.
How to prevent it
Run docker system prune on a schedule for long-lived runners.
Prefer ephemeral runners that reset disk between jobs.
Keep cache and artifact sizes bounded with short expiry.
Frequently asked questions
What causes GitLab CI "no space left on device" (Runner disk Full)?
There are 2 common causes: runner host disk filled and a single job writes too much. Long-lived runners accumulate dangling Docker images, build caches, and old artifacts until the volume is full.
How do I fix GitLab CI "no space left on device" (Runner disk Full)?
There are 2 fixes depending on which cause you have: reclaim disk on the runner host and reduce per-job footprint. Work through them in order, since the first is the most common.
What does GitLab CI "no space left on device" (Runner disk Full) actually mean?
A build, checkout, or artifact step dies with "no space left on device" / "write error: No space left on device".
How do I stop GitLab CI "no space left on device" (Runner disk Full) happening again?
Run docker system prune on a schedule for long-lived runners. The prevention section lists 3 changes that keep it from recurring.
Can Latchkey fix this automatically?
Yes. Latchkey runs your GitHub Actions on managed runners that detect this failure, apply the fix, and retry the job automatically - self-healing is on by default.
This is disk exhaustion on the runner, not a bug in your code. Latchkey detects, repairs, and retries it for you.Start free →30-day trial · No credit card
Cookie Preferences
Choose which categories of cookies you want to allow. Essential cookies are always active as they are required for the site to function.
Essential
Required for the site to function.
Functional
Remembers your preferences like selected organization and dashboard settings.
Analytics
Helps us understand how the site is used (Google Analytics).