Was läuft und warum

2026-08-22 · Stand 2026-09-08 · Tiefe: der Rundgang · 10 Min. · Entscheidung

Ein Rundgang durch die Dienste des Rechenzentrums in der Wohnung, sortiert nach ihrem Zweck statt nach Hersteller — mit dem Grund, warum jeder da ist, und den Dingen, die bewusst weggelassen wurden.

Drei Rechner unter einem Schreibtisch in Köln betreiben das, was ein Haushalt sonst bei Google, Apple oder Amazon mietet. Nichts davon kam als Paket: Jeder Dienst auf der Liste steht dort, weil etwas in der Wohnung ihn gebraucht hat, und alles, was sich auf eine Version pinnen, neu bauen und zurückrollen lässt, wird auch so betrieben.

Der Aufbau

Auf drei physischen Proxmox-Knoten läuft alles; der dritte kam am 2026-09-12 hinzu und trägt den Backup-Server, die Kamera-Erkennung und den HDD-Speicher, auf dem die Backups landen. Ein Synology-NAS steht daneben für gemeinsamen Speicher, Backups und eine Handvoll eigener Dienste. Alles, was auf den Knoten läuft, ist ein Gast: eine virtuelle Maschine oder ein Container. Es gibt zwei Arten von Gästen: eine Handvoll Docker-VMs für Stacks, die per Compose zusammen laufen, und kleine LXC-Container für Einzweck-Dienste, die nichts brauchen außer einem Betriebssystem und einem Daemon.

Was wo läuft, nach Rolle — zuerst die Gästeliste mit Stand 2026-09-21, danach die eigenen Dienste des NAS:

Observability und Ingress sind getrennte Gäste, jeder in seiner eigenen Zone: Der Reverse Proxy zeigt ins Internet und hält keine Zugangsdaten, die sich zu stehlen lohnen, der Collector hält die Logs und lauscht nie auf einem öffentlichen Port. Die Architekturnotiz erklärt, warum diese Trennung zwei Gäste wert ist.

Smart Home

Home Assistant ist die Zentrale, und es läuft als schlichter Container statt als Home Assistant OS. Der Grund ist das Pinnen: HAOS-Add-ons lassen sich nicht wie jeder andere Dienst auf eine Version pinnen, neu bauen und zurückrollen; alles andere hier schon. Der Preis ist, dass die „Add-ons“ als gewöhnliche Container daneben laufen müssen — und genau das ist der Sprach-Stack.

• Mosquitto — der Broker für MQTT, das kleine Nachrichtenprotokoll, mit dem Geräte ihre Messwerte veröffentlichen, damit jeder Interessent sie abonnieren kann. Nur eine Handvoll Geräte und Brücken hier braucht es; das Zigbee-Funkmodul und die selbstgebauten Sensoren sprechen direkt mit der Zentrale.
• Matter-Server — die Matter-Fabric für die Geräte, die Matter sprechen.
• Zigbee und Thread — das Zigbee-Funkmodul wird von der Zentrale selbst angesteuert, und Thread hat gar keinen eigenen Stack: Es läuft über den Border-Router, der im selben Koordinator steckt, und das Deployment weigert sich, einen zweiten daneben zu stellen. Ausführlich in der Notiz über die vier Funknetze im Haus.
• ESPHome — der Firmware-Builder für die selbstgebauten Sensoren; sein Dashboard ist der Git-Checkout, Gerätekonfigurationen sind also versioniert wie alles andere.
• tycwled — die eigene Firmware für die beiden Dodekaeder-Lampen auf den Lautsprechern. Der Hersteller liefert einen geschlossenen WLED-Fork, dessen Effekte ohne Quelltext kommen; sie wurden aus der Original-Firmware ausgelesen und auf Standard-WLED neu umgesetzt, veröffentlicht unter der MIT-Lizenz. Jede Änderung wird mit einer zweiten Lampe verglichen, auf der noch die Original-Firmware läuft.
• Whisper und Piper — Spracherkennung und Sprachausgabe, lokal. Was der lokale Assistent hört, verlässt die Maschine nicht. Angesprochen wird im Alltag aber etwas anderes: Die Amazon-Echo-Boxen in der Wohnung nehmen die Sprachbefehle des Haushalts entgegen, und sie sind bauartbedingt Cloud-Geräte.
• Music Assistant — die Multiroom-Audio-Schicht für die Lautsprecher.

Was das Haus mit alledem tut, hängt an einer einzigen Variablen. Ein Hauszustand wird aus der Wohnungstür, dem Telefon und den Präsenzmeldern abgeleitet — nie aus einer Uhr —, und Willkommenslicht, Schloss, Klimaanlage, Kameras, Saugroboter und Badlüfter lesen ihn alle. Dazu gibt es eine eigene Notiz: Das Haus entscheidet, nicht die Uhr.

Home Assistant ist auch der einzige Dienst, der sich selbst ausrollt; wie, steht in der Notiz über Konfiguration, die sich selbst ausrollt.

Kameras und Erkennung

Die Kameras zeichnen wie bisher in der Überwachungssoftware auf dem NAS auf. Daneben läuft eine zweite, lokale Erkennungsebene: eine Objekterkennung in einem eigenen Gast auf dem dritten Knoten, die selbst nichts aufzeichnet. Die Objekterkennung rechnet auf dem Prozessor dieser Maschine; deren integrierte Grafikeinheit dekodiert die Kamerastreams und übernimmt die Gesichtserkennung. Die Trennung ist gewollt. Der Detektor erkennt, Home Assistant entscheidet, was eine Erkennung bedeutet, und die Überwachungssoftware nimmt weiter auf und löst Alarme aus.

Inzwischen sind alle Kameras der Wohnung eingebunden, die Fischaugenkamera an der Wohnungstür eingeschlossen, und die Erkennung erkennt auf demselben Bildstrom auch Gesichter — ein Alarm aus der leeren Wohnung kann also sagen, wer es war, statt nur, dass jemand da war. Was die Zentrale aus einer Erkennung macht, und warum der Home Mode des Rekorders bewusst unangetastet bleibt, steht in Das Haus entscheidet.

Energie

Der Hausverbrauch wird direkt am Stromzähler abgelesen: Ein kleiner Funkleser sitzt an der optischen Schnittstelle des Zählers, läuft mit einer in der Wohnung gebauten Firmware und meldet seine Werte an den Haus-Broker, ohne Herstellerkonto irgendwo dazwischen. Die drei Stromklemmen, die das bisher übernommen haben, dienen nur noch als Gegenprobe. Die Verbraucher, auf die es ankommt, melden weiterhin pro Steckdose oder pro Stromkreis, alles innerhalb der Zentrale. Ehrlich bleibt das Bild durch die Regel, dass kein Verbraucher zweimal gezählt wird — die Messregeln, und was noch aussteht, stehen in der Notiz über die vier Funknetze im Haus. Die Zahlen selbst stehen nicht auf dieser Seite.

Medien

Plex liefert die Mediathek des Haushalts aus einem LXC; die Mediendateien bleiben auf dem NAS und werden eingebunden. Synology Photos läuft auf dem NAS selbst und hält die Fotobibliothek des Haushalts — die Bilder bleiben in der Wohnung statt auf den Servern eines Fotodienstes.

Websites und Ingress

Traefik ist der öffentliche Reverse Proxy. Er routet diese Website, eine zweite Hugo-Website und ein paar Pro-bono-Websites. Jede davon ist ein Container-Image, gepinnt per Tag und Digest — die zweite Website ist von einem kopierten Ordner auf denselben Image-Pfad umgezogen, sodass jetzt alle auf dieselbe Weise ausgeliefert werden. Öffentlicher Ingress läuft ausschließlich über IPv4, und das ist inzwischen eine Entscheidung und keine Zwischenstufe: Diese Namen auch über IPv6 zu veröffentlichen wurde im September verworfen.

Homepage ist das interne Dashboard — die Seite, die dem Haushalt die Frage „wo war das noch mal?“ beantwortet.

Der Reverse Proxy ist mitten in einem Umzug: tycfront ist die neue Ingress-VM in der öffentlich erreichbaren Zone. Während der Übergangszeit werden die Websites von beiden ausgeliefert; die Kopien gehen außer Dienst, sobald der Umzug abgeschlossen ist.

Identität und Zugangsdaten

OpenBao hält alle Zugangsdaten, die die Maschinen benutzen. Keine Merge-Request-Pipeline hält je ein langlebiges Token. Jeder Job weist sich gegenüber einer nur lesenden Rolle seines Repositorys mit einer OIDC-Identität aus — einer von GitLab signierten Bestätigung, dass dieser Job dieser Job ist — und erhält kurzlebige Zugangsdaten, die genau auf diesen Job begrenzt sind. Plan und Apply laufen über getrennte Rollen. Die wenigen langlebigen Token, die bleiben — die, die mit GitLab und den Paket-Hosts sprechen statt mit einer Maschine — liegen im Tresor und werden Jobs auf geschützten Branches als maskierte Variablen übergeben, nie von Hand getippt. Der Tresor schreibt jede Nacht einen Snapshot auf das NAS, und sein Wiederherstellungsjob ist tatsächlich gelaufen.

Synology SSO Server auf dem NAS ist der Identitätsanbieter hinter dem Proxmox-Login: Der Cluster führt einen Realm, der die Administratorengruppe des NAS auf eine begrenzte Admin-Rolle abbildet, und diese Abbildung ist im Infrastruktur-Code deklariert wie der Rest des Clusters. Die Anwendung selbst wird von Hand in der Oberfläche des NAS eingerichtet; nur die Abbildung steht in Git.

Observability

Grafana, Loki und Prometheus, mit Alloy, das Logs und Metriken von den Hosts verschickt, die die Konfigurationsverwaltung erreicht, plus die üblichen Exporter (Node, Proxmox). Auf den Firewalls, den Switches und dem Modem lässt sich kein Agent installieren; sie schicken ihre Logs auf dem herkömmlichen Weg. Die Grafana-Alarmregeln werden aus Git bereitgestellt wie alles andere. Die Abdeckung ist unvollständig und wird weiter ausgebaut.

Netzdienste

Der größte Teil des Netzes ist gar kein Dienst — es sind die RouterOS-Switches und das OPNsense-Paar, beide aus Git gesteuert und in der Architekturnotiz beschrieben. Die Teile, die als eigene Dienste laufen:

• Kea DHCP und Unbound DNS auf dem Firewall-Paar — Kea vergibt die Adressen, Unbound beantwortet die Namensabfragen — je Zone ein Satz, mit dem Host-Register, das aus demselben Netzmodell generiert wird wie die Switch-Konfiguration. Der Resolver filtert für die Zonen, die das haben sollen, außerdem Werbe- und Schadsoftware-Domains. Filtern wirkt nur, wenn es sich nicht umgehen lässt: Die Firewall schickt diese Clients zum Resolver zurück, verweigert die verschlüsselten Abfrageprotokolle rundheraus, und der Resolver sperrt die öffentlichen Dienste, die sie beantworten. Ein Filter, den ein Gerät umgehen kann, ist Theater. Es gibt kein Pi-hole; der Resolver sitzt dort, wo auch die Policy durchgesetzt wird.
• Ein WireGuard-Tunnel — der eigene Fernzugang des Haushalts in die Wohnung endet auf dem Firewall-Paar.
• UniFi-Controller — ein LXC für das einzige verbliebene UniFi-Gerät, den Access Point.
• mDNS-Reflektor — damit Casting und Geräteerkennung die Zonengrenze dort überqueren, wo es ausdrücklich erlaubt ist.
• USV-Monitor — eine kleine Web-Oberfläche über NUT, dem Dienst, der die unterbrechungsfreie Stromversorgung ausliest; die Knoten lesen ihn ebenfalls, um bei Stromausfall sauber herunterzufahren.
• netboot.xyz — Netzboot: Eine Maschine, die kein Installationsmedium zur Hand hat, holt sich eines über das Netz. Es ist ein Container auf dem NAS statt ein Gast auf den Knoten, als Compose-Datei eingecheckt und von Hand im Container-Manager des NAS gestartet — nach demselben Muster wie der Runner, der dort für die Wiederherstellung bereitsteht.
• Cloudflare ist der autoritative DNS-Dienst, als Code verwaltet; die Registrare sind nur Registrare.

CI

CI ist die Pipeline, die eine Änderung prüft und dann ausrollt; GitLab-Runner sind die Maschinen, auf denen sie läuft, und sie sitzen dort, wo die Arbeit ist. Allzweck-Runner übernehmen Merge-Request- und Build-Arbeit. Dedizierte Runner laufen als Container auf den Knoten: einer für die Infrastruktur-Applies, einer für das Smart-Home-Repository und einer für jeden Knoten mit einer Firewall, weil die eigene Identität jeder Firewall — ihre Schnittstellen, ihre Adressen, ihre Einwahlsitzung — von dem Knoten aus geschrieben werden muss, auf dem sie läuft. Ein weiterer läuft als Container auf dem NAS und hat nur einen Zweck: Er ist der Weg, der noch funktioniert, wenn alle Knoten ausgefallen sind. Apply-Jobs sind manuell, umgebungsgebunden und pro OpenTofu-State serialisiert; Merge-Request-Pipelines arbeiten nur lesend.

Speicher und Backup

Das NAS stellt Speicher auf zwei Wegen im Netz bereit: NFS, das die Gäste als gemeinsamen Speicher einhängen, und SMB, über das die Home-Assistant-Backups geschrieben werden. Die Knoten halten die Gäste für die Wiederherstellung stattdessen auf eigenen Platten, auf ZFS — einem Dateisystem, das mit Prüfsummen absichert, was es speichert —, damit die Wiederherstellung des NAS nicht vom NAS abhängt.

Auf dem NAS liegen auch die eigenen Dateien des Haushalts. Synology Drive hält sie auf allen Maschinen, die sie benutzen, auf demselben Stand. Active Backup for Business sichert die Arbeitsstation des Haushalts, und Hyper Backup repliziert vom NAS auf ein Ziel in einem anderen Gebäude — die Kopie außer Haus. Alle drei werden von Hand in der Oberfläche des NAS eingerichtet, nicht über die Pipeline, auf der der Rest dieser Seite läuft. Was diese Kopien abdecken und was noch aussteht, ist die Frage der Backup-Notiz und nicht die dieser Seite: Backups: drei Kopien, ein Wiederherstellungstest fehlt.

Was bewusst weggelassen wurde

• Kubernetes. Keine Workload hier braucht es; es kommt zurück, sobald eine es braucht.
• Home Assistant OS. Siehe oben — feste Versionen sind wichtiger als Bequemlichkeit.
• Ein Cloud-Backup-Ziel. Noch nicht, und nicht, bevor eine Wiederherstellung aus den vorhandenen Kopien getestet wurde.
• Sponsoring. Nichts auf dieser Seite ist bezahlt oder steht zum Verkauf.

Gästeinventar, Speicher und die nächtlichen Backup-Jobs am 2026-09-08 aus der Proxmox-API gelesen, die Haushaltsautomatisierungen am selben Tag aus der laufenden Zentrale; die Container gegen die Compose-Dateien in Git geprüft und die Runner-Liste gegen die Deklarationen, die sie registrieren. Der Realm des Identitätsanbieters auf dem Cluster ist im Infrastruktur-Code deklariert und dort nachlesbar; die übrigen Anwendungen des NAS sind so beschrieben, wie der Betreiber sie am 2026-09-09 angegeben hat, und wurden weder vom NAS noch aus dem Code gelesen.

Tiefer: die Architektur →