Docker filling the disk: images, volumes and logs

Docker fills a VPS disk in three ways: the images and layers left behind after updates, the volumes nobody uses, and the container logs, which by default grow without end. The typical error is “No space left on device”, and the symptom is a database that stops or a container that will not start. First you measure; then you clear only what you are sure you can lose.

First: where is the space

1 See the whole disk: df -h. Find the line for the main partition and the “Use%” column.
2 See what belongs to Docker: docker system dfIt shows images, containers, volumes and the build cache, and how much of the space is reclaimable.
3 See the largest directories on the system, if Docker does not explain it all: sudo du -xh --max-depth=1 /var | sort -hDocker’s data normally lives in /var/lib/docker.

Cleaning up, from safest to riskiest

What takes space Command Risk
Untagged or unused images docker image prune Low: it pulls again whatever you need.
Stopped containers docker container prune Low, but check what is there first with docker ps -a.
Build cache docker builder prune Low: later builds are slower.
Every image no container uses docker image prune -a Medium: you will have to pull them again.
Volumes with no container docker volume ls and only then docker volume rm name High. A volume may hold your database. Delete one at a time, knowing what it is.

The logs that grow without end

Each container writes whatever the application prints to a log file on the server, and by default that file has no limit. A chatty application, or one failing in a loop, can fill the disk with that alone. To see it: sudo du -sh /var/lib/docker/containers. The fix is to cap the size and the number of files, in Compose:services:
  app:
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"
The values are examples; pick your own. The rule applies to containers created after the change: recreate them with docker compose up -d --force-recreate. To free the space of a gigantic log right now, as an emergency: sudo truncate -s 0 $(docker inspect --format="{{.LogPath}}" container-name).

Beware of docker system prune -a --volumes. It is the command that appears in every guide and the one that most often deletes a database. Use it only on a server where you know exactly what is in each volume, and with a backup made. When in doubt, the safer commands in the table above are enough.
Set a limit from the start. Capped logs and a look at the disk now and then prevent the emergency. If the disk on your plan is small for what runs on it, see common VPS and Cloud errors, and how to update without losing data so that images do not pile up.

The disk filled up and you can no longer get in over SSH? Open a ticket: we help you recover access. Deciding what to delete inside the server is up to you.

Open a support ticket

SEE ALSO

Common VPS and Cloud errors: SSH, memory, disk and reboots

Updating a Docker application without losing data

Backing up a VPS: snapshots or files

RECOMMENDED PRODUCT

Web hosting with cPanel

Domain and SSL included, daily backups and the panel you already know. from $6.59/mo (3-year plan, with coupon)

See plans
  • 0 Users Found This Useful
Was this answer helpful?