Running a cluster in theory sounds like the perfect solution. Redundancy, scalability, and resilience—those are the promises. But in practice, I’ve found that keeping a cluster alive while moving between places and networks is a whole different story.

I’ve had multiple situations where my nodes simply refused to come online. Sometimes it wasn’t a small fix, either—it required reimaging the SD card and restoring everything from scratch. Thankfully, I had backups of my blog software script (a Python app), which meant I could recover quickly. Still, it’s not exactly what you’d call smooth sailing.

The Theory vs. The Practice

On paper, a cluster gives you:

  • Physical redundancy – if one node fails, another can pick up the load.
  • Distributed resilience – workloads can shift as needed.
  • Data protection – synced backups ensure nothing gets lost.

But when you’re traveling with small SBCs, flaky storage, and spotty power or network conditions, those strengths are harder to realize. Instead of the cluster seamlessly self-healing, I often found myself spending more time recovering nodes than benefiting from the setup.

Power: The Hidden Challenge

Another wrinkle I ran into was the power supply situation. Each node in the cluster was powered either by a battery pack or a USB-C wall supply. What I learned quickly is that many of these devices will drop power to one of the USB-C ports whenever another cable is plugged in. That meant nodes would unexpectedly lose power during setup if I didn’t get the sequence right.

I ended up developing a sort of “order of operations” for plugging in and powering up the cluster. Once I stuck to that sequence, I could bring the nodes online reliably.

In testing different battery packs, I found that the Ugreen battery pack performed better than the Inui ones. The Ugreen handled multiple USB-C connections more gracefully, whereas the Inui packs were more prone to cutting power when juggling ports. That small difference made a big impact on cluster stability.

Ironically, the thing I thought would be the hardest part turned out to be a non-issue: networking. Running Tailscale over Starlink just worked.

  • Ping times were stable and surprisingly good.
  • Latency was in the 20–30 ms range, which is more than acceptable for remote access.

So while the cluster itself had physical stability issues, connectivity via Starlink was rock solid. It gave me reliable access without the headaches I was expecting.

What the Cluster Still Gave Me

Despite the frustrations, there was value:

  • Redundant copies of the blog – my website content was always being synced across nodes.
  • Any-node availability – I could spin up the blog site from whichever node was working at the time.
  • Practical lessons – perhaps the biggest win, I’ve learned where clusters shine… and where they stumble when pushed outside of stable data center environments.

So while the cluster was more fragile than I hoped, it still delivered on one of its most important promises: keeping my blog safe and portable, even when individual nodes weren’t cooperating.