A homelab patch cadence that holds
Patch on a schedule, in one monthly window, layer by layer, with a snapshot before every layer and the rollback method known in advance. Keep a separate same-day fast path for an actively-exploited CVE on something exposed — compressed steps, never skipped ones.
"Update everything on a Sunday" is how most homelab outages start. Not because updates are bad, but because they happen without a snapshot, without a rollback plan, and without a sense of what actually needs a reboot. The fix is not more caution. It is a cadence, so the decision of when is made once, in advance, and the only decision left in the moment is whether tonight's symptom is worth rolling back for.
Three classes of update
Everything you will ever apply falls into one of three buckets, and the bucket decides the handling:
| Class | Definition | Handling |
|---|---|---|
| Routine | Regular OS, package and container-image updates, no known active exploit | Monthly window, batched |
| Notable | Major version bump, breaking changes in the release notes, or a service other things depend on | Scheduled separately, tested on one host or service first where possible |
| Emergency | Actively-exploited CVE affecting something exposed or public-facing | Same day, skip the normal window, never skip the snapshot |
Most of what arrives is routine. The value of naming the classes is that it stops routine work from being treated as urgent, and stops genuinely urgent work from waiting three weeks for a window.
Cadence by layer
A homelab is not one system, and one cadence for all of it is either reckless at the bottom or paralysed at the top. Firmware and network gear move on a different clock from containers, and they have different rollback stories:
| Layer | Cadence | Reboot? | Rollback method |
|---|---|---|---|
| Hypervisor host OS | Monthly, or emergency for kernel and security CVEs | Usually, for kernel updates | Boot the previous kernel entry, or restore host config from backup |
| Guest operating systems | Monthly | Sometimes | VM snapshot taken pre-update |
| Containers and images | As new images ship, batched monthly unless CVE-driven | No — recreate the container | Pin the previous image tag and redeploy |
| NAS operating system | The vendor's stable cadence, not every point release on day one | Yes | Boot-environment rollback, or documented config restore |
| Firmware and BIOS | Only when a specific bug or CVE applies | Yes | Usually none — which is exactly why the "only when needed" rule exists |
| Network gear firmware | Quarterly, or CVE-driven | Yes | Vendor rollback if supported, otherwise config backup and reflash |
The reboot column is worth reading before the window rather than during it. It is what tells you whether tonight is twenty minutes or two hours, and whether anything else in the house loses its network while you do it.
Before you touch anything
- A fresh backup or snapshot exists for everything you are about to update. For most layers this is the rollback plan, not a precaution alongside it.
- Release notes read for breaking changes, not just "update available".
- Dependency map checked for what else relies on the thing you are updating.
- The window is actually blocked out on the calendar. Even working alone, book the time, so you are not rushing a rollback decision at the end of an evening you needed for something else.
- For notable and emergency work: a fallback access path confirmed, in case the update breaks the thing you would use to fix it remotely.
That last one catches people exactly once. Updating the router firmware over the connection the router provides is survivable right up until it is not.
The window itself, in six steps
- Snapshot or back up first. A ZFS or LVM snapshot, a VM snapshot, or a fresh backup run — whichever matches the layer. No update proceeds without this step.
- Test on one instance. If you run several containers from the same image or several VMs in the same role, patch one, verify it, then do the rest.
- Apply the update.
- Verify. The service starts, the logs are clean, and a functional check passes — actually use the thing, rather than confirming a process exists. If the service is monitored, cross-check the monitoring agrees.
- Document. One row in the patch log and one in the change log. The connection between "what changed" and "what broke three days later" only exists if both were written down.
- Hold the snapshot for a defined window — seven days is a reasonable default — before pruning it. Some breakage does not show up on day one.
Step 6 is the one that gets dropped, and it is the one that turns a rollback plan into a rollback you can actually perform on the Thursday when the problem surfaces.
Rollback or fix forward
Decide this against a table you wrote calmly, not against how tired you are:
| Symptom after the update | Decision |
|---|---|
| Service will not start, the error is unclear | Roll back now, investigate the failed update offline |
| Service starts but a known feature is broken | Fix forward if a quick config fix is known; roll back if it is not resolved within fifteen minutes |
| Everything looks fine but you are not confident | Do not roll back pre-emptively. Watch it for the snapshot retention window, then prune |
| An emergency patch caused a new but lesser problem | Fix forward — the exploit you patched is worse than the regression, unless the regression is also a security issue |
Whichever way it goes, log the decision and the reason. "Rolled back, cause unknown, retry next month" is a perfectly good entry; "we had a problem in October" three months later is not.
When a CVE lands: the fast path
An actively-exploited CVE for something in your stack does not wait for the monthly window. It also does not justify skipping steps — an emergency patch is exactly the kind that sometimes breaks things, so you need the same safety net, not less of it because you are in a hurry.
- Confirm exposure first. Is the affected thing public-facing, or reachable from an untrusted segment? If it is not exposed, you still patch soon, but it is not a same-day fire drill, and treating every CVE as one is how the fast path stops meaning anything.
- Snapshot anyway. Same step, same requirement, compressed timeline.
- Patch, verify, document — the same six steps, run faster, none of them removed.
- Log it as emergency class, with the CVE ID. So a later review can see the difference between planned and reactive work, and how much of the year went to each.
The exposure question in step 1 is only answerable in seconds if you already have an inventory with a "public-facing" column. If you do not, that is the thing to build before the next CVE, not during it — it is the inventory chapter, published free.
Keep a patch log
Four columns are enough: date, layer, system, class. Beside it, four more: date, snapshot taken, result, rolled back. That is the entire record, it takes a minute per window, and it earns its keep the first time something behaves strangely and you can answer "what changed on this box recently?" without guessing.
Over a year the log also tells you something the individual rows cannot: which layer generates your breakage, how often emergency work actually interrupts you, and whether the cadence you picked is the cadence you are keeping. If the monthly window has not happened since spring, the finding is not that you need a better checklist. It is that the window needs to be shorter and on the calendar.
The full patching runbook — classification, the cadence table, the pre-flight checklist, the rollback decision table, the patch log and copy-paste window plan and rollback decision templates — is Chapter 5 of The Homelab Ops Handbook ($29 minimum / $39 suggested). The patching section of the free 96-item Homelab Ops Checklist has the short version. Free updates forever. 30-day 100% refund, no questions.