Remote Access.

Before enabling remote access.

Prerequisites and framing.

A clear reason for remote access. Most agricultural operations benefit from some remote access — the grower's phone needs to reach the system for alerts and status checks, the grower needs to make adjustments when away. Some operations, though, are fine with local-only access — on-site operations with the grower always nearby, for instance. Before enabling remote access, be clear about what it is for; security considerations are different for "phone receives push notifications" versus "grower actively logs in from the road."

Understanding the threat model. Remote access means the Home Assistant installation is reachable from places you do not control. Attackers scan the internet continuously looking for vulnerable systems. An unprotected Home Assistant exposed to the internet will receive attack traffic; it is not a question of if but when. Threat modeling does not require paranoia; it requires awareness of what attackers can reach and what they can do if they reach it.

What is at stake. A compromised Home Assistant gives the attacker control over whatever Home Assistant controls. For agricultural operations, this includes irrigation, climate, lighting, cameras, and potentially more. Beyond direct control, a compromised Home Assistant is a foothold on the operation's network — a starting point for attacks on other systems. The stakes are not hypothetical.

Strong authentication first. Before anything else, Home Assistant should have strong passwords for every user, two-factor authentication enabled for administrator accounts, and no default or weak credentials. This is baseline; everything else assumes it. [User Management and Security](/home-assistant/operations/security) covers this foundation.

The remote access options.

Three broad categories, each with trade-offs.

Nabu Casa. Home Assistant's official cloud service. Paid subscription (modest monthly cost). Provides remote access to Home Assistant without requiring any inbound firewall rules. The phone app connects through Nabu Casa's cloud; Nabu Casa relays the connection to the local Home Assistant. Zero networking configuration on the grower's end; strong security; supports the project.

VPN. A virtual private network that extends the operation's local network to remote devices. WireGuard and Tailscale are the common options. The grower's phone or laptop connects to the VPN; once connected, the device is "on" the local network and can access Home Assistant as if physically present. No Home Assistant-specific configuration needed; access control happens at the VPN layer.

Reverse proxy. A web server (Nginx, Caddy, or similar) on the public internet that authenticates traffic and forwards legitimate requests to Home Assistant. More complex than the other options; allows customization (custom domains, fine-grained access control, integration with external authentication). Requires disciplined security configuration to avoid becoming an attack vector.

What is not on the list: port forwarding directly to Home Assistant. This is the anti-pattern. Exposing Home Assistant's web interface directly to the internet through a router port forward, with or without basic authentication, is not secure enough for agricultural operations. The "What not to do" section covers this in more detail.

Nabu Casa.

The official path for most operations.

What Nabu Casa provides. Remote access to Home Assistant through the app. Text-to-speech services (the voice used for announcements). Cloud backups (covered in [Backup and Recovery](/home-assistant/operations/backup)). Access to Home Assistant's Assist cloud features. Alexa and Google Assistant integration for operations using those assistants. The subscription contributes to Home Assistant's development.

How it works. The Home Assistant instance connects outbound to Nabu Casa's cloud. The grower's app connects to Nabu Casa; Nabu Casa relays traffic to the Home Assistant instance. No inbound firewall rules needed; no router configuration; no public IP required.

Setup. Create a Nabu Casa account; subscribe; enable Home Assistant Cloud in Home Assistant's configuration; sign in. The remote access works immediately. For most operations, setup takes minutes.

Security. Nabu Casa's infrastructure handles authentication and transport security. Home Assistant's own authentication applies — users still need to log in. The connection is encrypted end-to-end for the application layer; Nabu Casa is the relay, not a data-inspection point for the application traffic.

Limits. Nabu Casa is the official path but not the only path. Operations with strong preferences for self-hosting (the collective's general lean) may prefer VPN or reverse proxy. Nabu Casa involves trusting a commercial service; for operations where that trust is acceptable, it is the simplest option. For operations where it is not, alternatives exist.

Cost. A few dollars per month at current pricing. Modest for what it provides; the cost question is usually not significant for established operations.

Recommendation. For operations that want simple, reliable remote access with minimum configuration overhead, Nabu Casa is the right starting point. It is explicitly recommended by the Home Assistant project. The collective does not endorse subscription services as a category, but acknowledging that Nabu Casa is a legitimate and often-best choice is consistent with practical guidance.

VPN options.

The self-hosted path.

WireGuard. A modern, performant, open-source VPN. Widely supported; runs on most platforms; configurations are small and understandable. The "gold standard" recommendation for VPN access in 2026.

Tailscale. A mesh VPN built on top of WireGuard that simplifies configuration. Uses a coordination server for peer discovery; the actual data traffic goes directly between peers. Zero-configuration for most use cases; free tier available for small deployments.

OpenVPN. An older VPN protocol, still widely used. More configuration overhead than WireGuard. Not typically the first choice for new setups but remains supported.

Which to pick for most operations. Tailscale is the easiest to set up and works well for agricultural operations. WireGuard is the right choice for operations that want full self-hosting without any third-party coordination. For most growers, Tailscale is a reasonable starting point; WireGuard is the upgrade path when full self-hosting matters.

VPN architecture for Home Assistant.

- Option A: VPN on the Home Assistant host. WireGuard or Tailscale runs directly on the Home Assistant host. Remote devices connect directly to the host. Simplest topology. - Option B: VPN on the router. Some routers support WireGuard or similar. Remote devices connect to the router, which gives access to the whole local network. Good for operations that want to access multiple devices remotely. - Option C: VPN on a dedicated device. A Raspberry Pi or similar running WireGuard/Tailscale as a dedicated VPN endpoint. Remote devices connect to the Pi; the Pi routes to Home Assistant. Works for operations with router hardware that cannot run VPN, or with multi-site topology.

What the VPN gives. Once connected, the remote device is on the local network. Home Assistant is accessible through its local URL — `https://homeassistant.local:8123` or whatever the local address is. The mobile app can be configured with the local URL; the VPN makes that URL reachable.

What the VPN costs. WireGuard itself is free and open-source. Tailscale has a free tier; paid tiers exist for larger deployments. The hardware (if any dedicated hardware is used) is the primary cost.

Security characteristics. A well-configured VPN is a strong security layer. Only clients with the correct key can connect; traffic is encrypted; the Home Assistant web interface is not exposed to the public internet. Device loss is the main concern — a laptop or phone with stored VPN credentials should be handled carefully, with credential revocation if the device is lost.

Reverse proxy.

The more complex but customizable path.

What a reverse proxy does. A web server on the public internet accepts connections, authenticates them, and forwards legitimate traffic to Home Assistant. The Home Assistant host itself is not directly reachable from the internet; the reverse proxy is the only public-facing component.

Common choices. Nginx (mature, widely used, substantial configuration options). Caddy (simpler configuration, automatic HTTPS, growing adoption). Traefik (container-focused, works well with Docker deployments). Each has its fit.

Why this path exists. Operations that want a custom domain (homeassistant.mygreenhouse.com), that want to combine Home Assistant remote access with other web services (Frigate web UI, Grafana dashboards), or that need specific integration patterns (external authentication providers, fine-grained access control) benefit from the flexibility of a reverse proxy. For simpler operations, Nabu Casa or VPN are easier and just as secure.

What hardening means here. A reverse proxy exposed to the internet is itself an attack surface. Default configurations are often not secure enough for public exposure. Hardening includes:

- HTTPS only, with strong TLS configuration. No HTTP access; enforce modern TLS versions; use strong cipher suites. - Rate limiting. Aggressive limits on connection attempts per IP to frustrate brute-force attacks. - Authentication in front of Home Assistant. Reverse proxy authentication (basic auth, OAuth, an identity provider) that must pass before traffic reaches Home Assistant. This is additional authentication on top of Home Assistant's own — defense in depth. - IP allowlists where possible. If remote access is needed only from specific locations (home, office, specific regions), restrict at the firewall or reverse proxy level. - Geographic blocking for regions with no legitimate need. Many attacks come from IP ranges in specific regions; blocking those regions reduces attack surface without affecting legitimate traffic. - Logging and monitoring. Access logs and alerting on unusual patterns. A sudden flood of failed login attempts is a sign of attack; the operation should know. - Regular patching. The reverse proxy software needs updates like any internet-facing service. Automated updates are typical.

The Caddy pattern. Caddy's simpler configuration makes it a common choice for home and small-operation reverse proxies. Automatic HTTPS (Caddy obtains and renews certificates from Let's Encrypt) removes a common source of configuration complexity. Still requires the hardening discipline above; Caddy's simplicity is about configuration, not about being secure out of the box.

When a reverse proxy fits. Operations with a technical grower or IT support, specific requirements (custom domains, multiple web services exposed together, integration with external auth), and comfort with ongoing security maintenance. For most agricultural operations, the simpler options (Nabu Casa or VPN) fit better.

Mobile app configuration.

How the app connects.

Home Assistant Companion app. The official Home Assistant mobile app for iOS and Android. Connects to Home Assistant for dashboard display, notifications, location sharing, and voice control.

Configuring for Nabu Casa. The app supports Nabu Casa remote access directly — signing into the Nabu Casa account in the app routes remote traffic through Nabu Casa automatically. Local connection is used when the phone is on the local network; remote connection is used when the phone is away.

Configuring for VPN. The app is configured with the local Home Assistant URL (`https://homeassistant.local:8123` or the IP-based equivalent). The VPN makes that URL reachable from anywhere the phone has the VPN connected. The app works without knowing about the VPN; the VPN just makes the local URL work remotely.

Configuring for reverse proxy. The app can be configured with the external URL through the reverse proxy. Behavior depends on the proxy configuration — whether the app's authentication flow works through the proxy's authentication layer.

Local-only fallback. Configuring both local and remote URLs lets the app use the local URL when on the local network and the remote URL otherwise. Faster and more reliable than always going through the remote path. Most remote-access configurations support this dual setup.

Notifications and push.

A specific aspect of remote access.

How push notifications work. Home Assistant sends notifications through the mobile app; the app receives them via Apple or Google's push notification services. The Home Assistant instance does not need to be directly reachable from the phone for notifications to work; the push goes through the platform's notification service.

What this means. Push notifications work independently of remote access method. A Home Assistant installation with no remote access at all still sends push notifications to the grower's phone — the phone does not need to reach Home Assistant for notifications to arrive.

Interactive notifications. Some notifications include action buttons — "Acknowledge," "Dismiss," "Run irrigation." These require the phone to reach Home Assistant when the button is tapped. That requires working remote access of some kind.

The design implication. For operations where the primary need is receiving alerts, push notifications alone (without full remote access) cover the need. The grower sees the alert on their phone without needing to log in. For operations where remote control matters, remote access is needed; Nabu Casa, VPN, or reverse proxy provides it.

Certificate management.

HTTPS for remote access.

Why HTTPS matters. Remote access traffic encrypted with HTTPS prevents interception. Without HTTPS, anyone on the network path (or snooping on the internet) can read the login credentials, the data being viewed, and the commands being issued. For remote access specifically, HTTPS is non-negotiable.

Let's Encrypt. A free certificate authority that issues TLS certificates automatically through standardized protocols. The default choice for home and small-operation HTTPS. Certificates auto-renew every 90 days.

Certificates with Nabu Casa. Nabu Casa handles certificates on its infrastructure; the grower does not need to configure anything certificate-related.

Certificates with reverse proxy. The reverse proxy handles the certificate. Caddy does this automatically; Nginx with certbot or similar also works. The specific configuration is proxy-specific.

Certificates with VPN. The VPN handles its own encryption; the Home Assistant web interface behind the VPN uses an internal certificate. For operations accessing Home Assistant over VPN, a self-signed certificate on Home Assistant is acceptable — the VPN already handles public-side encryption.

Certificate expiration monitoring. Certificates that expire unexpectedly break remote access. Monitor certificates and alert before expiration. Automatic renewal (Let's Encrypt, Caddy, certbot) makes this less of a concern; still worth confirming renewal happens as expected.

Network considerations.

The infrastructure remote access sits on top of.

Bandwidth. Remote access consumes upstream bandwidth from the operation's internet connection. Normal use is modest — a few kilobytes per second for dashboard viewing. Continuous camera streams (Frigate over VPN, for instance) use more. Operations with limited upstream bandwidth should consider what remote access will actually transfer.

Reliability of the internet connection. Remote access requires internet. An internet outage means no remote access; local access continues to work. For operations where remote access matters, internet reliability matters. A cellular backup for critical operations is sometimes worth the cost.

IPv4 versus IPv6. Some operations have IPv4-only internet (CGNAT — carrier-grade NAT — means no public IPv4 address is available). This prevents simple port forwarding or direct reverse proxy access. Nabu Casa and Tailscale handle this automatically; traditional WireGuard setup may need workarounds.

Firewall and router configuration. For any non-Nabu-Casa option, the router's configuration matters. The router should not expose Home Assistant directly. For VPN, the router may need to allow the VPN traffic. For reverse proxy, the router needs to forward the proxy's ports. The specific router configuration depends on the approach; all configurations should default to denying inbound traffic except what is explicitly needed.

What not to do.

The patterns that create real risk.

Don't port-forward Home Assistant directly to the internet. This is the anti-pattern. Exposing port 8123 (or whatever port) through the router to the public internet, with Home Assistant accessible directly, puts the installation under constant attack traffic. Even with a strong password, attacker persistence — bot networks trying millions of password attempts, known vulnerability exploits against specific Home Assistant versions, credential-stuffing attacks using leaked password databases — eventually finds a foothold. For an agricultural operation, a compromised Home Assistant can mean disabled irrigation, modified climate, or leaked operational data. The port forward approach is not a shortcut; it is a different and much worse security posture.

Don't rely on "security through obscurity." Using a non-standard port (8124 instead of 8123) or a subdomain that "nobody knows" does not provide meaningful protection. Internet scanning is automated and exhaustive; attackers do not need to guess.

Don't skip TLS. Remote access without HTTPS exposes credentials and data in transit. This is not negotiable; any remote access that does not encrypt traffic is unsafe.

Don't use weak passwords, default passwords, or shared passwords. Every user account has a strong, unique password. Administrator accounts have two-factor authentication. Passwords are not shared between staff; each person has their own account.

Don't enable remote access without monitoring it. Monitoring for unusual login patterns, failed authentication attempts, and access from unexpected locations catches attacks in progress. A Home Assistant with remote access but no monitoring is a blind spot.

Don't expose operational services (Frigate web UI, Grafana, InfluxDB) directly. Each service exposed is an additional attack surface. These services should be accessible through the same remote-access mechanism (Nabu Casa if it supports them, VPN, or the reverse proxy) — not through their own independent internet exposure.

Don't trust a reverse proxy config from the internet without review. Community reverse proxy configurations can contain security problems that are not obvious. Review before using; understand what each directive does; favor official documentation over unverified examples.

Don't skip firewall configuration. The router's firewall should default-deny inbound connections. Only the specific ports needed (VPN, reverse proxy) should be allowed. Everything else should be blocked.

Don't leave remote access enabled when it is no longer needed. If a specific user's access is no longer needed, their account should be disabled or removed. If an entire remote access method is no longer used, disable it. Unused remote access is unused attack surface.

Don't delay security updates for internet-facing components. The reverse proxy, the VPN, the router's firmware, Home Assistant itself — all get security updates that fix vulnerabilities attackers exploit. The longer an unpatched system stays exposed, the higher the risk. Updates for security-critical components should happen promptly, not when convenient.

Common failure modes.

Specific remote access problems from real deployments.

The direct port forward that was compromised. The grower enabled port forwarding to Home Assistant with "a strong password" and no other protection. Attacker brute-force succeeded (over months, with enough attempts); home automation was modified; the grower noticed when unexpected things started happening. Fix: Nabu Casa, VPN, or reverse proxy — direct port forwarding is not adequate protection.

The expired certificate that broke remote access. Let's Encrypt auto-renewal failed silently for a configuration reason; the certificate expired; remote access stopped working. Fix: monitor certificate expiration and alert in advance; verify auto-renewal is working through periodic log review.

The VPN key that was leaked. A laptop with a WireGuard configuration was lost; the attacker with the laptop could VPN in. Fix: revoke VPN keys immediately when devices are lost; consider using short-lived certificates for high-risk deployments; inventory the devices that have VPN access.

The reverse proxy that had a vulnerable module. A Nginx module had a CVE; the operation's deployment was vulnerable for weeks before being updated; luckily was not exploited during that window. Fix: track security advisories for the reverse proxy software; apply updates promptly.

The Nabu Casa outage that broke remote access. Nabu Casa had a multi-hour outage; remote access stopped. Local access continued to work. Fix: when critical remote access is a dependency, have a backup path; for most operations, the brief outage is acceptable.

The VPN that would not connect from some networks. Corporate or public WiFi networks sometimes block VPN protocols. The grower could not connect from a conference, from a customer's location, or from certain hotels. Fix: VPN options that use standard web-looking protocols (Tailscale's approach) work from more networks; Nabu Casa similarly uses standard HTTPS traffic.

The reverse proxy configuration that allowed too much. The proxy forwarded more than it should have — administrative endpoints, integration APIs that should have been internal-only, version strings that revealed vulnerabilities. Fix: restrict what the proxy forwards to the minimum necessary; test from outside to verify what is actually exposed.

The mobile app that stopped connecting after an IP change. The operation had a dynamic public IP that changed; the mobile app's remote URL no longer worked. Fix: dynamic DNS for dynamic IPs; or use a service like Nabu Casa that handles this automatically.

The notifications that stopped arriving. Notifications worked until a Home Assistant update or network change; then silently stopped. Some remote access configurations affect notification delivery subtly. Fix: test notifications after any network or remote-access change; monitor for notification delivery.

The operation compromise through an IoT device. The attack did not come through Home Assistant directly — it came through a vulnerable IoT device on the network that Home Assistant and the attacker could both reach. From there, the attacker reached Home Assistant. Fix: isolate IoT devices on a separate VLAN; apply security discipline to everything on the network, not just Home Assistant.