Home Assistant Remote Access 2026: What the Tutorials Don't Tell You

There's a moment in the life of every Home Assistant user. You're away for the weekend. Your partner texts: "something's broken" - the living room lights won't respond. You open HA in the mobile app. Spinning wheel. Timeout.

And that's when you realize the whole beautiful setup - 200 ZigBee devices, 40 automations, a dashboard you've been polishing for a month - is only accessible within Wi-Fi range of your house.

Tutorials online say: "set up a VPN" or "open port 8123." Both are technically correct. Both are a bad idea in 2026 for most people. Here's why.

TL;DR for people in a hurry#

• Port forwarding works, but exposes your HA panel to scanners from the entire internet. Without extra work = permanent exposure to zero-days in HA.
• VPN (WireGuard) is great for you, but bad for family - a separate app on every phone, breaks when the network changes.
• Nabu Casa is simple, but locks you into the HA ecosystem - if you also run Jellyfin or Grafana, you need a second solution anyway.
• Tailscale combines VPN benefits with convenience, but still needs a client app.
• Reverse SSH tunnel (what services like SmartHomeEntry for home do) gives you a normal HTTPS address - family just clicks a link in the browser.
• If you're behind CGNAT (mobile LTE/5G, most 5G home internet, many European fiber plans) - you have two options: an outbound tunnel (SSH/Nabu Casa/Tailscale) or you go to bed without remote access.

The rest of this article is the "why."

What your home network actually looks like in 2026 - not like in that 2018 tutorial#

When someone told you to "open a port on the router," they probably wrote that before the CGNAT era. And I've spent too much time explaining to people why their port forwarding "isn't working," before I finally started asking: "who's your ISP, and is it LTE?"

Why your ISP doesn't love you anymore#

The reason is both technical and political. There are finitely many IPv4 addresses - about 4.3 billion. The world has over 8 billion connected devices. Carriers solved it in the worst possible way for hobbyists: Carrier Grade NAT (CGNAT).

Instead of giving every customer a public IP, the ISP gives you a private address (e.g. 100.64.x.x), and a whole group of customers shares a single public address at the carrier level. Everything outbound works - websites, email, streaming. But no one from outside can reach you. Port 8123 on your router? From the internet's perspective, it doesn't exist. It will never work. You can click UPnP all day.

You'll find CGNAT on:

• Every mobile internet plan (T-Mobile, Verizon, EE, O2, Vodafone, Orange, Play - anywhere in the world, on any carrier) - 100% of cases.
• Most 5G fixed wireless access (T-Mobile Home Internet, Verizon 5G Home, Vodafone GigaCube, similar European offerings) - 95%+.
• A growing share of fiber ISPs - 20-40% depending on country and provider. In parts of Europe approaching majority.
• Most "neighborhood" ISPs that share a single /24 upstream block.

How to check: go to whatismyip.com from home, note the IP. Then check your router admin, find "WAN IP." If they differ - you're behind CGNAT. If they match - you have a public IP.

The consequence: 90% of YouTube tutorials don't apply to you anymore#

You land on a channel with 200k subscribers. The guy does port forwarding on a 2019 TP-Link. It works for him - he's on cable with a legacy public IP. It won't work for you because you're on fiber behind CGNAT. Comments: "doesn't work, am I dumb?". Author reply: "restart your router." That's about as useful as "your internet is slow - try turning off Wi-Fi."

Seven ways to get remote HA - an honest ranking#

Each of these is the correct answer under specific conditions. The problem with internet advice is that nobody tells you under what conditions.

1. Port forwarding + dynamic DNS#

How it works: open port 8123 (or 443 with a reverse proxy) on your router. A domain like yourhome.duckdns.org points to your public IP, updated by a DynDNS client.

When it makes sense: you have a public IP, you own a domain, you know how to configure Nginx with Let's Encrypt, you actively monitor security logs.

Why almost nobody meets those conditions: because nobody monitors logs. In three months, a CVE drops in some HA integration and you'll be on holiday. Add to that the fact that most users set this up once and that's it - zero updates, zero fail2ban, the password is still admin1234 from 2020.

Verdict: for the 1% of people who do internet networking for a living. For the rest, a trap.

2. WireGuard / OpenVPN#

How it works: you run a WG server on HA (add-on), generate keys, install the app on every household device. Every phone connects to your home network as if it were inside.

Pros: full network access (not just HA - also NAS, printer, cameras), strong encryption, zero cost.

Cons nobody mentions:

• An app on your partner's phone. Every new houseguest = fresh setup.
• Mobile HA in transit. Phone switches between LTE and café Wi-Fi, VPN disconnects, notifications from HA get lost, then suddenly show up.
• Battery. WireGuard is light, but always-on VPN eats 5-15% of battery per day.
• Doesn't work behind CGNAT. If your router doesn't have a public IP, the WG server on it doesn't either. Circle closes.

When WireGuard is good: a single user, public IP, you do networking professionally, and want to manage everything (not just HA).

3. Tailscale#

How it works: overlay network. Each device (yours, partner's, HA) installs a Tailscale client, which creates a mesh through their coordinator. Tailscale solves CGNAT via DERP relay.

Pros: works everywhere, even behind CGNAT. Minimal setup. Free tier up to 6 users, unlimited devices.

Cons:

• An app on every device. Same problem as WireGuard - a housesitter coming for a weekend won't install Tailscale.
• The coordinator is closed source (Headscale is an OSS alternative but it's another project to maintain).
• Performance degrades over DERP - if your devices can't do P2P (both behind CGNAT), traffic goes through a Tailscale server, possibly in Oregon. HA latency for a user in Europe: 180-250 ms.

When Tailscale is good: one or two people, you need access to other devices beyond HA, you're fine with a client on every phone.

4. Nabu Casa (Home Assistant Cloud)#

How it works: the official cloud service from Nabu Casa (the company that develops Home Assistant). Setup: one toggle in settings. You get an address like randomstring.ui.nabu.casa.

Pros: simplest deployment in this entire article - one switch. Supports HA development financially. Works behind CGNAT. Alexa, Google Assistant configured out of the box.

Cons:

• Works only with Home Assistant. Jellyfin? No. Grafana? No. Your photo gallery running on that mini PC? No. For every other service, you need a second solution.
• Random subdomain. abc123xyz.ui.nabu.casa isn't something you'll memorize.
• Latency. Traffic goes through Nabu Casa's relay, by default in the US. European users see ~150-250 ms extra.
• No full HTTPS on your domain. You can't use home.yourdomain.com.

When Nabu Casa is right: you use ONLY Home Assistant, you value simplicity, and you want to support the project.

5. Cloudflare Tunnel (cloudflared)#

How it works: Cloudflare's free tier. You install cloudflared on HA, it creates an outbound connection to Cloudflare, and you configure home.yourdomain.com → tunnel in the Zero Trust dashboard.

Pros: free, works behind CGNAT, you get your own domain, HTTPS with a CF cert, Cloudflare DDoS protection.

Cons:

• Requires your own domain (a cheap .com costs $10/year).
• Cloudflare may terminate connections based on WAF rules (if HA sends a "weird" request) - fantastic to debug.
• Video streaming (cameras, Jellyfin) violates Cloudflare's ToS for the free tier. Officially. Enforcement is uneven, but your RTSP camera through cloudflared is Russian roulette.
• Setup: not super complex, but requires understanding DNS, Zero Trust dashboard, tunnels. Not "60 seconds."

When Cloudflare Tunnel makes sense: you already own a domain, you don't stream video, you're comfortable in the Cloudflare stack.

6. ngrok / other dev-tunnel tools#

How it works: ngrok creates a tunnel to your HA and gives you xyz.ngrok.io.

Pros: fastest possible launch, 30 seconds.

Cons:

• Free tier drops sessions every 2 hours - your URL changes.
• Paid ngrok is expensive for just HA ($10/month for the Hobbyist plan with a fixed subdomain).
• Not designed for production - for a one-hour demo YES, for year-round HA at home NO.

When ngrok is right: showing HA to a friend at a meetup for an hour. Not for permanent use.

7. Reverse SSH tunnel (self-hosted or managed service)#

How it works: an agent on your HA opens an outbound SSH tunnel to a relay server. The relay exposes your HA under a fixed HTTPS URL. Zero open ports on your side.

Pros:

• Works behind CGNAT (outbound tunnel, not inbound).
• Stable HTTPS subdomain - yourhome.smarthomeentry.com (or your own, if self-hosted).
• Family without an app - everyone opens a link in their browser. Grandma too.
• Supports any HTTP service - HA, Jellyfin, Nextcloud, Grafana, whatever you run.
• Outbound SSH is a protocol that passes through every firewall and every CGNAT. Always.

Cons:

• Depends on the relay. If you use a managed service (like SmartHomeEntry), your access depends on their uptime. Self-hosted = another server to maintain.
• Doesn't give you full network access (unlike a VPN). You can't SSH into your Pi over this link. It's an HTTP-layer tunnel.
• Costs money if managed ($3-8/month for home).

When it's for you: family without tech skills, you want "click a link and it works," you have CGNAT, you also run other services (NAS, Jellyfin). Most real hobbyists.

Reverse SSH - what does this agent actually do#

Because it sounds like magic, but it isn't. Let me break it down, because nobody explains it clearly.

Picture calling the hotel reception and saying: "I'll call back in 10 seconds, keep the line open." Then you call a second time, and reception patches you through to the person already waiting. The caller never needed to know your number.

The agent does the same with TCP:

1. The agent calls the relay (SSH outbound, port 22 or 443). Your router doesn't block it, because outbound SSH is normal traffic.
2. The agent tells the relay: "reserve local port 20451 for me, and whatever comes in at yourhome.smarthomeentry.com, send it my way."
3. The relay records your mapping in memory.
4. A user visits yourhome.smarthomeentry.com - DNS points to the relay.
5. Nginx on the relay receives the request, checks the mapping: "ah, this subdomain = tunnel to agent #42." Forwards to localhost:20451.
6. Port 20451 on the relay is the channel to the agent. The agent picks up traffic, forwards it to localhost:8123 on your server (where HA lives). HA responds, traffic flows back the same way.

Key consequences:

• Your HA is never directly accessible from the internet. Only a slice of the relay is, and only as a mapping to your tunnel.
• Port 20451 on the relay binds to 127.0.0.1, not 0.0.0.0. Nobody outside sees it except the relay's own Nginx.
• SSH keys are unique per tunnel. Compromising one agent gives no access to others.
• HTTPS terminates on the relay, not on your HA. Simplifies certificates (wildcard LE).

Security: three things tutorials won't tell you#

1. HTTPS is not security. It's privacy.#

Every tutorial says: "you need HTTPS!" True. But HTTPS protects you from traffic snooping at a café - not from someone guessing your HA password and logging in. Two different problems.

If you use admin/admin - HTTPS does nothing for you. If you use jones_2007 and exposed port 8123 to the internet - a bot will log in within 48 hours.

What to do: enable 2FA in HA (Menu → Your Profile → Multi-factor authentication). One field that changes the game. Plus a password manager.

2. Home Assistant updates are critical, but they break automations#

HA ships a monthly release. Every release contains security fixes. If your installation is exposed to the internet and you update every six months "because I'm afraid things will break" - you're vulnerable to zero-days for five months at a time.

A reverse SSH tunnel (or any solution that doesn't expose a port) reduces this problem, because an attacker first has to get through the relay. It doesn't eliminate it, though.

What to do: enable automatic HA Core updates (Supervisor → Settings → Updates). Monthly updates. Core breaking changes are rare; breaking changes are in custom components.

3. HA logs tell you exactly who's trying to log in#

Go to Developer Tools → Logs. Type "auth". You'll see:

• Login attempts from your own IPs (yours, household members').
• If you expose HA to the internet: thousands of attempts from 185.x.x.x, 91.x.x.x, 47.x.x.x - scanning bots.

If you see the second kind, and you don't have 2FA - you have a problem "in a week, in a month, at some point." Reverse SSH eliminates it, because your HA is physically unreachable without going through the relay.

Redundancy: what if the relay goes down?#

A critical question that most sponsored articles won't answer. I'll answer honestly.

• Your HA still works locally. Lights at home, automations, notifications to devices in Wi-Fi range - all work. The relay is only the remote access layer.
• You lose external access. Can't open the app from work. Can't check the alarm from vacation.
• The agent retries every 60 seconds. When the relay is back, your tunnel is too. You don't have to do anything.
• For critical use cases (elderly monitoring, security) - reverse SSH is a single vector, so an outage = no access. Worth having a second independent channel (Telegram bot from HA, SMS from a motion sensor via Twilio).

My recommendation: for most people, this is acceptable risk. Relay outages are maybe 2-3 hours a year. Similar to an upstream ISP hiccup.

Performance: how many ms does your thermometer widget actually lose#

Practical question, because if you tap the HA dashboard and the light comes on 800 ms later instead of 50 ms - it's frustrating.

I measured (user in Europe, relay in Warsaw):

• Port forwarding (direct): 30-80 ms.
• Reverse SSH tunnel (EU relay): 50-120 ms.
• Nabu Casa (US relay): 150-250 ms.
• Tailscale DERP relay: 180-300 ms.
• Tailscale P2P (both endpoints with public IPs): 30-80 ms.

Conclusion: relay location matters. For a European user, an EU-based relay feels nearly local. A US relay is perceptible degradation in UX.

Mobile HA - no compromises#

This section is written out of frustration. The HA Companion app works well, but needs a URL to your HA. And here every method has traps:

• Port forwarding + DynDNS: works, but the app occasionally loses the connection when switching networks (Wi-Fi → LTE).
• VPN: HA Companion struggles with always-on VPN, especially on bad networks (hotel, traveling abroad).
• Nabu Casa: best integration with the app (one-click in config). Simplest setup.
• Reverse SSH: the app sees it as regular HTTPS. Works out of the box. Add yourhome.smarthomeentry.com, done.

Mobile push notifications from HA - here Nabu Casa wins due to their integration with FCM/APNS. Other options require configuring your own push (realistically: a Telegram bot is the cheapest reasonable fallback).

When NOT to use SmartHomeEntry (or reverse SSH in general)#

Since I'm writing this from the position of someone building this product, I want to be straight:

• You're a sysadmin, live alone, have a public IP. Set up WireGuard - free, full control, you'll learn something.
• You use ONLY Home Assistant and nothing else. Nabu Casa is simpler and supports HA's creators.
• You stream 4K from cameras non-stop. A relay (ours or Nabu Casa's) isn't the right channel for continuous 15 Mbps streams. Better: port forwarding + rate-limited Nginx.
• You obsess over <50 ms control latency. For turning on a lightbulb, 150 ms is fine. For a robot vacuum, also fine. For games - not HA's problem.
• You want everything on your own infrastructure with zero external dependencies. Set up your own SSH server + Nginx - it's a weekend project and an ongoing VPS to maintain.

When reverse SSH is for you: you have CGNAT (the majority of European hobbyists), family has no patience for VPNs, you run multiple services (HA + NAS + Jellyfin), you want "click and it works." This describes maybe 70% of HA users in Europe.

How to do it in 60 seconds (practice)#

If after all those arguments you're thinking "OK, reverse SSH makes sense" - here's the full setup with SmartHomeEntry.

Step 1: create an account#

Go to smarthomeentry.com, pick a plan (Home $7/month for 1 service is enough). Your subdomain name.smarthomeentry.com is provisioned.

Step 2: copy the command#

In the account panel you get a curl line:

curl -fsSL https://get.smarthomeentry.com | sudo bash -s -- --token ABCD1234

Step 3: paste it in the HA terminal#

How do you get a terminal? Depends on the platform:

• HAOS: Menu → Terminal & SSH (community add-on).
• HA Supervised on Pi: SSH to [email protected].
• HA Core (Docker): docker exec -it homeassistant bash.
• HA on separate Linux: just SSH.

Pasted, Enter. The agent:

• Downloads the binary (~8 MB).
• Generates SSH keys.
• Writes a systemd unit (or cron / Docker restart, depending on platform).
• Connects to the relay.

Step 4: open your link#

In a new tab, type yourname.smarthomeentry.com. HA loads.

Actual time (measured): 43 seconds from "subscribe" click to dashboard loaded. 60 seconds is conservative.

One question with no good answer#

What if the company you use as a relay goes under? (applies to every managed solution - Nabu Casa, SmartHomeEntry, Cloudflare, Tailscale.)

Cloudflare, Tailscale: large companies, outage risk low on a 5-year horizon. But policy changes (like the free-tier changes at CF) are a real risk.

Nabu Casa: the foundation behind HA, so it exists as long as HA does. Lowest risk.

SmartHomeEntry and other mid-size managed services: medium risk on a 10-year horizon.

Mitigation: pick a service that uses an open-source agent. If our company folds, and the SmartHomeEntry agent is public on GitHub, the community takes it over or you migrate to a fork. Vendor lock-in is minimal.

If your solution doesn't have an open agent, you're paying for convenience today but buying future risk.

What to read next#

• If you have a specific system and want the version for it: Home Assistant, Domoticz, Nextcloud, Jellyfin, NAS Synology/QNAP, Grafana.
• Deeper comparisons: Tailscale vs SmartHomeEntry, Cloudflare Tunnel alternative, ngrok alternative, Nabu Casa alternative.
• Installation on specific hardware: HA on Raspberry Pi, HA on Synology.
• Are you an installer managing multiple clients? Different article: How to close 80% of tickets from your desk.

If you read this far#

One takeaway: there isn't one good solution for everyone. There are several, each great in a different context. People who write "always use X" or "VPNs are bad" usually have few clients and lots of opinions.

My personal recommendation for the vast majority of hobbyists in 2026: a reverse SSH tunnel with a managed relay that uses an open-source agent. Best ratio of "easy to own" / "family doesn't hate it" / "works everywhere including CGNAT." If you want to try our specific implementation - 60-second setup is here.

But if after this article you end up choosing WireGuard, or Nabu Casa, or setting up your own sshd on a VPS - this article did its job too. The point was that you know why you're picking, not just what you're picking.