v0.0.22 — mixed-architecture clusters and Buddy updates itself

Released 2026-07-27.

Highlights

• A Buddy cluster can now mix processor types. A spare x86-64 machine can join a Raspberry Pi cluster as a worker, or be set up as the master itself with Pi boards as its workers — useful because an x86-64 machine can carry far more memory than the 2 GB minimum a Pi board holds as master. Buddy serves each node the management software built for its own processor automatically, and if it can’t yet build for a node’s processor at all, adding that node is refused up front, with a plain message naming what it needs, instead of a stuck, half-added node.
• An app with no version for its node’s processor now says so, in words. If an app’s container image was only published for one processor type and it lands on a machine of another, the panel now shows a plain sentence naming the mismatch instead of leaving the app looking stuck with no explanation. The full technical detail behind it stays available if you need it, one click away.
• Buddy can now tell you when a newer version of its own software exists, and install it for you. The Dashboard checks once a day for a new release — fully optional, and off until you turn it on — and, when it finds one, offers Update now. Confirm, and the master downloads the new version, checks it thoroughly, installs it and restarts onto it; your nodes and whatever they’re running keep working the whole time. Before an update ever changes its database, Buddy backs it up first, and a version of Buddy older than its own database now refuses to start rather than risk writing to a database it doesn’t understand.
• The panel’s icons were redrawn wholesale for a more consistent look. This is a visual change only — nothing about where things are or how they work moved.

Known limitations

• None of the mixed-processor-type claims above have run on a real mixed cluster yet. Every machine used to test this release has been a Raspberry Pi; there is no x86-64 machine, joined as a worker or set up as the master, that Buddy has actually run against. This is covered thoroughly by automated tests, but treat mixing processor types as unproven on real hardware until that run happens.
• The “no version for your processor” message hasn’t been triggered by a real mismatched install either, for the same reason — it takes an actual mixed cluster to test against. Its wording is built from what container tooling itself documents for this exact failure, not from watching one happen on a live cluster.
• Checking for, and installing, a newer version of the master’s own software has not been run once, on any machine — including the automatic recovery step if an install doesn’t come back up cleanly. Right now, checking for updates will only ever report “Couldn’t check for updates,” because nothing has actually been published yet for it to find. Until an update has been run end-to-end, treat Update now as unproven and update the master by hand instead — see Keep the cluster’s software up to date.
• The pre-update database backup itself is confirmed on real hardware — restoring it afterward is not. A live deploy of this release did back up the database before its own upgrade ran, and skipped the backup on an ordinary restart with nothing pending, exactly as designed. Actually restoring that backup, and the master coming back up on its older software from it, hasn’t been performed on any machine yet.