Home Assistant entfaltet seinen Nutzen erst dann richtig, wenn man ihn auch von unterwegs erreicht. Heizung vor der Rückkehr hochdrehen, im Urlaub nach der Kamera schauen, der Familie das Garagentor freigeben. Der Weg dorthin entscheidet allerdings darüber, ob die eigene Haussteuerung ein privates System bleibt oder als offener Dienst im Internet steht.
Die eine Regel, die alles andere überlagert
Home Assistant gehört nicht per Portweiterleitung ins offene Netz. Wer im Router den Port 8123 nach außen durchreicht, hat innerhalb weniger Stunden die ersten automatisierten Scanner auf der Instanz. Das Problem ist dabei weniger das Passwort als die dauerhafte Angreifbarkeit: Jede Sicherheitslücke, die irgendwann in Home Assistant oder einer Bibliothek darin auftaucht, trifft ein System, das rund um die Uhr erreichbar ist. Zwischen Bekanntwerden einer Lücke und dem eigenen Update liegen im Zweifel Tage.
Alle folgenden Wege haben eines gemeinsam: Sie kommen ohne offenen eingehenden Port aus oder schieben zumindest eine gehärtete Schicht davor.
Weg 1: Home Assistant Cloud
Die offizielle Lösung von Nabu Casa ist der bequemste Einstieg. Nach der Anmeldung baut die Instanz eine ausgehende Verbindung auf und ist danach über eine persönliche Adresse mit gültigem Zertifikat erreichbar. Am Router wird nichts geändert, um Zertifikate kümmert sich niemand.
Kosten: 7,50 Euro im Monat oder 75 Euro im Jahr inklusive Mehrwertsteuer, in den USA 6,50 US-Dollar monatlich. Eine Testphase gibt es.
Im Preis stecken neben dem Fernzugriff die Sprachassistenten mit Text-to-Speech, die Anbindung von Alexa und Google Assistant sowie 5 GB Speicher für Backups. Ein Teil des Geldes fließt in die Entwicklung von Home Assistant, ESPHome und Z-Wave JS, was für ein Open-Source-Projekt dieser Größe kein unwichtiges Argument ist.
Geeignet für alle, die eine Lösung wollen, die funktioniert, ohne dass man sich mit Netzwerktechnik befasst. Der Nachteil liegt auf der Hand: laufende Kosten und ein Anbieter, über dessen Infrastruktur der Zugriff läuft.
Weg 2: Tailscale oder ein anderes VPN
Ein VPN dreht die Logik um. Statt Home Assistant öffentlich zu machen, holt man das Handy ins Heimnetz. Home Assistant bleibt aus dem Internet vollständig unsichtbar.
Tailscale hat sich hier als Standardempfehlung durchgesetzt, weil es die Schlüsselverwaltung von WireGuard abnimmt. Es gibt ein offizielles Add-on, die Einrichtung besteht im Wesentlichen aus einer Anmeldung auf beiden Seiten. Danach verhält sich das Handy so, als hinge es am heimischen WLAN, und zwar unabhängig davon, ob der Router eine öffentliche IPv4-Adresse hat.
Wer lieber ohne fremden Koordinationsdienst arbeitet, richtet WireGuard direkt auf dem Router oder als Add-on ein. Das ist ein Stück Arbeit mehr und braucht in der Regel eine Portfreigabe für den VPN-Dienst selbst, aber der Dienst dahinter ist deutlich kleiner und besser überprüfbar als eine komplette Webanwendung.
Der Haken beim VPN ist die Alltagstauglichkeit für Mitbewohner. Auf jedem Gerät muss eine App laufen und aktiv sein. Für die eigene Nutzung ist das kaum spürbar, für den Besuch, der kurz das Licht schalten soll, taugt es nicht.
Weg 3: Cloudflare Tunnel
Ein Cloudflare Tunnel liegt zwischen den beiden Welten. Auf dem Home-Assistant-Rechner läuft ein kleiner Dienst namens cloudflared, der von innen nach außen eine Verbindung zu Cloudflare aufbaut. Der Router bleibt dicht, die eigene IP-Adresse taucht nirgends auf, und die Instanz ist trotzdem unter der eigenen Domain mit gültigem HTTPS erreichbar.
Das ist attraktiv, wenn Dashboards für Menschen erreichbar sein sollen, die keine VPN-App installieren wollen. Voraussetzung ist eine eigene Domain, die über Cloudflare verwaltet wird.
Ohne zusätzliche Absicherung landet damit allerdings wieder eine Login-Maske im Internet. Deshalb gehört Cloudflare Access davor, das die Anmeldung vorschaltet, bevor überhaupt ein Paket bei Home Assistant ankommt.
Und hier lauert die Stolperfalle, die in vielen Anleitungen fehlt: Die Companion-App und eingehende Webhooks können keine interaktive Anmeldung durchlaufen. Wer beides nutzen will, muss entweder bestimmte Pfade über Service-Token von Access ausnehmen oder die App über ein VPN laufen lassen und den Tunnel nur für den Browserzugriff verwenden.
Weg 4: Eigener Reverse Proxy
Der klassische Selbermacher-Weg führt über einen Reverse Proxy wie NGINX oder Caddy, eine dynamische DNS-Adresse und ein Zertifikat von Let’s Encrypt. Für Home Assistant OS gibt es dafür fertige Add-ons, unter anderem die Kombination aus DuckDNS und Let’s Encrypt.
Das bringt volle Kontrolle und keine laufenden Kosten. Es bedeutet aber auch, dass eine Portfreigabe für 443 offen ist und man selbst dafür verantwortlich ist, den Proxy aktuell zu halten. Wer diesen Weg geht, sollte den Proxy zusätzlich absichern, etwa über eine Beschränkung auf bestimmte Herkunftsländer, Fail2ban oder eine vorgeschaltete Anmeldung.
Wichtig ist außerdem die richtige Einstellung in Home Assistant selbst, sonst sieht die Instanz bei jedem Zugriff nur die Adresse des Proxys. Dazu gleich mehr.
Neu ab 2026.8: die Netzwerkeinstellungen in der Oberfläche
Bis Version 2026.7 wurden diese Dinge in der configuration.yaml unter http: eingetragen. Seit 2026.8 liegen sie unter Einstellungen > System > Netzwerk, und eine vorhandene YAML-Konfiguration wird beim ersten Start automatisch übernommen.
Dort finden sich unter anderem:
- Server-Port, standardmäßig 80 bei Home Assistant OS und 8123 bei einer Container-Installation
- Pfade zu SSL-Zertifikat und Schlüssel, falls Home Assistant selbst HTTPS ausliefern soll
- IP-Sperren aktivieren und Anmeldeversuche vor Sperre, der Wert -1 schaltet die Sperre ab
- X-Forwarded-For vertrauen und Vertrauenswürdige Proxys für den Betrieb hinter einem Reverse Proxy
Beim Ändern von Port oder Netzwerkeinstellungen greift ein Sicherheitsnetz: Wird die neue Konfiguration nicht innerhalb von fünf Minuten bestätigt, stellt Home Assistant den alten Zustand wieder her.
Die zwei Einstellungen, die man hinter einem Proxy braucht
Läuft Home Assistant hinter einem Reverse Proxy, kommt jede Anfrage scheinbar von diesem Proxy. Die IP-Sperre wäre damit wirkungslos, weil bei zu vielen Fehlversuchen der Proxy selbst gesperrt würde und danach niemand mehr hineinkäme.
Deshalb aktiviert man X-Forwarded-For vertrauen und trägt unter Vertrauenswürdige Proxys die Adresse des Proxys ein. Bei einem Netzbereich muss die Netzadresse stehen, also 192.168.1.0/24 und nicht die Adresse eines einzelnen Hosts.
Die Reihenfolge ist sicherheitsrelevant. Wer X-Forwarded-For vertraut, ohne die vertrauenswürdigen Proxys sauber einzugrenzen, erlaubt jedem Absender, sich eine beliebige Herkunfts-IP anzudichten und die Sperrmechanik damit auszuhebeln.
Bei Home Assistant Cloud sind beide Optionen ohne Wirkung, weil Anfragen dort über den Tunnel als 127.0.0.1 ankommen.
Die Grundabsicherung gilt in jedem Fall
Unabhängig vom gewählten Weg gibt es eine Handvoll Dinge, die immer stimmen sollten:
- Mehrstufige Anmeldung aktivieren. Home Assistant unterstützt TOTP-Apps. Bei einem aus dem Internet erreichbaren System ist das keine Kür.
- Ein eigenes, langes Passwort pro Konto, verwaltet in einem Passwortmanager.
- Administratorrechte sparsam vergeben. Der Haushalt braucht Zugriff auf Dashboards, keine Rechte auf die Systemebene. Für Kinder oder Gäste bieten sich Konten ohne Adminrechte an.
- Updates zeitnah einspielen. Jede monatliche Version enthält auch Korrekturen an Bibliotheken unterhalb der Oberfläche.
- IP-Sperre einschalten, typischerweise nach fünf Fehlversuchen. Gesperrte Adressen landen in der Datei
ip_bans.yamlund lassen sich dort wieder entfernen. - Smart-Home-Geräte in ein eigenes Netz. Viele Billiggeräte bekommen nie wieder ein Update. Ein getrenntes VLAN oder wenigstens ein Gäste-WLAN begrenzt den Schaden, wenn eines davon übernommen wird.
Welcher Weg passt
Für die meisten Haushalte ist die Entscheidung schnell getroffen. Wer eine Lösung will, die einfach läuft, und dem Projekt nebenbei etwas zurückgeben möchte, nimmt Home Assistant Cloud. Wer ausschließlich selbst zugreift und technisch nichts dagegen hat, fährt mit Tailscale sehr sicher und kostenlos.
Der Cloudflare Tunnel lohnt sich, wenn mehrere Personen ohne VPN-App zugreifen sollen und eine eigene Domain vorhanden ist. Der eigene Reverse Proxy bleibt die Wahl für alle, die die volle Kontrolle wollen und bereit sind, die Wartung dauerhaft zu übernehmen.
Was in keinem Szenario eine Option ist: den Port des Webinterfaces ohne Schutzschicht im Router freigeben. Alles andere ist eine Frage von Bequemlichkeit gegen Aufwand.