Homelab Patching Without the Pain

Most homelab setups break in one of two ways: hardware fails, or software rots. The second one is slower and quieter — a package left unpatched for six months, a container image with a known CVE still running because “it works, I’ll update it later.”

My setup spans a three-node Proxmox cluster, a Talos Kubernetes cluster, a Synology NAS, pfSense, and Docker services on Oracle Cloud. Everything on a different release cadence, everything with a different failure mode if ignored. This is the system I use to stay on top of it without it becoming a second job.

The Checklist

The foundation is a checklist in Joplin — a self-hosted note app I’ll cover separately. It resets monthly and covers every layer that needs human attention. The point isn’t complexity — it’s that the checklist forces a decision. You either check it off or you consciously skip it.

The split between automated and manual is intentional. Automation handles what’s low-risk and high-frequency. Manual attention goes to the layers where a bad update can take down the whole environment.

Network

pfSense CE

pfSense Community Edition moves slowly. Major releases are infrequent, and Netgate increasingly nudges CE users toward pfSense Plus — but the CE branch is still maintained for security patches.

The standard update path (System → Update) covers full version upgrades. For between-version patches, the System Patches package adds a second layer: it pulls individual patches directly from the pfSense source repository and applies them without a full upgrade cycle.

To install it: System → Package Manager → Available Packages → search "System Patches".

Once installed, System → Patches shows any recommended patches for your running version. Most months the list is empty. When there is something, it’s typically a targeted fix — applied in under two minutes, no reboot required.

TP-Link WiFi

Firmware for the AX3000 ships infrequently — a few times a year at most. Monthly check via the admin interface is more than enough. The update applies in under two minutes with a brief disconnection; all connected clients reconnect automatically.

Hypervisors — Proxmox Cluster

This is the part most homelab guides skip: how do you update a multi-node Proxmox cluster without taking everything offline?

My cluster is three nodes: Beelink GTi 13 (px-0, i9-13900H, 64GB DDR5), and two Dell OptiPlex 6500T units (px-1, px-2, each 32GB DDR4). Full specs in The Rack. Each node runs one Talos VM for Kubernetes, so losing a node during an update means losing a K8s control plane node — not catastrophic with three nodes, but still worth doing cleanly.

The Rolling Upgrade

The rule: update one node at a time, verify it’s back healthy before touching the next. Kernel updates require a reboot, and on a cluster node, that reboot needs to be planned.

Step 1 — Check cluster health before touching anything:

pvecm status

All nodes should show as online. If any node is already degraded, fix that first. Never start a rolling upgrade on an already-unhealthy cluster.

Step 2 — Migrate VMs off the node you’re about to update:

From the Proxmox web UI, or via CLI:

qm migrate <vmid> <target-node> --online 1

The --online 1 flag enables live migration — the VM keeps running during the move. For px-0 (Beelink), I migrate the Talos controlplane VM to px-1 before upgrading.

Step 3 — Run the upgrade:

apt update && apt dist-upgrade -y

dist-upgrade instead of upgrade matters here. upgrade won’t install new packages or remove obsolete ones — on Proxmox, kernel updates and pve package replacements require dist-upgrade to resolve correctly.

Step 4 — Reboot and verify:

reboot

After it comes back:

pvecm status          # cluster membership restored
uname -r              # confirm new kernel is running
pveversion            # Proxmox version consistent across nodes

Step 5 — Migrate VMs back, move to the next node.

Why Update px-0 First

px-0 (Beelink) is the highest-spec node — 64GB DDR5, i9-13900H. The Talos VMs temporarily land on px-1 and px-2 during the Beelink upgrade. Both OptiPlexes together have 64GB combined — enough to absorb the load short-term. Once px-0 is back online and clean, the VMs migrate back to it, and the OptiPlexes update one at a time with nothing critical running on them.

Dell R720

The R720 is nearly decommissioned — boots occasionally for benchmarking or one-off experiments. The rule is simple: boot → update → do the work → shut down. Never leave it running on a stale package tree.

apt update && apt dist-upgrade -y

Storage — Synology DS223+

Synology DSM has two auto-update modes worth understanding:

• Automatically install important updates — security patches and critical stability fixes only. Doesn’t touch major version upgrades or optional package updates.
• Automatically install the latest updates — everything, including feature releases that can change behavior or require service restarts.

I use the first option. It runs on a schedule (Friday 02:30) so the NAS is never mid-update during active use.

Major DSM version upgrades I handle manually after reading the release notes. These occasionally change NFS/SMB behavior or package compatibility — worth a few minutes of reading before applying.

The biweekly manual check isn’t for applying updates — it’s to verify the automated jobs ran successfully. DSM logs every update under Control Panel → Update & Restore → Update History. One glance confirms nothing silently failed.

VMs — Talos Kubernetes with Renovate

The three Talos VMs are the only layer I don’t touch manually at all. This is where automation actually pays off.

Renovate Bot monitors the infrastructure repo — github.com/meroxdotdev/infrastructure — and opens pull requests whenever it finds an updated version of anything: container images, Helm charts, Flux components, GitHub Actions, Talos OS itself, Kubernetes version.

Config That Makes It Work for Homelab

A few settings that matter:

1
"schedule": ["every weekend"],
2
":disableRateLimiting",
3
":automergeBranch",
4
"minimumReleaseAge": "3 days"

schedule: every weekend — all PRs batch into a single weekend session instead of trickling in daily. One review cycle per week, not twenty.

disableRateLimiting — Renovate’s default rate limits cap the number of PRs it opens at once. For a homelab with many dependencies, this means some updates silently queue for weeks. Disabling it means everything surfaces at once on the weekend.

automergeBranch — minor and patch updates merge automatically without a manual PR approval, as long as CI passes. You only review major version bumps.

minimumReleaseAge: 3 days — nothing automerges the day it’s published. This catches the occasional bad release that gets yanked within 48 hours (happens more often than you’d expect with container images).

What Gets Automerged vs Manual Review

1
{
2
  "matchUpdateTypes": ["minor", "patch"],
3
  "automerge": true,
4
  "automergeType": "branch",
5
  "ignoreTests": true
6
}

Minor and patch updates across GitHub Actions and mise tools automerge. Container images and Helm charts get a PR — I review them on the weekend and merge manually. Major version bumps are always manual.

Custom Annotations for Non-Standard Versioning

Some tools don’t publish to a registry Renovate understands natively. A regex annotation in the manifest file extends coverage:

1
# renovate: datasource=github-releases depName=k3s-io/k3s
2
k3s_release_version: &version v1.29.0+k3s1

Renovate picks up the comment, resolves the version against GitHub Releases, and opens a PR when a new tag appears. Works for any .yaml, .env, or .sh file in the repo.

The weekly merge session for K8s takes about 10 minutes: scan the Renovate dashboard issue, check any major version PRs for breaking changes, merge. Everything else Renovate handled while I wasn’t looking.

Cloud — Oracle Free Tier

The Oracle instance runs Ubuntu 24.04 on an Ampere A1 (4 vCPU, 24GB RAM — the free tier). All Docker services run through Portainer.

Container Image Updates

Portainer detects outdated images automatically — when a container’s image has a newer digest available upstream, it shows a marker in the container list.

The update flow: pull the new image → recreate the container. In Portainer’s UI: container detail → Recreate → enable “Re-pull image”. All volume mounts and environment variables carry over from the existing container config — no need to re-enter anything.

Host OS

apt update && apt upgrade -y
apt autoremove -y

Twice a month, same as the Proxmox nodes. The Oracle instance doesn’t run a kernel as actively patched as a local server would get, but it’s internet-facing — Traefik and Pi-hole sit on it. Staying current matters more here, not less.

What to Automate vs What to Touch Manually

The pattern across all of this:

Automate when: the update is low-risk, high-frequency, and the failure mode is contained. Synology security patches, K8s image bumps — these are safe to automate because they’re scoped, reversible, and the blast radius is a single service.

Stay manual when: the update touches the infrastructure layer itself — Proxmox host OS, pfSense, major DSM versions, K8s major upgrades. These can take down multiple services at once and benefit from a human checking cluster health before and after.

The checklist isn’t overhead — it’s the audit trail. It turns “I think I updated everything recently” into “I know I updated everything on these dates.”

Full infrastructure: The Rack — Homelab 2026. Kubernetes GitOps setup: github.com/meroxdotdev/infrastructure.