„Können wir das auf unseren eigenen Servern betreiben?" ist eine der ersten Fragen, die ernsthafte IoT-Einkäufer stellen — und eine der am wenigsten ehrlich beantworteten. Eine IoT-Plattform selbst zu hosten ist für manche Deployments wirklich die richtige Entscheidung und für andere ein teurer Umweg. So finden Sie heraus, zu welcher Gruppe Sie gehören.
Was „selbst gehostet" wirklich bedeutet
Eine selbst gehostete IoT-Plattform läuft auf Infrastruktur, die Sie kontrollieren: auf Ihren eigenen Servern, in Ihrer Private Cloud oder in einem isolierten Netzwerksegment. Gerätedaten verlassen nie Ihren Perimeter, die Authentifizierung integriert sich in Ihre Identitätssysteme, und die Verfügbarkeit der Plattform liegt in der Verantwortung Ihres Teams — im ermächtigenden wie im 3-Uhr-nachts-Sinn des Wortes.
Dieser letzte Punkt ist der ehrliche Kern dieses Artikels: Self-Hosting ist kein Feature, das man aktiviert, sondern eine Betriebsaufgabe, die man übernimmt.
Die guten Gründe für Self-Hosting
Datensouveränität und Compliance. Regulierte Branchen, der öffentliche Sektor und kritische Infrastrukturen haben oft harte Anforderungen, dass Telemetrie on-premise oder im Land bleibt. Wenn Ihre Auditoren sagen, die Daten dürfen das Haus nicht verlassen, ist die Diskussion beendet — Sie brauchen ein On-Premise-Deployment.
Air-Gap-Standorte und Standorte mit schwacher Anbindung. Eine Fabrik, ein Schiff oder eine abgelegene Anlage mit unzuverlässigem Backhaul braucht die Plattform womöglich neben den Maschinen — nicht auf der anderen Seite eines Ozeans.
Latenz und Lokalität. Wenn Automatisierungsentscheidungen in Millisekunden gegen lokale Anlagen greifen müssen, eliminiert eine lokale Plattform den Umweg über das Netz.
Langfristige Kontrolle. Manche Teams wollen schlicht die Garantie, dass keine Preisänderung und keine Produkteinstellung eines Anbieters ihr Deployment stranden lassen kann.
Die Kosten, die niemand auf die Landingpage schreibt
Open-Source-Plattformen, die Sie selbst hosten — ThingsBoards Apache-2.0-Community-Edition ist das bekannteste Beispiel — sind lizenzkostenfrei, aber nicht betriebskostenfrei. Jemand muss die Datenbank dimensionieren und skalieren, Sicherheitspatches einspielen, Upgrades testen, das Monitoring selbst überwachen und die Rufbereitschaft übernehmen. Features, die Sie für inklusive hielten, stecken womöglich in Bezahl-Editionen; bei ThingsBoard etwa kommt LoRaWAN-Konnektivität über externe Netzwerkserver-Integrationen, die den kostenpflichtigen Stufen vorbehalten sind. Unser Vergleich Kilo vs. ThingsBoard legt diesen Trade-off ehrlich offen — inklusive der Punkte, an denen ThingsBoard wirklich gewinnt.
Eine nützliche Faustregel: Wenn Sie den Engineer nicht benennen können, der in achtzehn Monaten die Plattform-Upgrades verantwortet, entscheiden Sie sich nicht für Self-Hosting — Sie entscheiden sich für technische Schulden.
Der Mittelweg: eine Managed-Plattform, on-premise betrieben
Die Wahl lautet nicht nur „Public SaaS" oder „rohes Open Source". Kilos IoT-Plattform läuft als Cloud-SaaS und als On-Premise-Deployment: dieselbe Plattform — integrierte LoRaWAN- und mioty-Netzwerkserver, Dashboards mit digitalem 3D-Gebäudezwilling, Regeln mit Build-Test-Deploy-Rollback, Alarm-Eskalationsketten und der KI-Assistent — installiert innerhalb Ihres Perimeters, während der Anbieter weiterhin für die Software selbst verantwortlich bleibt.
Das teilt den Unterschied genau dort, wo die meisten Teams ihn geteilt haben wollen: Ihre Infrastruktur und Ihre Daten, aber nicht Ihre Aufgabe, die Plattform zu entwickeln und zu warten.
Eine kurze Checkliste vor der Entscheidung
Stellen Sie fünf Fragen. Verlangt eine Regulierung tatsächlich On-Premise, oder fühlt es sich nur sicherer an? Wer betreibt die Plattform im zweiten Jahr? Enthält die selbst gehostete Edition die Konnektivität, die Sie brauchen (LoRaWAN-Netzwerkserver, MQTT), oder sind das Add-ons? Was kostet der Weg zurück, wenn Sie sich irren? Und können Sie beide Modelle zuerst günstig pilotieren?
Die letzte Frage ist leicht zu beantworten: Kilos Cloud-Stufe ist für 5 Geräte kostenlos. Sie können den Anwendungsnutzen also in der Cloud beweisen und dann mit bereits validiertem Deployment-Modell auf On-Premise wechseln — statt Infrastruktur und Use Case gleichzeitig zu debuggen.