Fast jedes MQTT-Projekt beginnt auf einem öffentlichen Broker. Du kopierst broker.hivemq.com oder broker.emqx.io aus einem Tutorial, verbindest dich ohne Zugangsdaten, und nach Sekunden fließen Nachrichten. Genau für diese Geschwindigkeit gibt es öffentliche Broker. Doch dieselbe Offenheit, die sie so einfach macht, macht sie auch ungeeignet für alles, was über Experimente hinausgeht. Dieser Leitfaden zeigt dir die Vor- und Nachteile ehrlich auf, damit du weißt, wann du bleiben und wann du wechseln solltest.
Was ein öffentlicher MQTT-Broker eigentlich ist
Ein öffentlicher Broker ist ein gemeinsam genutzter MQTT-Server, der anonyme Verbindungen von jedem im Internet annimmt. Hersteller und Open-Source-Projekte betreiben sie als Demos und Interoperabilitäts-Sandboxes. Unsere Liste öffentlicher Broker deckt die bekannten ab. Ihre prägenden Eigenschaften:
- Keine Registrierung und meist weder Benutzername noch Passwort.
- Ein gemeinsamer Topic-Namespace für alle Nutzer weltweit.
- Best-Effort-Betrieb zum Testen, kein unterstützter Dienst.
Die echten Risiken öffentlicher Sandboxes
1. Jeder kann deine Topics lesen und beschreiben
Ohne Authentifizierung und Zugriffskontrolle empfängt ein Subscriber auf # jede Nachricht auf dem Broker – auch deine. Jeder kann außerdem auf deine Command-Topics publishen. Wenn ein Gerät auf home/garage/door/set lauscht, kann ein Fremder es öffnen. Obskure Topic-Namen verringern Kollisionen, sind aber keine Sicherheit: Wer # abonniert hat, sieht sie.
2. Retained-Müll und veralteter Zustand
Retained Messages bleiben bestehen, bis jemand sie löscht. Auf einem öffentlichen Broker sind Topics übersät mit Retained Payloads anderer Nutzer und alter Tests, und jeder kann deinen Retained-Zustand überschreiben. Ein Dashboard, das dem Retained-Wert beim Subscribe vertraut, kann Daten anzeigen, die nie deine waren. Wie Retention funktioniert, erfährst du unter MQTT Retained Messages.
3. Topic- und Client-ID-Kollisionen
Generische Topics wie test/temperature teilst du mit allen, die demselben Tutorial gefolgt sind. Generische Client-IDs sind noch schlimmer: Verbindet sich jemand anderes mit deiner ID, trennt der Broker dich, und beide Clients landen in einer Reconnect-Schleife. Details unter MQTT-Verbindungsfehler.
4. Kein SLA, kein Support, keine Vorwarnung
Öffentliche Broker können jederzeit neu gestartet, aktualisiert oder gedrosselt werden. Manche laufen absichtlich mit Entwicklungs-Builds. Für eine Sandbox ist das in Ordnung, heißt aber, dass eine Demo vor einem Kunden aus Gründen scheitern kann, die du weder sehen noch beheben kannst.
5. Rate Limits und fehlende Features
Betreiber schützen geteilte Infrastruktur mit Limits für Verbindungen, Nachrichtenrate und Payload-Größe, die oft nicht dokumentiert sind. Außerdem kannst du die Features nicht testen, auf die es in Produktion ankommt: Authentifizierung, Berechtigungen pro Topic, Client-Zertifikate, Bridging oder Persistenz-Einstellungen.
Wann ein öffentlicher Broker völlig in Ordnung ist
- Zum Lernen von MQTT-Konzepten wie QoS, Wildcards und Last Will.
- Um zu prüfen, ob eine neue Client-Bibliothek oder Geräte-Firmware sich verbinden und publishen kann.
- Für schnelle Demos mit Dummy-Daten und einem zufälligen Topic-Präfix.
- Um einen Bug gegen einen neutralen, bekannten Broker zu reproduzieren.
Wenn du einen nutzt, halte dich an ein paar Gewohnheiten:
# Random prefix + random client ID = fewer collisions
PREFIX="testmqtt/$(openssl rand -hex 4)"
mosquitto_sub -h broker.emqx.io -i "sub-$(openssl rand -hex 4)" -t "$PREFIX/#" -vÖffentlichen Broker sicher ausprobieren
Anzeichen, dass es Zeit für einen Wechsel ist
- Deine Nachrichten enthalten etwas, das du nicht öffentlich posten würdest.
- Geräte nehmen Befehle über MQTT entgegen.
- Jemand außer dir ist darauf angewiesen – ein Teammitglied, ein Pilotkunde, eine Demo.
- Du musst Authentifizierung, ACLs oder TLS-Client-Zertifikate testen.
- Du hattest unerklärliche Verbindungsabbrüche, Drosselung oder fremde Nachrichten.
Deine Optionen für einen privaten Broker
| Option | Was du verwaltest | Passt gut, wenn |
|---|---|---|
| Selbst gehostetes Mosquitto | Server, TLS, Benutzer, Updates, Monitoring | kleine Deployments und Teams, die sich im Linux-Betrieb wohlfühlen |
| Selbst gehostetes EMQX oder HiveMQ Community Edition | Wie oben, plus Cluster-Konfiguration | du Clustering oder Broker-Plugins brauchst und Ops-Kapazität hast |
| Managed Broker (zum Beispiel ConnectMQ) | Nur Benutzer, Topics und Clients | du einen privaten, abgesicherten Broker willst, ohne Infrastruktur zu betreiben |
Self-Hosting ist eine solide Wahl und gibt dir volle Kontrolle; der Preis ist laufende Arbeit – Zertifikatserneuerungen, OS-Patches, Backups und Alerting. Ein Managed Broker tauscht etwas Kontrolle gegen den Wegfall genau dieser Arbeit.
Ein sinnvoller Weg: öffentlich zum Lernen, privat für alles andere
Du musst dich nicht ein für alle Mal entscheiden. Viele Teams nutzen eine öffentliche Sandbox für den ersten Nachmittag – um zu prüfen, ob eine Bibliothek funktioniert und das Topic-Design Sinn ergibt – und wechseln auf einen privaten Broker, sobald echte Geräte oder Teammitglieder beteiligt sind. Ab dann bekommen Entwicklung, Staging und Produktion jeweils einen eigenen Broker oder eigene Zugangsdaten, sodass ein Testskript nie versehentlich in Produktions-Topics publishen kann.
Halte die Verbindungsdaten (URL, Benutzername, Passwort) vom ersten Tag an in Konfiguration oder Umgebungsvariablen. Dann ist ein Brokerwechsel eine Deployment-Änderung statt einer Code-Änderung, und du kannst denselben Build für eine Demo auf einen öffentlichen Broker oder für einen Pilot auf einen privaten zeigen lassen.
Worauf du bei einem privaten oder Managed Broker achten solltest
- Isolation: eine eigene Instanz oder ein eigener Namespace, kein geteilter Topic-Baum.
- Authentifizierung: mindestens Benutzername/Passwort pro Client, idealerweise Zugangsdaten pro Gerät.
- Autorisierung: Zugriffskontrolle pro Topic, damit ein Sensor nur auf seine eigenen Topics publishen kann.
- Verschlüsselung: TLS auf
8883und sichere WebSockets für Browser-Apps. Siehe MQTT-Ports. - Protokoll-Support: MQTT 3.1.1 und MQTT 5, damit ältere Geräte und neuere Features nebeneinander funktionieren.
- Standard-Endpunkte: einfacher Host und Port, damit ein späterer Umzug nur eine Konfigurationsänderung ist.
- Transparenz: eine Möglichkeit, verbundene Clients zu sehen und warum eine Verbindung abgelehnt wurde.
Die Migration ist vor allem Konfiguration
Weil MQTT ein Standardprotokoll ist, berührt der Umzug von einem öffentlichen auf einen privaten Broker selten die Anwendungslogik:
// Before: public sandbox
mqtt.connect('wss://broker.emqx.io:8084/mqtt');
// After: private broker with credentials over TLS
mqtt.connect(process.env.MQTT_URL, {
username: process.env.MQTT_USERNAME,
password: process.env.MQTT_PASSWORD,
clientId: `sensor-${deviceSerial}`,
});Nutze den Umzug auch gleich, um deine Topic-Hierarchie aufzuräumen – eine konsistente Struktur macht Zugriffsregeln viel einfacher. MQTT-Topics und Wildcards behandelt Namensmuster, die skalieren, und mit dem Topic-Matcher kannst du deine Filter prüfen.
Häufig gestellte Fragen
Ist es sicher, einen öffentlichen MQTT-Broker zu nutzen?
Für das Lernen und schnelle Tests mit Dummy-Daten ja. Für alles Private nein: Öffentliche Broker haben keine Authentifizierung, also kann jeder, der dein Topic errät oder per Wildcard abonniert, darauf lesen und publishen.
Kann ich einen öffentlichen MQTT-Broker in Produktion nutzen?
Nein. Öffentliche Sandboxes werden zum Testen betrieben, bieten kein Service Level Agreement, können jederzeit drosseln oder neu starten und haben keine Zugriffskontrolle. Produktivsysteme brauchen einen Broker, den du oder ein Anbieter kontrolliert.
Was ist der Unterschied zwischen einem privaten und einem Managed MQTT-Broker?
Ein privater Broker ist jeder Broker, den nur deine Clients nutzen können. Du kannst ihn selbst hosten (Mosquitto, EMQX, HiveMQ CE) oder einen Managed Service nutzen, bei dem der Anbieter die Infrastruktur betreibt und du eine isolierte Instanz mit Zugangsdaten bekommst.