Requirements and supported hardware
This is the fuller technical reference. If you just want the pre-flight checklist before you buy anything, see What you need instead. The two don’t disagree, this page just goes a level deeper.
Machines
| Item | Minimum | Recommended |
|---|---|---|
| Master | 4-core ARM64 (or equivalent x86-64) board, 2 GB RAM | Same, with 4 GB RAM for more headroom |
| Workers | at least 2, matching the master’s processor family | Same |
| Power | a quality, official-spec power supply per machine | — |
The 2 GB minimum for the master is a measured figure, not a guess: a configured master idles at roughly 1 GB of memory before any of your own applications run, so a machine with 1 GB can’t hold it. A board with around 1 GB of memory can still work as a worker — just not as the master — but it isn’t recommended even there, since it leaves little room for your own applications.
Mixing architectures
A cluster’s machines don’t have to share one processor family Sincev0.0.22. Two shapes this is for:
- An x86-64 master, to raise the memory ceiling above the 2 GB minimum above — a Pi board barely holds the idle control plane; a spare x86-64 box has more headroom to spare.
- A spare x86-64 (or ARM64) machine as a worker, joining a cluster whose master is the other architecture, to add capacity without matching hardware.
Buddy serves each node the management software built for that node’s own processor automatically; adding a node whose processor type the master doesn’t have a build for is refused up front, with a message naming which one it needs.
Mixing architectures doesn’t mean every app you install runs on every node: a package pins a specific container image, which may only be built for one processor type. Buddy doesn’t check this for you in advance; if an app fails to start on a node, check whether its publisher builds it for that node’s processor type, and if not, run it on a node whose processor type they do support.
Boot media and storage
- Each machine needs its own boot storage: a memory card (Class 10, A1 or better, 16 GB or larger), a higher-endurance card, or a boot-capable SSD.
- Put the data your applications keep on a separate disk attached to a node, not the boot media: an SSD is strongly preferred over a spinning disk for endurance and speed.
- That disk’s data lives on the one node it’s physically attached to; there’s no automatic copy to another disk. See What you need for what that means day to day.
Network
- One local network. Every machine — master and workers — needs to be on the same local network, connected by wired Ethernet.
- Only the master needs to be reachable directly. You open the web panel at the master’s own address; workers talk to the master and each other over an encrypted connection the cluster sets up for itself.
- SSH, briefly. Each worker needs SSH reachable for the one-time step of adding it to the cluster; the credentials used for that are never stored and play no further part afterward.
- The ports the master listens on, useful to know if your network has a firewall between machines: the web panel and node enrollment on 8443; a secure channel the master and each node use to talk to each other on 9443 (reachable only from the cluster’s own private network, never from the Internet); and the cluster’s own private network on 51820.
- A gigabit switch and fixed (static) addresses for your machines are recommended, though not required.
Operating system
Every machine — master and workers alike — runs the same Ubuntu Server LTS release (ARM64, or x86-64 to match whichever architecture you chose above). The master can be set up two ways: flashing a ready-made image, or running the installer on an existing Ubuntu Server install. See Install the master. Workers get a plain, unmodified install; everything else about joining them happens from the panel.