Getting Home Assistant Off Your Local Network: Remote Access Decisions That Actually Matter
The Docker stack is running. Z-Wave devices are responding. MariaDB is handling the recorder. The local experience is solid. Then someone asks whether they can control the lights from their phone when they're away from home, and the comfortable self-contained feeling of the stack immediately collides with the question of network exposure.
Remote access is where operating context matters most for this setup. The decisions here don't just affect convenience — they determine your security posture, your vendor dependency profile, and how much of your maintenance time gets spent on the access layer rather than on the automation itself. The choices are not equivalent. They solve different problems and carry different risks.
Does Anything Open to the Internet?
The first question isn't which method to use. It's whether you're willing to maintain an exposed service at all.
Opening a port puts Home Assistant on the public internet. It's reachable from your phone on a cellular network, which is the point. It's also continuously reachable from scanners, bots, and systems looking for exposed services to probe. TLS encrypts the connection but does not prevent brute force attempts, credential stuffing, or exploitation of an unpatched vulnerability in HA or one of its integrations. Securing a publicly-exposed HA instance correctly requires strong TLS, authentication hardening (MFA at minimum), IP whitelisting or intrusion blocking, continuous update discipline across HA core and every installed integration, and an understanding of what each integration exposes on the wire. That's not a theoretical list. It's the actual maintenance load of the open-port approach.
The alternative framing: Home Assistant doesn't need to be on the internet. A VPN — Tailscale or WireGuard — lets you reach your local network remotely with no port exposed to the public internet. HA thinks it's talking to a local client. From a security standpoint, this is a qualitatively different model. Not more secure open ports. No exposure to the open internet at all.
This is the first decision to make explicitly, because everything that follows branches from it. VPN closes that branch entirely. Once you've chosen a VPN posture, the remaining decisions are about which VPN and what it costs to maintain. If you're willing to put HA on the internet, the remaining decisions are about how to do it without that being a liability.
In a homelab running on your personal time, the consequence of a compromised HA instance is real: it can see your presence, control your physical environment, and depending on your integrations, access your network. It's not a production SaaS with a security team — it's a service maintained by one person with other things to do. VPN removes the exposure problem rather than managing it. For most homelab operators, that's the right tradeoff.
In an enterprise context, exposed home services wouldn't typically be the conversation — but if you're running HA in a lab environment or advising someone who is, the posture holds: keep it off the internet unless there's a specific reason it needs to be there.
Nabu Casa vs. VPN: What They're Actually Solving
Most of the Nabu Casa vs. self-hosted discussion treats these as equivalent-class options with different tradeoff profiles. They're not. They solve different problems, and conflating them leads to comparisons that miss the point.
Nabu Casa is a managed remote access proxy with bundled voice integration and automated backups. It opens no ports on your router. It handles TLS. It provides a persistent URL for your instance. It proxies voice assistant integrations — Google Home, Alexa — without requiring you to expose HA directly to the internet. The cost is $7.50 per month and a dependency on Nabu Casa's infrastructure for remote access. If Nabu Casa has an outage, your remote access is down. If their infrastructure has a security incident, that's a potential vector. These are real risks. They're also risks that Nabu Casa has structural incentives to manage — their business depends on it, and they're the company that funds Home Assistant's core development.
Tailscale or WireGuard gives you a private network. Remote access to everything on your home network, not just HA. No port exposure. No third party in the data path for the connection itself. It requires a client on each remote device and some initial setup. Operational overhead after that is low but not zero — access management means client maintenance across the devices you want to connect. The security posture is better than any internet-exposed approach because the attack surface is smaller: your instance isn't reachable from the internet at all, only from devices enrolled in your private network.
The honest comparison: if your only requirement is remote access to HA with no voice assistant integration, VPN wins on security posture and long-term cost, and Nabu Casa wins on setup simplicity. That's a real tradeoff. Where it gets more interesting is voice assistant integration.
Voice Integration Changes the Calculation
If you want Google Home or Alexa to control your HA devices, you're introducing a cloud-to-local integration path that needs to exist somewhere. Nabu Casa handles this natively. Home Assistant Cloud manages the OAuth flow, keeps the voice assistant's backend talking to your local instance, and requires no exposed ports. It's the cleanest architecture for this specific requirement.
Without Nabu Casa, getting voice assistant integration working generally requires exposing HA to the internet so the voice assistant's cloud can reach it. Which reintroduces the open-port problem VPN was designed to avoid. You can architect around this — there are community solutions — but you're now maintaining something that Nabu Casa makes invisible.
The alternative is local voice. Whisper for speech recognition, piper-tts for responses, running on-device or on a separate local host. This is a fully private, zero-cloud-dependency setup. It's also a different project, with its own hardware requirements and its own maintenance surface. It doesn't integrate with the assistant ecosystems your household might already use.
This is a named variable with a clear decision path. If voice assistant integration (Google, Alexa) is required by your use case or your household: Nabu Casa is not just convenient, it's the right architecture. It solves a real integration problem in a way that the self-hosted alternatives handle only with significant added complexity or added exposure. If voice integration isn't required, or if local voice is acceptable: VPN + no cloud voice dependency is the cleaner security posture and the correct call.
The homelab operator using HA for personal automation — presence detection, climate control, scripted scenes — with no family members expecting to say "Hey Google, turn off the living room lights" has a clean answer. VPN, local access, no subscription, better security.
The operator with a household that's already embedded in Google or Amazon's ecosystem is making a different calculation. Nabu Casa isn't the expensive option there. It's the option that avoids a more complex exposure model for something you'd have to maintain indefinitely.
What Nabu Casa's Backups Actually Cover
Nabu Casa includes automated HA backups as part of the subscription. Encrypted, automatic, stored in their infrastructure. The constraint worth knowing: only the most recent backup is retained, with a 5GB file size limit. This is useful for specific recovery scenarios — a corrupted configuration, an accidental change that broke something, a host failure that requires rebuilding from scratch. It is not a historical archive. It doesn't replace a local backup strategy.
For a Docker-based installation, backup is already a containerised concern you're managing. HA config lives in a defined volume. MariaDB data lives in a defined volume. Z-Wave JS UI config lives in a defined volume. Backing these up means backing up the volumes — which fits naturally into whatever tooling the host is already running: rsync to network storage, rclone to an offsite bucket, Duplicati for scheduled encrypted backups. The explicit volume definitions in the Docker stack actually make backup easier to reason about than HAOS, where things are less obviously separated.
Nabu Casa's backup is a useful safety net and worth having if you're subscribed anyway. It should not be your only net. The 5GB limit matters if your MariaDB recorder has years of history. The single-backup policy means it's a point-in-time recovery tool, not a versioned history. Both constraints are fine to work with once you know they exist — they become a problem when you discover them during a recovery event.
What to Carry Forward
The remote access decision for this stack has three genuinely distinct variables: whether anything faces the internet (VPN removes this entirely), whether voice assistant cloud integration is required (which changes the Nabu Casa calculus from convenient to architecturally justified), and what your backup posture needs to cover (Nabu Casa's net is thin but automatic; self-managed is more flexible but requires effort to maintain).
A misconfigured open-port setup is demonstrably less secure than Nabu Casa. This is worth saying plainly because the homelab instinct is often to self-host everything and assume that means more control and more security. On remote access, the managed option with zero open ports is a harder posture to accidentally undercut than a self-hosted reverse proxy with an SSL certificate and a prayer. The self-hosted path is more secure than Nabu Casa only if it's configured and maintained correctly. That's a real condition, not a formality.
The defensible homelab posture without voice integration requirements: Tailscale or WireGuard, self-managed volume backups, no Nabu Casa dependency. The defensible posture with household voice assistant integration: Nabu Casa handles the integration architecture cleanly, the $7.50/month is paying for a solved problem you don't want to unsolved at the access layer.
Where you land depends on what you've committed to in the rest of the stack. The Docker installation already signals a preference for explicit control and accepted complexity. Remote access is the one layer where that preference should be examined honestly rather than assumed — because the cost of getting it wrong isn't extra maintenance time, it's an exposed service in your house.
