Explained
Your disk is filling up — and you haven't uploaded anything
Real server problems, translated into plain English by Onserva.
What you're seeing
Disk usage at 80%, then 90%, and you can't think of a single thing you've added. Or you found out the hard way: a deploy failed with no space left on device, or a database refused to write, on a machine that supposedly had tens of gigabytes free last month. When Docker disk space is full, this is usually how it announces itself.
What it actually means
Almost nothing you did filled the disk. The machine filled it itself, as a by-product of doing its job. Servers that run containers accumulate four common kinds of clutter:
Old images
Every deploy builds a fresh copy of your app, and old image layers can be left behind afterwards. On a busy Coolify box this is often the single biggest consumer of space.
Build cache
To make deploys fast, the machine keeps intermediate pieces of builds. Useful, but it can grow steadily if it is never pruned.
Logs
Every line every app prints is written to disk. One chatty app — or one stuck printing the same error in a loop — can produce gigabytes in a week. Those logs are useful evidence, so fix the cause before clearing them.
Backups and databases
This is the category that is genuinely yours. Databases grow with your data, and backup schedules quietly stack up copies. Do not treat either as disposable clutter.
What to do right now
- Confirm how bad it is:
df -h— look at the Use% on your main filesystem. - See how much is container clutter:
docker system df— this splits usage into images, containers, volumes and build cache. - Reclaim the safest Docker clutter:
docker image prune— this removes only dangling image layers: unnamed leftovers that no container uses. It does not touch named images, containers or volumes. - If logs are the culprit, find the offender:
sudo du -sh /var/lib/docker/containers/*/ | sort -h— the largest entries are your chattiest containers. Fix the app that's screaming, then set log rotation so it cannot happen again.
When to worry
A disk at 70% growing 1% a month is fine. A disk that gained 10% in a week has something actively wrong — usually a log loop or a runaway backup schedule — and will hit the wall far sooner than the percentage suggests. And a full disk is an emergency even if the sites still look up: databases may be unable to write cleanly, services can crash, and recovery is a much worse day than a failed deploy.
How Onserva handles this
Onserva does not just show disk 85%. It watches the trend and tells you how long you have at the current rate, so a steadily filling disk becomes a warning weeks before a deploy fails. It does not pretend that one aggregate disk reading identifies the directory responsible — that still needs the checks above.
Its one-button disk clean-up is deliberately narrower than a broad Docker prune: only a small, compiled-in set of machine-rebuildable clutter is ever eligible, and every action states exactly what it will do before you authorise it. Backups, databases, volumes and your application files are never targets.