Routine maintenance

Running your own server means a set of recurring chores that a managed platform would have absorbed. None of them are difficult, but they do not happen unless someone does them, and ignoring them is how a working system slowly stops working.

This page describes what to expect, what is already automated, and what needs judgement.

Notifications you will receive

Coolify sends alerts to the configured channel. The ones that recur:

Server patches available. A count of Ubuntu packages with newer versions, with a note about how many "may require restarts". This arrives regularly and is normal. What to do with it is the subject of most of this page.

High disk usage. Sent when the disk crosses a threshold. This has fired here before, at 83 percent, caused by accumulated Docker images and build caches rather than by real data. See Disk space.

Coolify update available. Shown as a badge in the interface rather than as an alert.

A notification is not an incident. Every one of these is routine, and the correct response is usually "schedule it", not "act now". Treating each one as urgent leads to patching a production server at midnight for no reason, which is itself a risk.

Security updates are already automatic

unattended-upgrades is installed and enabled, which means Ubuntu security patches are applied on their own without anyone intervening.

The practical consequence is that a long list of pending updates is usually not a security backlog. At the last check there were 28 pending packages and zero of them were security updates, precisely because the security ones had already been applied automatically.

So before reacting to a patch notification, find out what is actually in it:

apt list --upgradable 2>/dev/null | grep -i security

Empty output means nothing is waiting that affects security, and the rest can be done whenever it is convenient.

Updates that restart everything

Most package updates are harmless. Two categories are not, and they are worth recognising in a list before running an upgrade.

Docker and containerd. Upgrading docker-ce, docker-ce-cli, or containerd.io restarts the container runtime, which restarts every container on the server: the application, the entire Supabase stack, and Coolify itself. Expect a short outage, and expect the Supabase stack to take a couple of minutes to settle, because several of its services wait on each other during startup.

The kernel. A linux-image update does nothing until the machine reboots, and the reboot is the outage.

To check whether a reboot is pending:

[ -f /var/run/reboot-required ] && cat /var/run/reboot-required.pkgs

Neither category is dangerous in normal circumstances. The point is to do them deliberately, at a quiet hour, rather than discovering mid-afternoon that the site went away for two minutes.

Do backups first

There is a specific ordering problem worth stating plainly: there are currently no backups of the database, and upgrading the container runtime is exactly the kind of operation that occasionally does not come back cleanly.

The risk is small. The consequence, on a single server with no restore path, is total.

Until backups exist, prefer to defer runtime upgrades that are not fixing a security problem. Once they exist, this page's advice becomes simply "do it at a quiet time".

Applying updates

Coolify offers a patch interface, which is convenient and fine for ordinary packages. The equivalent on the command line, which shows you exactly what will happen:

apt update
apt list --upgradable          # read this before continuing
apt upgrade                    # will name anything being removed; read that too

Watch for anything in the output about removing packages. An upgrade that wants to remove something should be understood before it is accepted, not confirmed reflexively.

Coolify itself

Coolify updates independently of the operating system, through its own interface.

Read the release notes before a major version. Coolify manages every deployment on this server, so a regression in it affects everything at once, and there is no second environment on which to try it first. There is rarely a reason to update within hours of a release; waiting a week costs nothing and lets other people find the problems.

Disk space

The disk fills through normal use. Every deployment produces an image, and old images and build caches are not removed automatically unless configured.

To see the situation:

df -h /
docker system df

To reclaim space:

docker image prune -a -f       # images not used by a running container
docker builder prune -f        # build cache
journalctl --vacuum-size=100M  # systemd logs

The first command is safe but will force the next deployment to rebuild from scratch rather than from cache, so the next build takes longer.

Better than doing this by hand: enable Coolify's automated Docker cleanup, so it happens on a schedule instead of after an alert.

What is already handled

Worth knowing so you do not go looking for work that does not exist.

TLS certificates renew automatically. Traefik requests and renews them from Let's Encrypt, well before the ninety-day expiry. A certificate problem is almost always a DNS or routing problem rather than a renewal failure.

Security patches are applied automatically, as described above.

Container restarts after a server reboot are handled by Docker's restart policies; the stack comes back on its own.

A reasonable cadence

There is no need to be systematic about this, but roughly:

Task	How often
Read patch notifications, check whether any are security	As they arrive
Apply ordinary package updates	Monthly, or when convenient
Apply Docker or kernel updates, reboot if needed	Deliberately, at a quiet hour, after backups exist
Update Coolify	A week or two after a release
Check disk usage	Monthly, or when alerted
Verify a backup restores	Once backups exist, periodically