Ich habe Home Assistant diesen Monat auf eine eigene Maschine gelegt — eine kleine Cloud-VM, nichts davon zu Hause. Vorher wollte ich eine klare Antwort auf etwas, das die Dokumentation nicht gibt: Was braucht es eigentlich?
Geworden ist es eine Hetzner cx23. Zwei vCPU, 4 GB Arbeitsspeicher, 40 GB Platte, in Nürnberg, auf Ubuntu 24.04. Das sind 7,09 Euro netto im Monat. Home Assistant 2026.8.2 läuft im Container auf Docker 29.7.2, mit network_mode: host.
Was die Maschine ausliefert: ein Dashboard aus Bordmitteln, auf Demo-Sensoren.
Was es tatsächlich braucht
Mit gestopptem Container liegt die Maschine bei 611 MB. Das ist Ubuntu plus Docker-Daemon, sonst nichts. Zwei Minuten nach dem Start von Home Assistant sind es 960 MB, davon entfallen 339 MB auf den Container.
Der Wert wandert, deshalb gehört der Zeitpunkt daneben. Direkt nach dem Start sind es 850 MB. Nach 22 Stunden Laufzeit habe ich zwischen 969 und 985 MB gemessen. Wer eine Speicherzahl für Home Assistant nennt, sollte dazusagen, wann sie entstanden ist — alle drei stimmen.
Von docker compose up bis zum HTTP 200 auf Port 8123 vergingen 6,6 Sekunden, im Halbsekundentakt gemessen. Die Zahl schmeichelt der Software: Die Oberfläche antwortet, bevor die Integrationen fertig initialisiert sind. Sie markiert also den Moment, in dem der Webserver steht, nicht den, in dem das System bereit ist.
Das Image ist 625 MB groß. Nach dem Grundaufbau lag die Platte bei 5,4 von 38 verfügbaren GB, nach dem Anlegen einer 4-GB-Swapdatei bei 9,4 GB. Der Sprung ist die Swapdatei.
Zwei vCPU und 4 GB sind mehr, als eine Container-Installation ohne Add-ons heute braucht. Weniger würde ich trotzdem nicht nehmen, weil die Recorder-Datenbank stetig wächst und Swap auf einer 4-GB-Maschine verhindert, dass ein Update wegen Speichermangels abgeschossen wird.
Warum es nicht auf dem Kubernetes-Cluster läuft
Ich betreibe für anderes bereits ein Single-Node-k3s, also lag die Frage nahe, ob Home Assistant dorthin gehört. Ich habe die Maschine zuerst gemessen: 11,7 Prozent CPU als Grundlast über sieben Tage, bevor überhaupt eine eigene Arbeitslast läuft, dazu 1 bis 1,5 GB Speicher für die Control Plane im Leerlauf.
Entschieden hat es aber nicht der Overhead. Home Assistant braucht mDNS und Broadcast-Verkehr, um Geräte im Netz zu finden. Unter Docker ist das network_mode: host, eine Zeile. Das Kubernetes-Gegenstück heißt hostNetwork: true und gibt genau die Netzwerk-Isolation auf, die der Grund für Kubernetes gewesen wäre.
Eine Richtigstellung, weil sie oft auftaucht: „Docker in K3s" gibt es nicht. K3s fährt containerd, das Docker-Backend ist seit Längerem abgekündigt. Gleiches OCI-Image, andere Laufzeitumgebung darunter.
Was ein Standard-Setup offen lässt
Ich bin die Maschine am Tag nach dem cloud-init-Aufbau durchgegangen und habe vier Dinge gefunden, die eine Korrektur wert waren. Keines davon meldet sich von selbst, und genau deshalb stehen sie hier.
ufw war installiert und nie aktiviert. Das Paket stand in der cloud-init-Liste, und ohne ein ausdrückliches Aktivieren ist das Ergebnis eine Firewall im Zustand inactive. Solange die Provider-Firewall davor alles filtert, fällt das nicht auf. Relevant wird es in dem Moment, in dem für TLS die Ports 80 und 443 aufgehen.
sshd stand auf Passwort-Anmeldung, der Ubuntu-Standard. Root selbst ist ausschließlich per Schlüssel erreichbar, es lag also nichts offen — aber jeder später angelegte Benutzer hätte sich mit Passwort anmelden können.
Es gab keinen Swap auf einer 4-GB-Maschine, und die SSH-Freigabeliste enthielt genau eine Adresse: einen Heimanschluss, dessen IP rotiert. Genau so habe ich mich in einem anderen Projekt schon einmal ausgesperrt, deshalb kam eine feste zweite Adresse als Anker dazu.
Alle vier sind auf der laufenden Maschine behoben und in die cloud-init-Datei zurückgeschrieben, damit ein Neuaufbau sie nicht stillschweigend rückgängig macht.
Was eine Maschine im Rechenzentrum nicht kann
Das ist der Teil, den die meisten Beiträge über das Hosten von Home Assistant auslassen, und es ist das Erste, was du prüfen solltest, bevor du mein Setup übernimmst. Deine Geräte hängen im Heimnetz. Eine VM in Nürnberg nicht, und die mDNS-Erkennung endet am Router. Alles, was nur lokal spricht — Zigbee-Sticks, KNX, die meisten günstigen WLAN-Steckdosen — ist von dort nicht erreichbar.
Für diesen Aufbau ist das Absicht. Er bindet in der ersten Phase überhaupt kein Gerät an; er existiert, um sauber eingerichtet und fotografiert zu werden. Das Haus steuert weiterhin die alte Instanz, und die steht dort, wo sie die Hardware sieht.
Wer eine Cloud-Maschine und lokale Geräte will, braucht einen Tunnel nach Hause, und dann ist es der Netzwerkpfad, der um drei Uhr nachts ausfällt, und nicht der Server. Eine Maschine zu Hause vermeidet das vollständig. Dafür übernimmst du Verfügbarkeit, Sicherungen und Update-Disziplin selbst, die dir der Anbieter sonst abnimmt.
Was ich behalten würde
Die Container-Installation, aus dem Grund, dass sie unauffällig geblieben ist. Kein Supervisor, keine Add-ons, eine Compose-Datei, und ein Update ist ein geänderter Image-Tag. Aufgegeben habe ich damit das Add-on-Ökosystem, und auf einer Maschine, die nichts außer Home Assistant tut, habe ich es bisher nicht vermisst. Zwei Dinge, die hier oft verwechselt werden: Add-ons sind eine Supervisor-Funktion, und eine Container-Installation hat keinen — HACS dagegen läuft im Container und liefert Integrationen, Karten und Themes.
Wenn dich die Installation selbst interessiert und nicht die Wahl der Maschine, habe ich das für Docker auf einer Linux-VM getrennt aufgeschrieben. Und wenn es läuft, ist das Erste, was sich lohnt, ein Backup über den ganzen Host, nicht nur über den Config-Ordner.
