HiveMQ stellt den Tarif HiveMQ Cloud Serverless ein, und zwar sowohl die Cluster von Serverless Free als auch von Serverless Pay As You Go, zum 31. Dezember 2026. Nach diesem Datum können sich MQTT-Clients nicht mehr mit diesen Clustern verbinden, und HiveMQ löscht die Cluster samt ihren Daten endgültig. Wenn sich Ihre Geräte, Dashboards oder Backend-Dienste mit einem Hostnamen auf hivemq.cloud in einem Serverless-Cluster verbinden, brauchen Sie bis zum Jahresende einen neuen Broker und einen Migrationsplan.
Dieser Leitfaden fasst zusammen, was das End of Life von HiveMQ Cloud Serverless in der Praxis bedeutet, was Sie übernehmen können und was nicht, welche Optionen Sie haben und wie Sie ohne Serviceunterbrechung zu einem privaten verwalteten MQTT-Broker wechseln. Alle Aussagen zu HiveMQ in diesem Artikel beruhen auf der End-of-Life-Dokumentation von HiveMQ zum Zeitpunkt der Erstellung; prüfen Sie für den aktuellen Stand immer die offizielle Seite und die E-Mail zur Einstellung, die Sie erhalten haben.
Was HiveMQ angekündigt hat
Die Dokumentation von HiveMQ beschreibt die Einstellung in wenigen klaren Regeln:
| Thema | Was HiveMQ angibt |
|---|---|
| Betroffene Tarife | Cluster von HiveMQ Cloud Serverless Free und Serverless Pay As You Go |
| Neue Cluster | Sie können keinen Serverless-Cluster mehr anlegen und keinen Serverless-Cluster mehr auf Pay As You Go hochstufen |
| End-of-Life-Datum | 31. Dezember 2026 |
| Nach dem End-of-Life-Datum | MQTT-Clients können sich nicht mehr mit Serverless-Clustern verbinden |
| Daten | HiveMQ löscht alle Serverless-Cluster und ihre Daten endgültig, einschließlich Retained Messages, Client-Sessions, Zugangsdaten und Berechtigungen |
| Cluster-URL | Kann nicht auf einen neuen Broker übertragen werden |
| Automatische Migration | Keine: Clients, Daten und Konfiguration werden nicht für Sie übertragen |
| Migrationsangebot | Eine kostenlose Migration License für den selbst betriebenen HiveMQ Enterprise Broker |
Bis zum End-of-Life-Datum können Sie weiterhin Zugangsdaten und Berechtigungen verwalten, Verbindungsdetails einsehen und Ihren Serverless-Cluster löschen. Ein gelöschter Cluster kann nicht wiederhergestellt werden. Löschen Sie ihn also erst, wenn Ihre Clients auf dem neuen Broker laufen.
Was ab dem 1. Januar 2027 nicht mehr funktioniert
Die konkreten Auswirkungen hängen davon ab, was mit Ihrem Cluster verbunden ist:
- Geräte und Gateways, die sich mit
<cluster-id>.s1.eu.hivemq.cloud(oder einem ähnlichen Serverless-Hostnamen) verbinden, scheitern beim Verbindungsaufbau und versuchen es immer wieder. - Backend-Dienste wie Datenaufnahme, Regel-Engines oder Node-RED-Flows, die den Cluster abonnieren, erhalten keine Daten mehr.
- Web-Dashboards, die sich über Secure WebSocket verbinden, zeigen keine Live-Daten mehr an.
- Retained Messages und persistente Sessions auf dem Cluster sind verloren. Der letzte bekannte Zustand jedes Geräts muss auf dem neuen Broker neu aufgebaut werden.
Da die Cluster-URL nicht mitziehen kann, braucht jeder Client mindestens einen neuen Hostnamen und neue Zugangsdaten. Das ist die wichtigste Tatsache für Ihre Planung: Der Aufwand wächst mit der Zahl der Clients und damit, wie schwer sich jeder einzelne umkonfigurieren lässt. Bei einem Web-Dashboard ist es eine Konfigurationsänderung; ein batteriebetriebener Sensor im Feld braucht womöglich ein Firmware-Update.
Die Migration License im Überblick
HiveMQ bietet berechtigten Nutzern eine kostenlose Migration License für den selbst betriebenen HiveMQ Enterprise Broker an. Laut HiveMQ erlaubt sie 12 Monate lang 100 gleichzeitige Verbindungen und 100 Nachrichten pro Sekunde, erfordert keine Kreditkarte und läuft danach als kostenlose Lab License mit niedrigeren Limits weiter (derzeit 25 gleichzeitige Verbindungen und 25 Nachrichten pro Sekunde). Sie können sie beanspruchen, wenn Ihr Benutzerkonto zum Zeitpunkt der Ankündigung einen Serverless-Cluster besaß.
Das entscheidende Wort ist selbst betrieben. Mit der Migration License installieren, betreiben, sichern, patchen und überwachen Sie den Broker selbst, auf Ihrem eigenen Server oder Kubernetes-Cluster. Für manche Teams passt das gut, für andere ist es eine erhebliche neue Verantwortung, vor allem für jene, die Serverless gerade deshalb gewählt haben, weil sie keine Infrastruktur betreiben wollten. Beide Wege vergleichen wir ausführlich in HiveMQ Migration License vs. verwalteter MQTT-Broker.
Ihre Optionen nach HiveMQ Cloud Serverless
| Option | Wer den Broker betreibt | Passend, wenn |
|---|---|---|
| Selbst betriebener Broker (zum Beispiel mit der HiveMQ Migration License) | Sie | Sie Betriebskapazität haben und den Broker auf eigener Infrastruktur wollen |
| Ein anderer Serverless-MQTT-Dienst | Der Anbieter, auf einem geteilten Cluster | Sie dieselbe „serverlose" Erfahrung wie bei Serverless möchten |
| Ein dedizierter verwalteter MQTT-Broker | Der Anbieter, auf einem Cluster nur für Sie | Sie Produktionsflotten betreiben und Isolation sowie planbare Leistung wollen |
| Bring Your Own Cloud | Der Anbieter, in Ihrem Cloud-Konto | Daten in Ihrem eigenen Cloud-Konto bleiben müssen |
Die meisten Nutzer von Serverless Free hatten kleine Flotten und Prototypen; die meisten Nutzer von Pay As You Go waren bereits in Produktion. Diese beiden Gruppen landen meist an unterschiedlichen Stellen. Deshalb haben wir getrennte Leitfäden für die Serverless-Alternative und die verwaltete Cloud-Alternative geschrieben.
Wo ConnectMQ ins Bild passt
ConnectMQ ist eine verwaltete MQTT-Plattform mit vergleichbaren Bereitstellungsoptionen und spricht Standard-MQTT 3.1.1 und MQTT 5.0, sodass Ihre bisherigen Client-Bibliotheken weiter funktionieren.
- Serverless-MQTT-Broker der ConnectMQ Cloud. Ein privater Broker auf einem geteilten, isolierten Multi-Tenant-Cluster, in wenigen Minuten einsatzbereit. Der kostenlose Serverless-Tarif unterstützt bis zu 25 gleichzeitige Verbindungen, QoS bis 1, Nachrichten bis 256 KB, Retained Messages und Wildcard-Abonnements und benötigt keine Kreditkarte. Serverless (Paid) erhöht dies auf bis zu 1.000 Verbindungen, QoS 2, Nachrichten bis 1 MB und Shared Subscriptions.
- Verwalteter Cloud-MQTT-Broker von ConnectMQ. Ein dedizierter Cluster (Dedicated), den ConnectMQ ausschließlich für Ihre Organisation betreibt, mit den Optionen BYOC (Bring Your Own Cloud) und Self Managed Enterprise für Anforderungen an Datenstandort und On-Premises-Betrieb.
- Standard-Endpunkte. Port 1883 (MQTT), 8883 (MQTT über TLS), 8083 (WebSocket) und 8084 (Secure WebSocket, Pfad
/mqtt) mit einem öffentlich vertrauenswürdigen Zertifikat von Let's Encrypt. - Integrierte Tools. Ein MQTT-Client im Browser, ein Live-Topic-Explorer, ein Dashboard, eine ISA-95-Geräteansicht für Ihren Unified Namespace (UNS) und Schwellwert-Alarme, sodass Sie migrierten Datenverkehr ohne zusätzliche Installation prüfen können.
Ein Migrationsplan in fünf Schritten
- Bestandsaufnahme. Erfassen Sie jeden Client, seine Client-ID, die genutzten Topics, QoS-Stufen, Retained Topics und wie er sich umkonfigurieren lässt. Nutzen Sie unsere HiveMQ-Migrationscheckliste als Vorlage.
- Ziel wählen und Zugangsdaten planen. Dimensionieren Sie den Tarif nach Ihrer Spitzenzahl an Verbindungen und legen Sie fest, wie Zugangsdaten und Client-IDs den Geräten zugeordnet werden.
- Privaten Broker anlegen und testen. Verbinden Sie einen Test-Client, veröffentlichen und abonnieren Sie mit Ihrer echten Topic-Struktur und messen Sie die Latenz von den Standorten Ihrer Geräte aus.
- Parallelbetrieb und Umzug in Wellen. Leiten Sie Datenverkehr zwischen altem und neuem Broker weiter, während Sie zuerst die Consumer und dann die Geräte in Gruppen umziehen. Details finden Sie unter HiveMQ-Migration ohne Ausfallzeit.
- Vor der Frist umschalten. Planen Sie einige Wochen Puffer vor dem 31. Dezember 2026 ein und löschen Sie den alten Cluster erst, wenn sich nichts mehr mit ihm verbindet.
Das vollständige Vorgehen Schritt für Schritt steht in unserem Migrationsleitfaden für HiveMQ Cloud Serverless, einen Wochenplan finden Sie im Migrationszeitplan für HiveMQ Serverless.
Warten Sie nicht bis zur letzten Woche
Migrationen dauern aus drei Gründen länger als erwartet: Geräte, die sich nicht aus der Ferne aktualisieren lassen, Retained-Zustände, die niemand dokumentiert hat, und Integrationen, die stillschweigend vom alten Hostnamen abhängen. Wenn Sie jetzt beginnen, haben Sie Zeit, diese Überraschungen zu entdecken, solange der alte Cluster noch läuft. Wenn Sie Ende Dezember beginnen, wird jede Überraschung zum Ausfall – in der Produktion womöglich zum Stillstand einer Linie.
Unter app.connectmq.com legen Sie in wenigen Minuten einen kostenlosen Serverless-Broker von ConnectMQ an und können noch heute einen Test-Client damit verbinden. Hintergründe zu den Betriebsmodellen finden Sie in unserem Leitfaden zum verwalteten MQTT-Broker und in der Übersicht zum Cloud-MQTT-Broker.
Häufig gestellte Fragen
Wann wird HiveMQ Cloud Serverless abgeschaltet?
HiveMQ stellt den Serverless-Tarif, sowohl Free als auch Pay As You Go, am 31. Dezember 2026 ein. Nach diesem Datum können sich MQTT-Clients nicht mehr mit Serverless-Clustern verbinden, und HiveMQ löscht die Cluster und ihre Daten endgültig.
Migriert HiveMQ meine Geräte automatisch?
Nein. HiveMQ gibt an, MQTT-Clients, Daten und Konfiguration nicht automatisch zu übertragen. Sie müssen jeden Client mit neuem Hostnamen, Port, neuen Zugangsdaten und TLS-Einstellungen umkonfigurieren.
Kann ich meine HiveMQ-Cluster-URL behalten?
Nein. Die URL eines Serverless-Clusters kann nicht auf einen neuen Broker übertragen werden. Damit künftige Wechsel einfacher werden, sollten Sie Hostname, Port und Zugangsdaten des Brokers in einer Konfiguration ablegen, die sich aus der Ferne aktualisieren lässt, statt sie fest in die Firmware zu kompilieren.
Was passiert mit Retained Messages und Sessions?
Sie werden zusammen mit dem Cluster gelöscht, ebenso Zugangsdaten und Berechtigungen. Lassen Sie Ihre Geräte ihren Zustand auf dem neuen Broker erneut veröffentlichen und neu abonnieren, und exportieren Sie vor der Frist alles, was Sie behalten müssen.
Ist ConnectMQ mit Clients kompatibel, die für HiveMQ Cloud entwickelt wurden?
Ja, bei Standard-Clients für MQTT 3.1.1 und 5.0. Sie ändern Host, Port, Zugangsdaten und Client-ID. Beachten Sie, dass ConnectMQ Client-IDs an die ausgegebenen Zugangsdaten bindet: Jedes Gerät verwendet seine ausgegebene Client-ID oder eine Variante davon mit _suffix.
