MQTT Broker Hosting reicht von einem einzelnen virtuellen Server, den Sie selbst konfigurieren, bis zu einem verwalteten MQTT-Broker in Ihrem eigenen Cloud-Konto. Dieser Vergleich geht die fünf gängigen Optionen durch, zeigt den tatsächlichen Aufwand jeder einzelnen und endet mit einer Checkliste, mit der Sie heute die passende Variante für Ihr Projekt wählen, ohne sich den Weg für morgen zu verbauen.
Die fünf gängigen Optionen für MQTT Broker Hosting
- Selbst gehostet auf einem VPS oder On-Premises-Server, meist mit Mosquitto.
- Selbst gehostet auf Kubernetes, mit einem Open-Source-Broker in Containern.
- Serverless (verwaltet), ein gemeinsam genutzter, mandantenfähiger verwalteter MQTT-Broker, den Sie als Service beziehen.
- Dedicated (verwaltet), ein isolierter Broker-Cluster, der von einem Anbieter betrieben wird.
- BYOC (Bring Your Own Cloud), ein vom Anbieter betriebener Broker in Ihrem eigenen Cloud-Konto.
Eine sechste Variante, Herstellersoftware, die Sie unter einer Enterprise-Lizenz selbst installieren und betreiben, liegt zwischen Option 1 und 5.
Vergleich im Überblick
| VPS mit Mosquitto | Kubernetes | Serverless (verwaltet) | Dedicated (verwaltet) | BYOC | |
|---|---|---|---|---|---|
| Zeit bis zur ersten Verbindung | Schnell bei einem einzelnen Server | Länger; Cluster-Einrichtung nötig | Minuten, Self-Service | Abstimmung mit dem Anbieter nötig | Abstimmung und Vorbereitung des Cloud-Kontos nötig |
| Wer patcht und aktualisiert | Sie | Sie | Anbieter | Anbieter | Anbieter |
| Wer verwaltet TLS-Zertifikate | Sie | Sie | Anbieter | Anbieter | Anbieter |
| Isolation von anderen Mandanten | Vollständig | Vollständig | Logisch, gemeinsame Infrastruktur | Vollständig | Vollständig |
| Eigentum an der Infrastruktur | Sie | Sie | Anbieter | Anbieter | Sie |
| Skalierungsaufwand | Manuelles Hochstufen | Manuell, clusterbewusst | Plan wählen | Dimensionierung mit dem Anbieter | Dimensionierung mit dem Anbieter |
| Erforderliches internes Know-how | Linux, Netzwerk, TLS | Kubernetes, Netzwerk, TLS | MQTT-Clients | MQTT-Clients | Administration des Cloud-Kontos |
| Am besten geeignet für | Labore, kleine Systeme an einem Standort, isolierte Werksnetze | Teams, die bereits Kubernetes betreiben | Prototypen bis mittelgroße Flotten | Produktive Flotten mit Isolationsbedarf | Strikte Datenkontrolle oder bestehende Cloud-Landschaft |
Option 1: VPS oder On-Premises mit Mosquitto
Eclipse Mosquitto ist schlank, gut dokumentiert und leicht zu starten. Eine minimale, produktionstaugliche Konfiguration mit TLS und Passwortauthentifizierung sieht so aus:
# /etc/mosquitto/conf.d/production.conf
per_listener_settings true
listener 8883
certfile /etc/letsencrypt/live/mqtt.example.com/fullchain.pem
keyfile /etc/letsencrypt/live/mqtt.example.com/privkey.pem
allow_anonymous false
password_file /etc/mosquitto/passwd
listener 8084
protocol websockets
certfile /etc/letsencrypt/live/mqtt.example.com/fullchain.pem
keyfile /etc/letsencrypt/live/mqtt.example.com/privkey.pem
allow_anonymous false
password_file /etc/mosquitto/passwd
sudo apt install -y mosquitto mosquitto-clients
sudo mosquitto_passwd -c /etc/mosquitto/passwd device01
sudo systemctl restart mosquitto
Damit sind Sie startklar. Unterschätzt wird meist der laufende Aufwand: Zertifikate erneuern und den Broker neu laden, Sicherheitsupdates für Betriebssystem und Broker einspielen, Festplatte und Arbeitsspeicher überwachen, Limits für Dateideskriptoren erhöhen, Backups der Passwortdatei verwalten, Brute-Force-Anmeldeversuche abwehren und planen, was passiert, wenn der einzelne Server ausfällt.
Vorteile: volle Kontrolle, geringe direkte Kosten, funktioniert offline im lokalen Netzwerk, etwa im OT-Netz einer Fertigungshalle neben SPS und Edge-Gateways. Nachteile: Sie sind die Rufbereitschaft; ein einzelner Server ist ein Single Point of Failure; die Sicherheit liegt vollständig in Ihrer Verantwortung.
Option 2: Kubernetes
Wenn Ihr Unternehmen bereits Kubernetes betreibt, liegt es nahe, den Broker dort bereitzustellen. Sie erhalten deklarative Konfiguration, Rolling Updates und die Anbindung an Ihr bestehendes Monitoring.
Der Haken: MQTT ist ein zustandsbehaftetes Protokoll mit langlebigen Verbindungen, während Kubernetes seine Stärken bei zustandslosen Request-Response-Services ausspielt. Sie brauchen TCP-Load-Balancing statt HTTP-Ingress, sorgfältig gewählte Pod Disruption Budgets, damit Rolling Updates nicht alle Clients gleichzeitig trennen, Persistent Volumes, wenn Sie Session-Persistenz wünschen, und ein Verständnis dafür, wie sich Ihr Broker verhält, wenn Pods neu eingeplant werden. Unser Leitfaden MQTT-Broker auf Kubernetes behandelt diese Details.
Vorteile: passt zu vorhandenen Plattform-Werkzeugen, Infrastructure as Code, volle Kontrolle. Nachteile: erhebliches Betriebs-Know-how erforderlich; bei Routinearbeiten entstehen leicht störende Reconnect-Stürme.
Option 3: Serverless (verwaltet)
Ein Serverless Broker ist der schnellste Weg zu einem sicheren Endpunkt. Sie registrieren sich, legen einen Broker an und erhalten Hostname, Ports und Zugangsdaten. Der Anbieter betreibt einen gemeinsam genutzten, mandantenfähigen Cluster und setzt Kontingente pro Plan durch, um die Mandanten voneinander abzugrenzen.
Die Serverless-Pläne von ConnectMQ sind ein Beispiel:
- Serverless (Free): bis zu 25 Verbindungen, QoS bis 1, Nachrichten bis 256 KB.
- Serverless (Paid): bis zu 1.000 Verbindungen, QoS 2, Nachrichten bis 1 MB, Shared Subscriptions.
Beide unterstützen MQTT 3.1.1 und 5.0 über TCP 1883, TLS 8883, WebSocket 8083 und Secure WebSocket 8084 mit dem Pfad /mqtt, ein Let's-Encrypt-Zertifikat ist bereits eingerichtet. Die Verbindung funktioniert wie bei jedem anderen Broker:
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID \
-t "acme/#" -v -V mqttv5
Vorteile: Start in Minuten, keine Server, sichere Standardeinstellungen, Portal-Werkzeuge inklusive. Nachteile: gemeinsame Infrastruktur, feste Plan-Limits, weniger Kontrolle über Standort und Feintuning.
Mehr dazu unter Serverless MQTT-Broker.
Option 4: Dedicated (verwaltet)
Eine dedizierte Bereitstellung bietet Ihnen einen isolierten Broker-Cluster, den kein anderer Kunde nutzt und der weiterhin vom Anbieter betrieben wird. Das passt zu Produktivsystemen, bei denen Sie eine vorhersehbare Performance ohne Einfluss anderer Mandanten wünschen und deren Last den Limits gemeinsamer Pläne entwachsen ist. Sie beschreiben die erwarteten Verbindungen, Nachrichtenraten und Payload-Größen, und die Bereitstellung wird entsprechend dimensioniert.
Vorteile: Isolation, Betrieb durch den Anbieter, auf Ihre Last zugeschnitten. Nachteile: höhere Kosten als gemeinsame Pläne; die Einrichtung dauert länger als eine Self-Service-Registrierung.
Details finden Sie unter dedizierter MQTT-Broker.
Option 5: BYOC
Bei Bring Your Own Cloud läuft der Broker in Ihrem eigenen Cloud-Konto, mit Ihrer Abrechnung, Ihren Netzwerkkontrollen und Sicherheitsrichtlinien, während der Anbieter ihn bereitstellt und betreibt. Das eignet sich für Organisationen mit strengen Anforderungen an die Datenkontrolle oder einer großen bestehenden Cloud-Landschaft, in der die Konsumenten bereits laufen.
Vorteile: Ihre Infrastruktur und Ihr Datenpfad, Betrieb durch den Anbieter, Platzierung direkt neben Ihren anderen Systemen. Nachteile: Sie zahlen die Cloud-Rechnung und müssen den Zugriff des Anbieters gewähren und steuern; mehr Abstimmung bei der Einrichtung.
Unser Artikel BYOC MQTT Broker erklärt das Modell und die nötige Vorbereitung des Kontos.
Was keine der Optionen ändert
Unabhängig vom gewählten Hosting-Modell bleiben einige Aufgaben bei Ihnen:
- Geräte-Firmware, Reconnect-Logik und lokale Pufferung.
- Design des Topic-Namensraums. In Industrie-4.0-Projekten ist das meist ein Unified Namespace (UNS), dessen Topic-Struktur der ISA-95-Hierarchie folgt (Enterprise, Site, Area, Line, Cell), etwa
acme/werk-muenchen/presswerk/linie-2/zelle-1/energie. Diese Struktur zieht bei jedem Wechsel des Hosting-Modells unverändert mit; siehe Sparkplug B und Unified Namespace. - Payload-Formate und Validierung.
- Speicherung der Historie und Integration mit anderen Systemen, typischerweise über einen Subscriber-Service, Node-RED oder Telegraf als MQTT-Client.
- Wahl der QoS-Stufe je Nachrichtentyp.
Da MQTT ein Standard ist, bedeutet ein Wechsel zwischen Hosting-Modellen meist nur, Hostname und Zugangsdaten auf den Clients zu ändern, sofern Sie proprietäre Erweiterungen vermeiden.
So wählen Sie: eine Hosting-Checkliste
Beantworten Sie diese Fragen der Reihe nach. Die erste, die eindeutig zutrifft, entscheidet meist über das Hosting-Modell.
- Ist es eine Übung oder eine Demo? Nutzen Sie den Öffentlichen MQTT-Broker, der ausschließlich für Tests und Prototypen gedacht ist, und verzichten Sie ganz auf Hosting.
- Muss der Broker in einem lokalen Netzwerk ohne Internet laufen, etwa in einer abgeschotteten OT-Zelle? Hosten Sie On-Premises selbst oder ziehen Sie eine selbst verwaltete Enterprise-Option in Betracht.
- Müssen die Daten in Cloud-Konten bleiben, die Ihnen gehören? Wählen Sie BYOC.
- Brauchen Sie Isolation von anderen Mandanten oder eine Dimensionierung jenseits gemeinsamer Pläne? Wählen Sie eine dedizierte Bereitstellung.
- Betreiben Sie bereits Kubernetes und möchten den Broker auf derselben Plattform? Hosten Sie selbst auf Kubernetes und nehmen Sie den Betriebsaufwand in Kauf.
- Andernfalls: Starten Sie mit einem verwalteten MQTT-Broker im Serverless-Plan und steigen Sie auf, wenn Verbindungen und Anforderungen wachsen.
Berücksichtigen Sie außerdem die Gesamtkosten, nicht nur den Monatspreis. Engineering-Zeit für Patches, Zertifikatserneuerung, Incident Response und Upgrades ist bei selbst gehosteten Optionen ein realer Kostenfaktor. Gesamtbetriebskosten eines MQTT-Brokers und MQTT-Broker selbst betrieben vs. verwaltet vertiefen diesen Vergleich, und der Leitfaden zum Cloud-MQTT-Broker bietet den vollständigen Überblick.
Wo ConnectMQ ins Bild passt
ConnectMQ deckt die verwaltete Seite dieser Tabelle ab: Serverless (Free und Paid) für einen schnellen Start und wachsende Flotten, Dedicated für isolierte Cluster, BYOC für Broker in Ihrem eigenen Cloud-Konto und Self Managed Enterprise für Organisationen, die den Broker selbst betreiben müssen. Alle sprechen dasselbe Standard-MQTT, sodass Sie klein anfangen und sich entlang des Spektrums bewegen können, ohne Ihre Geräte neu zu konzipieren.
Starten Sie Ihr MQTT Broker Hosting mit ConnectMQ
Erstellen Sie einen kostenlosen Serverless Broker unter app.connectmq.com, ohne Kreditkarte, und verbinden Sie Ihr erstes Gerät in wenigen Minuten. Wenn Sie Isolation oder Kontrolle über den Standort des Brokers brauchen, sprechen Sie mit dem Team über Dedicated oder BYOC. Wenn Sie zunächst einen breiteren Einstieg wünschen, lesen Sie, wie Sie einen verwalteten MQTT-Broker auswählen.
Häufig gestellte Fragen
Was ist der günstigste Weg, einen MQTT Broker zu hosten?
Ein kostenloser Plan für einen verwalteten MQTT-Broker oder ein kleiner selbst gehosteter Mosquitto-Server verursachen die geringsten direkten Ausgaben. Beim Self-Hosting kommt Ihre eigene Zeit für Patches, Zertifikate und Monitoring hinzu, die die Serverkosten oft übersteigt.
Kann ich Mosquitto für den Produktivbetrieb auf einem VPS hosten?
Ja, mit TLS, Authentifizierung, Monitoring und einem Plan für Updates und Ausfälle. Viele Teams starten so und wechseln zu einem verwalteten MQTT-Broker, wenn der Betriebsaufwand wächst.
Ist Kubernetes ein guter Ort für einen MQTT Broker?
Das kann es sein, wenn Ihr Team Kubernetes bereits sicher betreibt. Die langlebigen Verbindungen von MQTT erfordern TCP-Load-Balancing und sorgfältige Rolling Updates, um massenhafte Reconnects zu vermeiden.
Was ist der Unterschied zwischen Dedicated- und BYOC-Hosting?
Beide bieten Ihnen einen isolierten Broker, der vom Anbieter betrieben wird. Dedicated läuft in der Infrastruktur des Anbieters, BYOC dagegen in Ihrem eigenen Cloud-Konto.
