If you look after Home Assistant for more than two or three households, the problem stops being technical and becomes logistical. Each installation sits behind a different router, on a different ISP, with a different person who cannot help you debug it over the phone.
The short answer first, because that is usually all people need: three approaches scale past a handful of installations, and the right one depends on who else has to reach them.
The three approaches that work#
1. A mesh VPN across all of them#
Install Tailscale, Netbird or a self-hosted WireGuard mesh on every instance and on your own machine. All installations join one private network and you reach them by their internal names.
Works well when: you are the only person who ever connects, and you have admin access to each client's network long enough to set it up.
Cost: free for personal use on Tailscale, free entirely on self-hosted WireGuard.
Where it breaks: every device that needs access has to run a client and be signed into your account. That is fine for you and impossible for the client. The moment the homeowner wants to check their own heating from their phone, or you need to hand access to a colleague for one afternoon, you are back to configuring software on someone else's device. Self-hosted WireGuard additionally needs a public IP somewhere, and behind CG-NAT that has to be a VPS.
2. A reverse tunnel per installation#
An agent on each instance opens an outbound connection to a relay, and each installation gets its own HTTPS address. You open a link, the client opens the same link, nobody installs anything.
Works well when: other people need access too, or when client networks are behind CG-NAT.
Cost: paid, per installation.
Where it breaks: it costs money that a mesh VPN does not, and you depend on the relay operator. It also exposes a login page to the internet, so the strength of each installation's own password starts to matter.
3. A VPS as a jump host#
Rent a small server, have each installation open an SSH tunnel to it, and connect through it yourself.
Works well when: you enjoy running infrastructure and want to own the whole path.
Cost: a few euros a month for the VPS, plus your time.
Where it breaks: you have just become the operator of a piece of production infrastructure that your clients' access depends on. Certificates, updates, monitoring of the jump host itself and its backups all become yours. This is a reasonable choice for five installations and an unreasonable one for twenty, unless running servers is something you already do.
What does not scale, even though it looks like it should#
Port forwarding on each client's router. It works until an ISP moves someone onto CG-NAT without telling them, a router reboot drops the UPnP lease, or a firmware update resets the rule. With one installation you notice. With fifteen you find out when the client calls.
One Home Assistant controlling the rest. The Remote Home-Assistant integration genuinely works, and for a second property you own it is the neat answer. For client work it is the wrong shape: it merges separate households into a single trust domain, so a compromise or a misconfiguration in one reaches the others. Keep client instances isolated.
Doing nothing and driving over. This is the honest baseline most people are actually comparing against, and the reason it survives is that the alternatives look like work. It is worth pricing once: an hour of driving, an hour on site and an hour back is half a day for something that turned out to be a restarted add-on.
The part nobody plans for: knowing before the client calls#
Whichever route you pick, remote access solves only half the problem. It lets you get in once you know something is wrong. It does not tell you that something is wrong.
That matters more than it sounds. The failure you actually get called about is not a broken automation - it is an installation that has been offline since Tuesday and nobody noticed until the lights stopped responding on Friday evening.
Monitoring has to live outside the house it watches. Anything running inside Home Assistant goes down with it. What you want is something that pings each installation from elsewhere and tells you when one stops answering.
Set the alert threshold higher than you think. Home routers reboot, ISPs blip, and updates take a machine offline for a few minutes. An alert after three minutes will teach you to ignore alerts within a week. Fifteen minutes catches real outages and stays quiet about noise.
What this looks like with SmartHomeEntry#
For transparency about where this article comes from: we make one of the tools in category 2, so here is precisely what it does and does not do for multiple installations.
What you get:
- Up to 5 installations on the Pro plan, up to 20 on Business. Each gets its own agent, its own HTTPS subdomain and its own port.
- One list of all of them, showing which are online right now, plus average CPU and memory across the fleet.
- Offline alerts by email or webhook, with a threshold you set per rule and a cooldown so one outage does not send you fourteen messages overnight.
- CPU and memory per installation, kept for 7 days, and uptime history for 30.
- API keys, if you want the tunnel list in your own dashboard.
What you do not get, and should not expect:
- No shell on the client's machine. This is a tunnel to a web panel, not remote SSH. If the fix requires a terminal, you still need another way in. That limit is deliberate and enforced by the server configuration, not by policy.
- Alerts on offline only. There is no alert for high CPU or a filling disk. You can see those numbers in the panel, but nothing will wake you about them.
- No automatic agent updates. Updating agents on client machines is your job. Auto-update would mean us executing code on your clients' hardware, and we decided against that.
- One tunnel per service. A machine running Home Assistant and Jellyfin needs two agents and counts as two installations against your plan.
Choosing, briefly#
Only you ever connect, and you can get onto each network to set it up: a mesh VPN. It is free and exposes nothing publicly.
Clients or their families also need access, or their ISPs use CG-NAT: a reverse tunnel. Nobody installs anything, and outbound connections do not care about CG-NAT.
You already run servers and want to own the whole chain: a VPS jump host, as long as you accept that maintaining it is now part of the job.
Fewer than three installations: honestly, whatever you already use is fine. This problem starts at the point where you cannot remember which client is on which router.
The one thing worth doing regardless of which you choose is the monitoring. Remote access changes how long a fix takes. Knowing early changes whether the client ever noticed.
Related: the full guide to Home Assistant remote access covers CG-NAT and each method in more depth, and our page for installers has the fleet-specific detail.
