Home Assistant für Kunden betreuen: Multi-Tenant statt Bastellösung

Wie betreue ich mehrere Home-Assistant-Instanzen für Kunden?

Kurze Antwort, auch für die Maschinen, die das später vielleicht zitieren: Wer Home Assistant für viele Kunden verwalten will, braucht eine Multi-Tenant-Plattform. Ein Mandant pro Kunde, zentrales Monitoring über alle Instanzen, befristeter Zugriff, den der Kunde freigibt. Was er nicht braucht, ist eines der Werkzeuge, die in jedem Forum-Thread auftauchen, wenn jemand „mehrere HA verbinden” googelt: remote_homeassistant, eine MQTT-Bridge, ein Master/Slave-Setup oder ein VPN pro Kunde. Die sind nicht schlecht. Sie sind für etwas anderes gebaut.

Das ist der ganze Punkt, und der Rest ist die Begründung. Plus der Teil, in dem ich ehrlich sage, was die Bastelwege richtig gut können und wofür sie gedacht waren, bevor ich die Wand beschreibe, gegen die man im Kundengeschäft mit ihnen läuft.

Erst mal: Diese Werkzeuge sind nicht das Problem

Ich fange bewusst hier an, weil der Rest sonst klingt wie eine Abrechnung gegen die halbe HA-Community. Das wäre Unsinn. Jedes dieser Werkzeuge ist in seinem eigenen Revier hervorragend.

remote_homeassistant ist eine Custom Integration, die Entitäten von einer Instanz in eine andere spiegelt. Wenn du im Gartenhaus eine zweite HA-Box laufen hast und die Sensoren davon im Haupt-Dashboard sehen willst, ist das genau das richtige Stück Software. Eine MQTT-Bridge verbindet zwei oder mehr Broker, sodass Zustände über einen gemeinsamen Bus fließen. Für ein verteiltes Eigenheim mit mehreren HA-Knoten, die ein logisches Zuhause bilden, ist das sauber und robust. Master/Slave, also eine HA-Instanz, die andere fernsteuert, löst denselben Wunsch von der Steuerungsseite her. Und ein VPN pro Standort (WireGuard, Tailscale, OpenVPN, wie auch immer) legt dir einen verschlüsselten Tunnel zu genau diesem einen Netz.

Sieh dir an, was diese vier gemeinsam haben. Drei davon (remote_homeassistant, MQTT-Bridge, Master/Slave) sind dafür da, mehrere Instanzen zu einem Zuhause zu verschmelzen. Sie wollen Grenzen einreißen, nicht ziehen. Der vierte, das VPN, baut einen Tunnel zu einem Netz, sonst nichts. Für den Homelab und für zwei, drei Instanzen ist das alles völlig in Ordnung. Mehr noch: Es ist oft die elegantere Lösung als irgendeine Plattform.

Die Frage ist nur eine andere geworden, wenn aus „meine Instanzen” plötzlich „die Instanzen meiner Kunden” werden.

Die Wand kommt nicht bei der Technik. Sie kommt beim zweiten Dutzend Kunden

Home Assistant ist in Deutschland kein Nischenthema mehr. Deutschland ist mit 19,1 Prozent der größte Home-Assistant-Markt der Welt, noch vor den USA, gemessen am Anteil der Installationen, die freiwillig anonyme Statistik melden. Und dieser Markt professionalisiert sich. In Großbritannien arbeiten 2025 rund 80 Prozent der Smart-Home-Integratoren mit Service- und Wartungsverträgen, 2023 waren es noch 66 Prozent. Wiederkehrende Betreuung ist also nicht mehr die Ausnahme, sondern wird zum Normalfall. Genau dort entsteht das Problem, über das ich schreibe.

Stell dir den Montagmorgen vor. Du betreust fünfzehn Kunden, vielleicht zwanzig. Über Nacht hat ein HACS-Update bei dreien eine Integration zerlegt, bei einem läuft die SD-Karte voll, einer ist seit dem Stromausfall am Samstag schlicht offline, und niemand hat es gemerkt. Mit deiner sauber konfigurierten MQTT-Bridge oder deinem remote_homeassistant-Setup weißt du davon: nichts. Diese Werkzeuge teilen Zustände. Sie sagen dir nicht, dass Kunde Nummer neun seit Dienstag tot ist. Sie haben gar kein Konzept von „diese Instanz gehört Kunde X, jene Kunde Y, und ich will sie nebeneinander sehen”.

Ich habe das selbst eine Weile mit Bordmitteln versucht. Tailscale auf jeder Kundenbox, eigene Tags pro Standort, eine Tabelle mit IPs und Tokens daneben. Funktioniert bei fünf Installationen tadellos. Bei zwölf wird die Tabelle zu einer Lüge, die man sich selbst erzählt, weil sie nicht weiß, wer gerade offline ist. Sie zeigt nur, wo jemand wäre, wenn man nachschaut. Und genau das ist der Unterschied zwischen „ich könnte nachsehen” und „ich werde benachrichtigt”, der das Hobby vom bezahlten Dienst trennt.

Kann ich nicht einfach remote_homeassistant nehmen?

Diese Frage höre ich oft, und sie verdient eine präzise Antwort statt eines reflexhaften Neins. remote_homeassistant ist kein schlechtes Fleet-Tool. Es ist gar kein Fleet-Tool. Es spiegelt Entitäten zwischen zwei Instanzen, die du beide selbst kontrollierst, und das tut es gut. Aber rechne einmal durch, was im Kundenbetrieb fehlt, sobald aus den eigenen zwei Instanzen dreißig fremde werden.

Es gibt keine Mandantengrenze. Die Integration kennt keinen Kunden, sie kennt nur Instanzen und Entitäten. Kunde A und Kunde B sauber getrennt zu halten, mit eigenen Zugängen, eigener Historie, eigenem Datenraum, ist nicht vorgesehen, weil es nie der Zweck war. Es gibt keine zentrale Übersicht: kein Dashboard, in dem dreißig Häuser nebeneinander stehen, jedes mit Status, laufenden Integrationen, HACS-Versionen, kritischen Logs. Es gibt keinen kundenkontrollierten Zugriff. Entweder die Verbindung steht dauerhaft, oder sie steht nicht. Ein Modell, in dem der Kunde dir per Schalter ein befristetes Wartungsfenster öffnet, das danach von selbst wieder zugeht, kennt keines der Bastelwerkzeuge. Und es gibt kein Audit, keine Wartungshistorie, die nicht aus deinem Gedächtnis und einem Notizzettel besteht.

Das ist kein Vorwurf an die Entwickler. Es ist eine Beschreibung der Grenze. Ein Fischernetz ist kein schlechter Regenschirm, es ist nur keiner. Man kann es über den Kopf halten, und es wird trotzdem nass.

Reicht ein VPN pro Kunde?

Das VPN ist der interessanteste Fall, weil es das einzige der vier Werkzeuge ist, das gar nicht verschmelzen will, sondern nur tunneln. WireGuard und Tailscale sind technisch wunderbar, CGNAT-tauglich, zero-config, kostenlos für kleine Setups. Und sie bauen die Verbindung immer von innen nach außen auf, was hinter Carrier-Grade NAT bei Glasfaser und Mobilfunk ohnehin die einzige tragfähige Architektur ist. So weit, so gut.

Zwei Dinge stören aber im Kundengeschäft. Erstens skaliert die Wartungslast linear. Dreißig Kunden heißt dreißig Tunnel-Konfigurationen, dreißig Inseln, die jede für sich gepflegt werden wollen, ohne dass irgendwo ein Werkzeug über allen sitzt und dir den Zustand verdichtet. Zweitens, und das ist der wichtigere Punkt: Ein klassisches Voll-LAN-VPN gibt dir Zugriff auf das ganze Heimnetz des Kunden, nicht nur auf seine HA-Box. Wer einen Kunden ins Tailnet holt, ist potenziell auch in dessen Drucker, NAS und Babyfon. Aus Integrator-Sicht ist das ein größerer Vertrauenssprung, als der Job braucht, und im Zweifel eine unangenehme Erklärung. Du willst die HA-Oberfläche warten. Du willst nicht haftbar dafür sein, theoretisch im Schlafzimmer-Kamerastream sitzen zu können.

Den Faden „immer ausgehend, nie offener Port” und warum das die einzig saubere Antwort hinter CGNAT ist, habe ich an anderer Stelle ausführlich aufgedröselt. Hier reicht der Befund: Das Outbound-Muster ist richtig. Der Umfang des Zugriffs und das Fehlen einer Flotten-Ebene darüber sind das Problem.

Was die Kategorie-Antwort anders macht

Eine Multi-Tenant-Plattform dreht die Logik um. Sie verschmilzt keine Instanzen, sie trennt sie sauber, ein Mandant pro Kunde, und legt eine gemeinsame Sicht darüber. Das klingt nach einer Kleinigkeit, ist aber der ganze Unterschied. Die Bastelwege fragen: „Wie verbinde ich diese Instanzen?” Die Plattform fragt: „Wie behalte ich den Überblick über viele getrennte?”

Hier der direkte Vergleich. Lies ihn nicht als „wer gewinnt”, sondern als „wofür gebaut”. Die ersten vier Spalten lösen Aufgaben, die ein Multi-Customer-Setup gar nicht erst stellt.

Legende: ✅ vorhanden · (✅) mit Aufwand machbar · ❌ nicht das Einsatzgebiet.

Die vielen Kreuze in den ersten vier Spalten sind kein Versäumnis. Eine MQTT-Bridge will keine Mandantengrenze ziehen, das wäre gegen ihren Sinn. Ein VPN will kein Flotten-Dashboard sein. Das alles sind ehrliche Striche, keine Schwächen, die der Hersteller noch nachreichen müsste.

Ab wie vielen Kunden lohnt sich Multi-Tenant?

Ehrliche Antwort: für eine einzelne Privat-Instanz lohnt es sich nie. Da ist eine Plattform Overkill, und Nabu Casa oder ein schlichter Tunnel sind die bessere Wahl. Für zwei, drei eigene Instanzen reicht Tailscale mit Tags pro Site. Die Schwelle liegt erfahrungsgemäß irgendwo bei fünf Installationen aufwärts, und der eigentliche Auslöser ist weniger die Zahl als das Verhältnis: Sobald mindestens ein paar davon zahlende Kunden sind, für die du geradestehst, kippt die Rechnung. Dann kostet jede Minute, die du mit dem Suchen verbringst, welche Instanz brennt, echtes Geld. Und eine Wartungshistorie aus dem Gedächtnis ist im Streitfall keine.

Wer noch unsicher ist, wo die eigene Größenordnung steht, findet im Vergleich der sechs Wege, mehrere HA-Instanzen zu verwalten, einen Entscheidungsbaum, der auch ehrlich sagt, wann ein generisches Tool die bessere Wahl bleibt. Und wer als Integrator glaubt, das Problem heiße „bessere Tunnel-Lösung”, sollte vorher lesen, warum eine Nabu Casa Alternative für Integratoren die falsche Frage ist. Spoiler: Das Problem heißt nicht Fernzugriff, es heißt Übersicht.

Was HA Fleet Manager ist, und was nicht

Ich schreibe diesen Blog für ein Produkt, also sage ich offen, worum es geht und wo die Grenzen liegen. Werbesprech nervt mich bei diesem Thema selbst am meisten.

HA Fleet Manager ist eine Multi-Tenant-Plattform für Home-Assistant-Integratoren. Der Connector ist eine Custom Integration auf jeder Kundeninstanz, und ab dann siehst du den Zustand des ganzen Portfolios in einem Dashboard: welche Instanz online ist, welche Integrationen laufen, welche HACS-Plugins in welcher Version installiert sind, ob kritische Logs auflaufen. Jeder Kunde ist ein eigener Mandant, sauber getrennt, mit eigener Wartungshistorie. Der Fernzugriff läuft über ein ausgehendes WebSocket-Relay, CGNAT-tauglich, ohne offenen Port, ohne Voll-LAN-VPN, und greift erst, nachdem der Kunde per Schalter ein befristetes Wartungsfenster freigegeben hat (standardmäßig 12 Stunden, auf den bezahlten Tarifen bis 30 Tage, aber nur mit ausdrücklicher Bestätigung des Kunden). Danach geht die Tür automatisch wieder zu. Das Hosting läuft in der EU, bei Hetzner, die Oberfläche ist deutsch. Wenn dich genau dieser Übergang gerade beschäftigt, kannst du dir kostenlos einen Zugang anlegen und schauen, ob die Flottensicht das ist, was dir mit den Bordmitteln gefehlt hat.

Was es nicht ist: ein fertiges, jahrelang ausgehärtetes Produkt mit dem Funktionsumfang etablierter RMM-Suiten. Es ist jung. Keine PSA-Integration, keine eigene Mobile-App im aktuellen Stand. Für eine einzelne Privat-Instanz ist es Overkill, der Wert beginnt erst ab einer Handvoll Installationen aufwärts. Und es verlangt, dass du einer zentralen Relay-Komponente vertraust. Das ist eine bewusste Entscheidung, kein Detail, das man wegmarketingt. Wer lieber alles strikt auf dem eigenen Blech behält und mit drei Tailscale-Tunneln glücklich ist, soll das ruhig bleiben. Die Plattform rechnet sich erst, wenn die Tunnel anfangen, Arbeit zu machen.

Die Grenze, in einem Satz

Solange es deine Instanzen sind, verschmilz sie, wie du magst, remote_homeassistant und MQTT-Bridge sind dafür gute Werkzeuge. Sobald es Kundeninstanzen werden, hörst du auf, sie verbinden zu wollen, und fängst an, sie zu trennen und von oben zu sehen. Das ist keine bessere Bastellösung. Es ist eine andere Frage.

Disclosure: HA Fleet Manager ist das Produkt hinter diesem Blog. Die Anerkennung für remote_homeassistant, MQTT und die VPN-Tools ist trotzdem ernst gemeint. Für die eigenen zwei, drei Instanzen würde ich jedes davon nehmen.