Skip to content
JS BRAND LAB

VPS · Problems

VPS out of disk space: how to diagnose it and free space

If your VPS ran out of space, first measure with df and du what is using it, then delete only what regenerates itself: the apt and npm caches, system logs, old versions of tools and old builds. Never touch databases or backups. We know it first-hand: on October 23, 2026 our server's disk reached 99% and several websites were down for about 17 hours.

Updated 2026-11-10 · By Rómulo Felizola · Leer en español

Step 1: confirm it is the disk (and not the inodes)

df -h /
df -i /

df -h shows space and df -i shows inodes (the number of files). A server can be “full” with free space if the inodes run out, and the fix differs: millions of small files, usually caches or sessions.

Step 2: find what uses the space

du -xh / --max-depth=2 2>/dev/null | sort -h | tail -20
find / -xdev -type f -size +500M 2>/dev/null

The first command lists the biggest folders and the second the files over 500 MB. Go one level down each time until you find the culprit.

Step 3: delete what regenerates itself

apt-get clean
journalctl --vacuum-size=100M --vacuum-time=30d
npm cache clean --force
docker system df   # only if you use Docker

This is what we found on October 23, and about 23 GB were freed: the npm cache (about 8 GB), installers and old versions of the GitHub Actions runners (one copy per project, ten in all), old VS Code servers, old Playwright browsers, already-published original photos and old backups. The disk went from 99% to 52%.

The rule: delete only what you know gets generated again. If you doubt a folder, don't delete it: rename it, wait a day and check everything still works.

Step 4: so it doesn't happen again

  • A weekly cleanup script with a systemd timer. Ours runs on Sundays and sticks to what regenerates itself: apt cache, system logs, runner installers and old tool versions.
  • A check every 15 minutes that runs that cleanup if the disk passes 85%. It would have saved us the 17-hour outage.
  • Logs with a maximum size (journalctl --vacuum-size) and rotation of nginx logs.
  • Backups outside the server: a copy on the same disk uses the same space you want to free.

When it is time to change plan

If after cleaning what remains is your own data (databases, uploaded files, photos), it is not a cleaning problem but a size problem. Our disk was about 50 GB and, after cleaning, we moved to the KVM 2, which has 100 GB. According to Hostinger, existing plans are upgraded from the account with the “Upgrade” button. Before deciding, see which KVM plan to choose.

The plan we moved to (100 GB):KVM 2 VPS at Hostinger

Frequently asked questions

Is it safe to delete the files in /var/log?

Old logs yes, but don't delete the whole folder or files a service has open. Use journalctl --vacuum-size for the system and logrotate for nginx.

Why do my websites stop working when the disk fills?

Because applications and databases need to write (sessions, logs, temporary files). With no space, writes fail and they tend to crash; nginx may answer with 5xx errors. See also the nginx 502 error.

How much free space should I leave?

Our alarm triggers at 85%. With less than 15% free you have no room for a big build or an update.

Keep reading