Linux disk full on a VPS: find what filled it, then stop it happening again

df -h          # space per file system; look for 100% under Use%
df -i          # inodes; 100% under IUse% means too many small files
lsblk          # every disk and partition, with its size

Check /, /boot and any mounted volume separately. A full /boot stops kernel updates even when / has room.

sudo du -xh --max-depth=1 / 2>/dev/null | sort -h | tail -15
sudo du -xh --max-depth=1 /var 2>/dev/null | sort -h | tail -15

-x stays on one file system, so a mounted volume does not hide the answer. Repeat one level down into the biggest folder. ncdu -x / does the same interactively if you can install it.

The usual suspects on a VPS:

Docker. See what Docker holds, then remove what nothing uses:

docker system df
docker image prune -a        # images no container uses
docker builder prune         # build cache
docker container prune       # stopped containers

Leave docker volume prune for last and read its list first: volumes hold databases and uploads.

Container logs. Docker’s default log driver writes one JSON file per container with no size limit. Find the biggest and empty it without stopping the container:

sudo sh -c 'du -h /var/lib/docker/containers/*/*-json.log | sort -h | tail -5'
sudo truncate -s 0 /var/lib/docker/containers/<id>/<id>-json.log

The systemd journal.

sudo journalctl --disk-usage
sudo journalctl --vacuum-size=500M

Packages and old kernels on Debian and Ubuntu:

sudo apt clean
sudo apt autoremove --purge

autoremove is also the fix when /boot is full of old kernels. If /boot is at 100% and apt itself fails, remove one old kernel package by name with sudo apt remove linux-image-<version>, never the one uname -r shows, then run autoremove.

• A deleted file is still open. Deleting a log that a process still writes to frees nothing until the process lets go. sudo lsof +L1 lists them; restart that service, or truncate the file instead of deleting it next time.
• Out of inodes. df -i at 100% means millions of small files, often a cache or session folder. Find it with sudo du --inodes -x --max-depth=1 / | sort -n.
• Reserved blocks. ext4 keeps 5% of the disk for root by default, so ordinary users see the disk as full first.
• Files under a mount point. Files written to a folder before a volume was mounted over it still use space but are hidden. Unmount the volume, or bind-mount / elsewhere, to see them.

Cap Docker logs for every new container in /etc/docker/daemon.json, then restart Docker. Existing containers keep their old settings until they are recreated.

{ "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3" } }

Cap the journal with SystemMaxUse=500M in /etc/systemd/journald.conf, then run sudo systemctl restart systemd-journald. Make sure your own app logs go through logrotate, and schedule docker image prune -a -f and docker builder prune -f on servers that build images.

Cleaning up treats the symptom. What prevents the outage is knowing the disk is filling days before it is full, which no df you run by hand will tell you.

Most VPS consoles graph what the host can see, such as CPU, disk I/O and network, but not how full your disk is, and few alert on it. See what each one shows: Hetzner disk full, Linode monitoring, Vultr monitoring, OVHcloud monitoring, Hostinger VPS monitoring and Scaleway monitoring. DigitalOcean Droplets and Coolify warn on disk usage themselves (see DigitalOcean Droplets monitoring and Coolify monitoring).