Patching a Homelab Without Babysitting It

A homelab has one enemy that isn’t hackers or hardware failure: boredom. Patching a single server is easy. Patching the host plus a dozen containers, each with its own package manager, every week, is exactly the kind of chore that quietly stops happening.

So I stopped relying on discipline and wrote a tool instead.

The problem

My lab is one Proxmox VE node running each service in its own LXC container. That isolation is great until patch day:

• The host and every container need updating separately.
• Not every container runs the same distro, so apt, apk and dnf all show up.
• Some containers are stopped most of the time, and a stopped container never gets patched.
• Some things need a reboot afterwards, and I don’t want a script rebooting my host at 3 a.m.

What the updater does

Proxmox Updater runs on the host and works through everything it finds:

• Scans the host and every LXC container for available package updates.
• Detects the distro inside each container and uses the right tool: apt for Debian and Ubuntu, apk for Alpine, dnf or yum for Rocky, Alma and CentOS.
• Starts stopped containers, updates them, and stops them again, so nothing falls behind just because it was off.
• Linux VMs are opt-in through the guest agent.
• Knows its limits. Windows VMs and Docker containers are detected and skipped, because they have their own update paths (Windows Update, or a Watchtower-style tool for images).

Report first, apply on purpose

The most important design decision was the default. Out of the box it only reports. It checks everything and emails me a summary over SMTP, with no mail server needed on the host.

Installing happens only when I ask for it, with --apply. That split does two things:

1. I always know what’s pending, even on weeks I don’t act on it.
2. Nothing changes on my infrastructure without a deliberate decision.

Never reboot on its own

Some updates need a restart. The updater doesn’t do it. Instead, the report says “reboot needed” and names what’s waiting.

An automatic reboot is the kind of convenience that turns into an outage, with a VM mid-write or a service that doesn’t come back cleanly. Surfacing the need and letting a human pick the moment is safer, and it costs me one click.

Write every change down

The project keeps a changelog where every entry answers the same four questions:

• Changed: what was edited, with file paths.
• Deployed: what landed where, or “not deployed”.
• Why: the reason, especially anything non-obvious.
• Rollback: how to undo it.

It feels like overkill for a homelab until the first time you need to know what you changed three weeks ago and how to get back.

What I’d tell you

• Automate the reminder before you automate the action. A report you actually read beats a silent auto-updater you don’t trust.
• Make the dangerous step explicit. --apply is a flag, not a default.
• Let humans own reboots. Report the need; don’t act on it.
• Handle the boring edge cases. Stopped containers and mixed distros are where patching quietly fails.

The same thinking carries straight into production work: visibility first, deliberate changes, and a written way back.