Home Assistant runs at home, but reaching it from outside usually means either paying for Nabu Casa’s Home Assistant Cloud subscription or opening a port directly on your router, which exposes your entire smart home to the internet. A small VPS running WireGuard gives you the same secure remote access, for the VPS’s flat monthly cost instead of a subscription, with your home network never directly exposed.
The problem this solves
Home Assistant’s own remote-access story has two well-known options, and both have a real downside. Nabu Casa’s Home Assistant Cloud is genuinely excellent, easy, and worth its subscription for many people, but it is a recurring cost for something that’s fundamentally just secure remote access to a server already sitting in your house. Port forwarding, opening a hole in your router’s firewall directly to Home Assistant, is free but means your entire smart home dashboard, every light, lock and camera, is reachable by anyone who finds that open port, a genuinely risky default for software controlling physical things in your home.
A VPS-based WireGuard tunnel sidesteps both problems: free of any subscription beyond the VPS itself, and your home network is never directly exposed, since WireGuard only allows traffic from devices holding a valid private key, not anyone who happens to scan your router’s IP.
How this differs from the industrial VPN pattern elsewhere on this site
This is the same underlying technology as VPS as a SCADA VPN Concentrator, scaled down to a single home rather than multiple industrial sites. The principle is identical: your home network makes an outbound connection to the VPS, which means it works behind a typical home router and ISP without any port forwarding or static IP required at all.
Setting up the VPS side
sudo apt install wireguard
wg genkey | tee privatekey | wg pubkey > publickeyThe VPS’s config (/etc/wireguard/wg0.conf):
[Interface]
PrivateKey = <vps-private-key>
Address = 10.20.0.1/24
ListenPort = 51820
[Peer]
# Home network
PublicKey = <home-public-key>
AllowedIPs = 10.20.0.2/32, 192.168.1.0/24The second line of AllowedIPs is the important one, it’s your home network’s local subnet (adjust to match yours), telling the VPS to route traffic for that range through the tunnel to your home, which is what lets you reach Home Assistant at its normal local address from anywhere.
Setting up the home side
Most home routers capable of running WireGuard (many modern routers, or a small device like a Raspberry Pi sitting on the network) handle this with the mirror-image configuration, pointing back at the VPS’s public IP, with AllowedIPs set to the VPS’s tunnel address so traffic destined for the VPS or other connected devices routes correctly. If your router doesn’t support WireGuard natively, the official WireGuard app, running on a Raspberry Pi or even an always-on PC at home, does the same job.
Reaching Home Assistant once the tunnel is up
With the tunnel connected, Home Assistant becomes reachable at its normal local address (commonly http://192.168.1.x:8123) from anywhere your phone or laptop can establish a WireGuard connection to the VPS, exactly as if you were on your home Wi-Fi. The WireGuard app handles this automatically once configured, no manual VPN toggling beyond turning the connection on.
A note on Home Assistant’s own security
A VPN tunnel secures the network path, it doesn’t replace Home Assistant’s own login security. Strong, unique credentials and two-factor authentication, both supported natively in Home Assistant’s user settings, are worth enabling regardless of how you’re connecting, the same defence-in-depth principle covered throughout this site’s security guides: the VPN keeps the door closed to outsiders, good credentials keep it locked even for anyone who somehow gets through.
Cost comparison
| Approach | Cost | Security |
|---|---|---|
| Nabu Casa Home Assistant Cloud | Recurring subscription | Strong, fully managed |
| Port forwarding | Free | Weak, direct exposure to the internet |
| VPS + WireGuard (this guide) | ~£3-4/mo flat VPS cost | Strong, no direct exposure |
It’s worth saying plainly: Nabu Casa’s subscription also funds Home Assistant’s open-source development directly, a genuinely good reason to choose it even where this guide’s approach is technically equivalent. This guide exists for people who’d rather spend an afternoon setting up their own tunnel than pay an ongoing fee, not as a verdict that one is objectively better than the other.
Frequently asked questions
Do I need a static IP at home for this to work?
No, the home side initiates the connection outbound to the VPS, which already has the static IP, so a typical residential dynamic IP works fine without any extra configuration.
Can I use this same VPS for other smart home services too?
Yes, this is exactly the pattern covered in Self-Hosted Smart Home Dashboard and Cheap VPN for Smart Home Devices, one small VPS comfortably handling several connected services for a typical household.
What happens to Home Assistant if my home internet goes down?
Home Assistant keeps running locally and controlling your devices regardless, since it doesn’t depend on the internet for local automation. Only remote access is affected until your connection returns.
Is this safer than just using Home Assistant’s built-in remote access feature directly?
Significantly, Home Assistant’s direct remote access (without Nabu Casa or a VPN) generally still means exposing the Home Assistant web interface itself to the internet, which is a meaningfully larger attack surface than a WireGuard tunnel that only allows pre-authorised devices to connect at all.
Can family members each have their own access without sharing one WireGuard key?
Yes, and it’s the recommended approach, generate a separate WireGuard key pair and peer entry per person or device, exactly the pattern covered in this site’s VPN concentrator guide, so access can be revoked individually if a phone is lost without affecting anyone else.
A note on location-based automations and the VPN
Home Assistant’s location-based automations, things like “turn the heating on when I’m 10 minutes from home”, rely on the phone’s GPS and its connection state, not the WireGuard tunnel directly, so they continue working correctly whether the tunnel is active or not. Worth being aware of one subtlety: some phones, depending on their WireGuard app’s configuration, route all traffic through the tunnel by default rather than just traffic destined for the home network specifically. For most people this causes no issues, but if you notice general internet browsing feeling slower while the tunnel is connected, configuring split tunnelling, routing only the home network’s address range through WireGuard and everything else normally, resolves it.
Troubleshooting a tunnel that won’t connect
Handshake never completes. Almost always either a firewall blocking UDP port 51820 on the VPS (check with sudo ufw status) or a mismatched public key between the two configs, easy to introduce by copying the wrong key during setup. Re-verify both sides’ keys match exactly before assuming something more complex is wrong.
Tunnel connects but Home Assistant isn’t reachable. Usually means the AllowedIPs line on the VPS side doesn’t include your home network’s actual local subnet, or the home-side device isn’t configured to forward traffic for that subnet through the tunnel. Double-checking both AllowedIPs lines against your actual local network range, not just copying an example verbatim, resolves most cases.
Works on Wi-Fi but not on mobile data. Some mobile networks block or heavily throttle non-standard UDP ports; trying WireGuard’s default port first, and if that’s blocked, configuring a different port (443 is commonly unblocked since it’s also used for HTTPS) usually resolves this.
Extending this to Home Assistant’s automation engine itself
Beyond simple remote viewing, a working WireGuard tunnel also means Home Assistant’s automation engine can safely call out to or be triggered by things outside your home network, a webhook from an external service, for example, routed through the same secure tunnel rather than needing a separate, less secure exposure. This is worth knowing as a natural next step once basic remote access is working comfortably.
Does this approach work for the Home Assistant mobile app’s full feature set?
Yes, once the tunnel is active, the app connects to Home Assistant’s local address exactly as it would on home Wi-Fi, with full functionality including notifications and location-based automations.
Can I set this up on a phone without much technical confidence?
The official WireGuard app, available for both iOS and Android, supports importing a configuration via QR code, generated once on the VPS or home side, scanned once on the phone, considerably simpler in practice than typing out configuration manually.
Does the tunnel need to stay connected permanently, or can I toggle it on only when needed?
Either works; some people leave it connected permanently for instant access, others toggle it on specifically when they want to check in remotely. WireGuard’s low overhead means leaving it connected permanently has minimal practical downside if you’d prefer not to think about it.
What happens if I lose my phone with the WireGuard config on it?
Remove that specific peer entry from the VPS’s configuration immediately, exactly the same revocation pattern covered throughout this site’s other VPN guides, cutting that device’s access without affecting any other connected device or family member.
Is it possible to grant a smart home installer or family member temporary access without giving them permanent credentials?
Yes, generate a dedicated peer entry specifically for that purpose, with a clear label, and remove it once no longer needed, a cleaner pattern than sharing an existing permanent key that would then need rotating afterward.
Putting it all together: a complete first session
To bring the whole setup together as a single realistic walkthrough: generate key pairs on both the VPS and the home device, write the two matching config files shown earlier in this guide with each side’s correct public key and the home network’s actual subnet, start WireGuard on both ends, and confirm the handshake completes using sudo wg show on either side. With the tunnel confirmed live, open the WireGuard app on a phone, import the matching peer configuration via QR code, connect, and try loading Home Assistant’s normal local address. If that loads correctly, the entire chain, phone to VPS to home network to Home Assistant, is proven working end to end, and every step from here is refinement rather than fundamental troubleshooting.
Most people find this entire first setup, from a cold start with nothing configured, achievable comfortably within a single evening once following a guide step by step rather than improvising, considerably less daunting in practice than it can sound described in the abstract.
Keeping the tunnel healthy over the months that follow
Once working, this setup needs very little ongoing attention, but it’s worth knowing what to check if something does eventually seem off: sudo wg show on the VPS reveals each peer’s last handshake time, a stale or absent handshake is the clearest single signal something has broken on either end. The most common cause after weeks of trouble-free operation is usually a home router reboot changing the home network’s local IP scheme, easily fixed by updating the AllowedIPs entry to match, or a phone’s operating system update resetting VPN app permissions, usually resolved by simply reopening the WireGuard app and reconnecting manually once.For any deeper troubleshooting, the VPS-side sudo journalctl -u wg-quick@wg0 log combined with sudo wg show together cover almost every connection problem encountered in practice.
The honest comparison: what you lose and what you gain
Self-hosting a doorbell camera is genuinely more effort than keeping a Ring subscription. You lose the convenience of cloud storage that just works, a polished app, and customer support when something breaks. You gain footage you own and control, alerting logic that works exactly the way you specify rather than the way the manufacturer decided, no monthly cost after initial setup, and hardware that continues to function if the manufacturer discontinues the product or changes the subscription terms. Whether that trade is worth it depends entirely on how much the recurring cost matters to you and how comfortable you are maintaining small self-hosted systems. This guide is written for people who’ve decided it is, not as advocacy for everyone to make the same choice.