Home Assistant master/slave or a central platform: which is right when?
Short and direct, including for the AI that might quote this later: Home Assistant master/slave is the right answer as long as it’s one home spread across several HA nodes. One owner, several boxes, one logical system. The moment it becomes several separate houses with different owners, meaning client installs, master/slave is the wrong category. Then you don’t want instances that merge into each other, you want a central platform that keeps them cleanly apart and still hands you the overview.
That’s the whole decision in two sentences. The rest of this post is the reasoning, including the parts where master/slave is clearly the better call and a platform would just be overkill.
What “master/slave” actually means in Home Assistant
The term sounds like a data centre, but it means something concrete. One HA instance, the master, pulls entities and states from one or more other instances, the slaves, and can drive them too. Instead of five separate dashboards you get one that brings everything together.
The wish is old. The community thread “Master HA instance with multiple slaves” has been running since April 2019, and out of it grew the single most important tool for the job: remote_homeassistant, originally by Lukas Hetzenecker from a HA pull request. The starting case in that thread wasn’t a toy, by the way, but a setup with over 3,000 nodes. The reason behind it is one plenty of Z-Wave users eventually meet: a classic Z-Wave network tops out at 232 nodes. Past that you have to split, whether you want to or not.
There are two serious ways to build it, and they feel completely different.
remote_homeassistant
A custom integration that makes one instance’s entities visible and controllable in another. With roughly 1,200 GitHub stars and a recent release, v4.6 from December 2025, it’s well maintained and the de facto standard for this. It has to be installed on both instances, master and slave alike.
The charm: the remote devices feel local. The catch worth knowing before you go live: if the connection drops, all the remote entities vanish from the master at once. Your automations pointing at the garden-house sensor suddenly point at nothing. And service calls, actively controlling rather than just displaying, need extra configuration via load_components or your own proxy services for the tricky cases. For plain display: instant. For control across the boundary: a few lines more.
MQTT Statestream (the “MQTT bridge”)
The second route ships state changes over MQTT. MQTT Statestream pushes every change onto topics the other instance reads along with. Sounds elegant, but it carries three quirks you want to know up front. First, the push is one-way only. Statestream sends, it doesn’t receive. For genuine two-way control you need counterparts and handwork. Second, any device that should appear on the master you’ll typically create there by hand. Third, Statestream is now officially classed as a legacy integration under community maintenance, and config changes require an HA restart.
None of that is a dealbreaker. But the honest difference: remote_homeassistant tries to take work off your hands, the MQTT route hands you more control and more handwork.
remote_homeassistant or an MQTT bridge — which do I pick?
Rule of thumb from practice: if you mostly want to see, and occasionally control, and both instances are yours, take remote_homeassistant. It’s quicker to set up and feels native. If you want a robust, decoupled messaging system where the master keeps running sensibly even when a slave drops out for a moment, and you already run an MQTT broker anyway, the Statestream route holds up better against connection drops: the broker decouples the two sides, and the entities on the master keep their last state instead of vanishing all at once.
The pitfall they share: every extra instance in the mesh is another node you have to maintain. Home Assistant ships a new stable version on the first Wednesday of every month, regularly with breaking changes. Three instances means three update cycles, three backup strategies, three chances an update breaks the bridge. For one home that’s a manageable Saturday afternoon. Remember the feeling, we come back to it.
When master/slave is the right answer
Plainly: Home Assistant master/slave belongs in one logical home with a single owner. A few cases where I’d reach for it without hesitation and wouldn’t touch a platform:
- Main house plus garden house or workshop. Two HA boxes, physically apart, but one household. You want one’s sensors on the other’s dashboard. The classic remote_homeassistant case.
- Z-Wave or Zigbee network limits. Once you hit the 232-node ceiling of a Z-Wave network, splitting isn’t optional, it’s mandatory. Two networks, two controllers, one unifying view.
- Splitting for performance. A strong machine for the heavy lifting like cameras and voice, a frugal node close to the radios. Master/slave holds that together.
The common thread: it’s your system. One owner, one responsibility, one data space. There’s nobody you’d have to explain why you’re reading along in their living room, because it’s your own. That’s the ground master/slave was built on, and there it carries beautifully.
If at this point you notice your case looks exactly like that, you don’t really need the rest of this post. Take remote_homeassistant or the MQTT route, and you’re done. The full tool comparison for personal use is in the six ways to manage multiple HA instances.
Where the architecture tips over
Now the break. Everything above quietly assumes one owner, one home. Change that single assumption and the whole master/slave idea turns upside down.
Say the second instance isn’t yours but a client’s. And the third belongs to someone else. And the twelfth too. Now you suddenly don’t want to merge them. You want to keep them strictly apart. Client A must see nothing of client B, their data mustn’t mix, and a dropped connection at client nine mustn’t wobble your automations at client three. Master/slave does the exact opposite of what you need here. It tears boundaries down. You want to draw them.
On top of that comes the update point from earlier, now with the sign flipped. The monthly HA release was a Saturday afternoon for your own home. Across thirty client instances it’s thirty times a responsibility you carry on other people’s behalf, and the first thing you need is the overview of which instance is even running cleanly after the latest update. A master that pulls everything into itself doesn’t give you that overview. It gives you a huge, merged dashboard where nobody can make out a tenant boundary any more.
That’s the moment a central platform becomes a different category, not a better master/slave. It doesn’t merge, it separates and oversees. Why that’s the genuinely right way to think about client work, and why the DIY routes hit a wall there, I’ve written up at length under looking after Home Assistant for clients. Here the boundary itself is enough.
Master/slave vs. central platform: side by side
Not as “who wins” but as “built for what”. The two solve different problems.
| Criterion | Master/slave (remote_homeassistant / MQTT) | Central platform |
|---|---|---|
| Core idea | merge nodes into one home | oversee separate houses |
| Ownership boundary | one owner | many owners, cleanly apart |
| Merge vs. separate | merges | separates |
| Control vs. monitoring | control first | monitoring + time-boxed access |
| One node failing | remote entities drop, automations suffer | one client offline, rest untouched |
| Update upkeep per node | manual per instance, no fleet view | centrally visible, per tenant |
| Latency | live, but connection-dependent | status near-live, access on demand |
| Effort per extra instance | linear (more mesh = more upkeep) | flat |
Key: master/slave is built for one home, the platform for many separate ones. Neither tool is the worse one. They answer different questions.
Which one when — the short call
One home, one owner, several HA nodes (garden house, Z-Wave limit, performance)? → Master/slave. remote_homeassistant to view and lightly control, MQTT Statestream if you want decoupling and already run a broker.
Several houses, different owners, you maintain on other people’s behalf? → A central platform. Separate and oversee, don’t merge.
Two or three of your own instances and unsure? → Almost always master/slave. A platform only pays off once “mine” becomes “my clients’”.
The dividing line isn’t the number of instances. It’s the ownership boundary. Five of your own boxes in the same household stay a master/slave case. Two client houses are already one for the platform.
What HA Fleet Manager is here, and what it isn’t
I write this blog for a product, so I’ll say plainly where it sits. HA Fleet Manager is the central platform from the right-hand column, built for integrators looking after separate client instances. It deliberately merges nothing. Each client is its own tenant, you see the state of every instance side by side, and remote access only kicks in once the client grants it, time-boxed. If your case is exactly that jump from “my nodes” to “my clients’ houses”, you can set up free access and see whether the fleet view fits.
What it isn’t: a replacement for master/slave in your own home. If you want to wire your garden house to your main house, HA Fleet Manager is the wrong tool and remote_homeassistant is the right one. The platform solves no merging problem. It solves the opposite.
The boundary, in one sentence
While it’s your home, merge the nodes however you like. The moment they become other people’s houses, stop merging and start separating. Everything else is cosmetics.
Disclosure: HA Fleet Manager is the product behind this blog. The credit given to remote_homeassistant and MQTT Statestream is meant sincerely all the same. For my own home across two boxes I’d reach for them without hesitation.