Self-Hosting with Home Assistant: How to Achieve 99.99 % Uptime on a Raspberry Pi Cluster

<p>Four nines of uptime — 99.99 % — sounds like marketing until you convert it into hours. Over a full year it allows roughly 52 minutes of downtime; over a month, about four and a half minutes. That is the budget you are spending every time an SD card corrupts, an update hangs, or the single Raspberry Pi running your lights and door locks needs a reboot. A single-node Home Assistant install cannot hit that target, because it has one of everything. A small cluster can get close, and the techniques it uses are borrowed almost directly from how data centres have kept services alive for the past two decades.</p> <h2 id="what-home-assistant-actually-is">What Home Assistant actually is</h2><div class="ad-unit ad-in-article" aria-label="Advertisement"> <span class="ad-label">Advertisement</span> <ins class="adsbygoogle" style="display:block;text-align:center" data-ad-client="ca-pub-3726833845844946" data-ad-slot="3291553914" data-ad-format="auto" data-full-width-responsive="true"></ins> <script>(adsbygoogle = window.adsbygoogle || []).push({});</script> </div> <p>Home Assistant is an open-source home-automation platform, first released in 2013 by the Dutch developer Paulus Schoutsen. It runs locally, integrates with thousands of devices and services, and — crucially for the self-hoster — keeps working when the internet does not. That local-first design is the whole appeal: your automations do not depend on a vendor&rsquo;s cloud staying online, and your data does not leave the house.</p> <p>The trade-off is that you now own the reliability problem. When your smart home lived in someone else&rsquo;s cloud, uptime was their concern. Run it yourself and a dead SD card at 2 a.m. is your concern, which is exactly the tension explored in <a href="/story/cloud-computing-a-symphony-of-someone-elses-silicon/">Cloud Computing: A Symphony of Someone Else&rsquo;s Silicon</a> — control and privacy on one side, operational burden on the other.</p> <h2 id="why-one-pi-is-not-enough">Why one Pi is not enough</h2> <p>The Raspberry Pi is a superb little computer, but two of its defaults work against long-term reliability. The first is the microSD card, which wears out under the constant small writes a database-backed application generates and tends to fail without warning. The second is that a single board is, by definition, a single point of failure: when it reboots for an update or dies from a power spike, your automation stops.</p> <p>High availability is the discipline of removing single points of failure one at a time. You cannot eliminate all of them on a home budget — you will likely still have one switch and one internet connection — but you can remove the ones that fail most often, which are storage and the compute node itself.</p> <h2 id="building-the-cluster">Building the cluster</h2><div class="ad-unit ad-in-article" aria-label="Advertisement"> <span class="ad-label">Advertisement</span> <ins class="adsbygoogle" style="display:block;text-align:center" data-ad-client="ca-pub-3726833845844946" data-ad-slot="3291553914" data-ad-format="auto" data-full-width-responsive="true"></ins> <script>(adsbygoogle = window.adsbygoogle || []).push({});</script> </div> <p>Start with three identical Raspberry Pi boards, ideally the Pi 4 or Pi 5 with 4 GB of RAM or more. Three is the smallest useful number for a highly available system, because clustering software uses a quorum — a majority vote — to decide which node is in charge, and a majority of three survives the loss of one node without ambiguity. Two nodes cannot form a majority when one disappears.</p> <p>Flash each board with a 64-bit Linux distribution and run Home Assistant in a container using Docker or Podman. Give each node a stable hostname and a static address so your integrations and dashboards have endpoints that do not move. Connect the boards through a gigabit switch and, importantly, power the whole cluster and the switch from a single uninterruptible power supply. A UPS turns a brief power cut — the most common cause of home-lab downtime — from an outage into a non-event.</p> <h2 id="shared-state-and-a-single-front-door">Shared state and a single front door</h2> <p>A cluster is only useful if any node can take over the work, and that requires the nodes to share state. Put the Home Assistant configuration, the database and the backups on shared storage — an NFS export from a small NAS, or a distributed filesystem if you want to avoid the NAS itself becoming a single point of failure. When a node fails, its replacement reads the same configuration and picks up where the last one left off.</p> <p>In front of the cluster you want one address that never changes, regardless of which node is actually serving requests. A reverse proxy such as Nginx Proxy Manager or Traefik, bound to a floating virtual IP, gives your phones and tablets a single door to knock on. Behind that door, the proxy quietly routes traffic to whichever node is currently healthy.</p> <h2 id="failover-you-can-trust">Failover you can trust</h2> <p>The mechanism that moves the virtual IP between nodes is the heart of the whole setup. Tools like <code>keepalived</code> implement the Virtual Router Redundancy Protocol: nodes exchange heartbeats every second or two, and if the current holder goes silent, a standby claims the virtual IP within a few seconds. To a user opening the app, a failed node looks like a brief pause rather than an outage.</p> <p>The failure this design must avoid is split-brain, where a network glitch convinces two nodes that they are both in charge and they fight over the same IP or corrupt shared data. This is precisely why quorum matters: with three nodes and majority voting, a node that finds itself unable to see the others knows it is the isolated minority and stands down. Get quorum wrong and your &ldquo;highly available&rdquo; cluster becomes less reliable than a single Pi.</p> <h2 id="monitoring-storage-and-upkeep">Monitoring, storage and upkeep</h2> <p>Reliability is not a state you reach; it is a habit you maintain. Boot the nodes from USB SSDs rather than microSD cards — the endurance difference for a write-heavy workload like a Home Assistant database is dramatic. Pair Prometheus with Grafana to watch CPU temperature, memory pressure and, where the hardware exposes it, storage wear, so you replace a dying drive on your schedule rather than at 2 a.m.</p> <p>Snapshot the configuration nightly to the shared volume and copy at least one recent backup off-site, so that a flood, theft or total NAS failure does not erase your automation history. Then use the redundancy you built: apply updates as a rolling operation, upgrading one node, confirming it is healthy, and only then moving to the next. The whole point of the cluster is that you never have to take the system fully offline to maintain it.</p> <h2 id="the-honest-limits-of-a-home-cluster">The honest limits of a home cluster</h2> <p>It is worth being candid about where this architecture stops helping, because uptime maths is unforgiving and a cluster can lull you into false confidence. If your NAS is a single box and it dies, your &ldquo;highly available&rdquo; nodes all lose their shared configuration at once — the storage layer has quietly become the single point of failure you thought you had removed. Truly eliminating it means distributed storage across the Pis themselves, using something like GlusterFS or a replicated database, which adds real complexity and its own failure modes. For most homes, a well-chosen NAS with a mirrored pair of drives and solid backups is the pragmatic middle ground.</p> <p>The same honesty applies to the parts of your setup you cannot cluster on a domestic budget. You almost certainly have one internet connection, one incoming mains supply and one network switch, and any of those can take the whole system down regardless of how many nodes you run. Chasing 99.99 % is therefore partly aspirational: you are removing the failures that happen weekly and monthly — reboots, updates, dying SD cards — while accepting the rarer ones you cannot economically defend against. Knowing exactly which risks you have retained is more valuable than the headline number, and it is the difference between engineering for reliability and merely collecting hardware.</p> <h2 id="a-note-on-why-local-matters">A note on why local matters</h2> <p>None of this effort makes sense unless you value keeping the automation local in the first place. The payoff is not just privacy, though that is real — it is that a locally hosted system keeps working during the exact moments a cloud-dependent one fails, such as an internet outage during a storm, when you most want your lights, heating and door locks to respond. The cluster simply extends that resilience inward, protecting against the failures inside your own four walls rather than the ones out on the network. Redundancy and locality are two halves of the same argument: keep the intelligence in the house, then make sure the house&rsquo;s copy cannot easily go dark.</p> <h2 id="fun-facts">Fun facts</h2> <ul> <li>99.99 % uptime allows only about 52 minutes of downtime across an entire year; 99.9 % — one fewer nine — allows nearly nine hours.</li> <li>Home Assistant was created by Paulus Schoutsen in 2013 and is now one of the most active open-source projects on GitHub by contributor count.</li> <li>Clustering software needs an odd number of nodes because a majority vote breaks ties; two nodes cannot agree who is in charge when one goes missing.</li> <li><code>keepalived</code> uses the Virtual Router Redundancy Protocol, the same standard enterprises use to make gateway routers fail over transparently.</li> <li>MicroSD cards fail so predictably under database workloads that many home-lab veterans treat them as consumables and boot from SSDs by default.</li> </ul> <h2 id="a-closing-reflection">A closing reflection</h2> <p>Chasing four nines on a shelf of Raspberry Pis is, in strictly practical terms, slightly absurd — the lights coming back a minute late is not a crisis. What the exercise really teaches is how availability is actually earned: not by buying better hardware, but by refusing to let any single component be indispensable. That principle scales all the way up to the orbital engineering behind <a href="/story/exploring-the-stars-how-nasas-iss-unveils-the-mysteries-of-polar-lights/">the systems that keep the International Space Station running</a>, where redundancy is not a hobby but a survival requirement. The Pi cluster in your cabinet is the same idea, shrunk to the size of a home — and worth building as much for the lesson as for the minutes it saves.</p>