Self-Hosting / Automation

Auto-Updating Self-Hosted Apps: the Gap unattended-upgrades Leaves

Unattended OS-level security updates feel like they cover "keeping things patched" as a category. They do not cover the self-hosted applications running on top of that OS. One of those apps falling a single version behind silently broke a client I use every day, with no warning from anything monitoring the server itself.

What actually happened

A self-hosted password manager's browser extensions stopped populating vault data one day. Firefox and Chrome both. No error dialog, just an empty-feeling extension. The web vault and mobile app on the same account kept working perfectly. Those browser extensions auto-update through their browser stores, entirely outside my control. They had moved to a client version requiring a newer minimum server version than the one running. The release that closed that gap had shipped the day before the extensions updated. The self-hosted server was exactly one version behind. Nothing had ever updated it, because nothing was watching for that.

The gap this exposed

BE WARNED: unattended OS-level security updates and self-hosted application updates are two separate categories. Solving one implies nothing about the other. Every container's underlying Linux packages were covered by a real, working unattended-upgrades policy. Not one of the self-hosted applications running inside those containers had any update automation at all. That is the software people used every day. It only ever got updated by hand, on no particular schedule. Which is exactly the condition that lets a compatibility-breaking version gap go unnoticed until a client somewhere silently breaks.

This is easy to miss because "we have automated patching" sounds like a solved problem. Ask whether that coverage means the OS, the applications, or both. The answer is usually "just the OS", and nobody decided that on purpose.

The fix: backup-gated auto-updates, staggered, per service

Skip the generic "auto-update everything" cron job. This is the pattern that has held up:

A real backup immediately before every update attempt. Not a substitute for testing. A guaranteed rollback path if the update itself introduces a regression. That is the risk you are trading for closing the staleness gap, so trade it knowingly.
One systemd service and timer pair per application, each running its own update-then-verify script. Not one big script trying to handle every app's different update mechanism.
Staggered timers across the early-morning hours instead of everything firing at once. That spreads the backup storage load. More importantly it limits the blast radius when one update goes wrong. You debug one service's timer window, not six simultaneous updates that happened to run in the same few minutes.

Worth deciding explicitly, not by default

Once this exists for one application, list every other self-hosted app you run and decide one by one whether it belongs in the same automation. Do not assume "we have auto-updates now" covers anything beyond whatever triggered building it. The whole point of this gap is that it is invisible until something breaks. Closing it for one app does not close it for the others sitting right next to it, running the same unwatched, hand-updated or never-updated software stack.