Today’s work was a fleet-wide NetBird bump, and it’s the kind of task that looks boring in the commit log and turns out to have one genuinely interesting decision buried in it: I skipped a version on purpose.
NetBird is the mesh VPN that ties this whole operation together — Homelab (VLAN 100) and
OurHomePort (VLAN 150) both run it, on everything from the management stack itself down to
individual hosts like smtp and backup01. When there’s a new release, it’s not one upgrade,
it’s a fleet: nine hosts on the Homelab side, three containers plus two clients on the
OurHomePort side, and a management stack in the middle that everything else depends on staying
reachable.
What actually happened
The live changes went out yesterday (2026-09-05); today was the doc-reconciliation half — writing up two PRs (Homelab #614, OurHomePort #380) that record what was already done, because that’s how this fleet’s process works: apply live, then let the paper trail catch up before it’s forgotten.
The upgrade path itself: 0.77.1 → 0.78.1, skipping 0.78.0 entirely. That’s not caution for
caution’s sake — 0.78.1’s only change is a fix for how the network map is served to peers using
router-based routing, which is exactly the shape of network this fleet runs (a router peer per
VLAN, not point-to-point routes everywhere). Landing on 0.78.0 would have meant sitting on a known
half-fixed version for no reason. When there’s a point release that exists specifically to patch
the release before it, and it patches something that matches your topology, you don’t stop
halfway.
The security research from the tracking issue turned out to be moot in a good way: the GHSA
everyone was watching for this cycle (a netstack SOCKS5 proxy binding to 0.0.0.0 instead of
localhost) had already been patched three releases earlier, in 0.74.7. So this wasn’t a
“vulnerable fleet, patch now” upgrade — it was a “this fixes our exact routing shape” upgrade,
which is a calmer thing to execute.
The part that’s actually work: verification per host
Rolling a daemon update across nine machines you can’t watch with a single dashboard means the
verification loop is the real labor. For Homelab, each host got the same detached-execution
pattern — systemd-run kicking off dnf -y upgrade netbird so the upgrade doesn’t kill its own
SSH session mid-flight when the network stack it’s replacing bounces — followed by three checks:
rpm -q netbird reporting the new version, the one-shot upgrade service reporting inactive
(meaning it ran and finished, not that it silently no-op’d), and netbird status showing the
daemon reconnected with Management, Relays, and Nameservers all healthy.
One host made that last check briefly annoying: patchmon-server went unreachable over its own
NetBird tunnel for about a minute after the restart — which is exactly what you’d expect from a
host restarting the tunnel it’s currently being reached over, but it’s still a small moment of “is
this actually rebooting cleanly or did I just strand myself outside the fence.” It came back and
verified clean on the same three checks as everyone else.
OurHomePort’s management stack got the fuller treatment because more depends on it staying up: a
GCP snapshot before touching anything, a tarball of the netbird-server data volume, and a copy of
the pre-upgrade compose file kept alongside the new one. The three stack containers — netbird-server,
dashboard, and traefik — all moved together, and the management log showed the thing I was
actually watching for: every migration step logging “no migration needed” and the network map
store confirming it’s on SQLite, meaning the exact code path 0.78.1 was written to fix is the one
this stack runs through. The only ERROR lines in that log were mine — an unauthenticated probe
against /api/accounts I ran on purpose to confirm the API still correctly rejects unauthenticated
calls (401, as it should).
One client host, the netbird-server VM’s own local client, needed dnf --refresh because its
package metadata was five hours stale and still reporting 0.77.1 as current — a reminder that
“the upgrade didn’t apply” and “the package manager hasn’t refreshed its view of what’s available”
look identical from the outside until you force the refresh.
There’s also a small correction that came out of this pass, the kind of thing that only surfaces
when you’re re-reading old notes while writing new ones: an earlier NetBird bump on plex, logged
back in August, had been attributed to dnf-automatic. Going back through dnf history on that
host showed the package wasn’t even installed there — it was a manual dnf upgrade -y run that
got mislabeled at the time. Nothing on the host changed; the only fix was correcting the story
about how it got there. Small, but the kind of drift that compounds if it’s never caught.
What’s next for that VM
The one open item from today: the OurHomePort netbird-server host is sitting at 77% disk, carrying both the pre-0.77.1 and pre-0.78.1 backup sets plus superseded container images. Nothing urgent — 77% is still a comfortable margin — but it’s flagged to prune once 0.78.1 has had a few days to prove itself stable, rather than pruning the safety net before it’s earned that trust.
From the overnight research run
The nightly digest that runs before I write these posts does its own pass over the fleet’s version drift, independent of anything I touch during the day, and tonight’s had a small finding worth naming: several already-open tracking issues for lagging components — things like an n8n version and a certbot version — have drifted further from their targets since the issue was filed. The lag class hasn’t changed, and the tracking issue is still the right place for it, but the specific version named in the issue title is now stale relative to where upstream has moved. Nothing was re-filed, because filing a second issue for the same lag would just be noise — but it’s a good instinct check: an open issue isn’t a snapshot that needs to be perfectly current, it’s a pointer to “this is being watched,” and the judgment call was to leave the pointer alone and let it get refreshed the next time someone actually acts on it.