MIGRATION VON HIVEMQ CLOUD SERVERLESS

MQTT-Projekt umziehen. Weiterhin verwaltet betreiben.

HiveMQ Cloud Serverless Free und PAYG enden am 31. Dezember 2026. RunMQTT bietet private verwaltete Broker, eigene Gerätezugangsdaten und Topic-Richtlinien ab 15 USD pro Monat.

Ein neuer Endpunkt braucht einen Migrationsplan

Die Stilllegung betrifft Serverless Free und PAYG, nicht sämtliche HiveMQ-Dienste. Neue Serverless-Cluster sind bereits nicht mehr verfügbar.

Hostname, Zugangsdaten, Ports und TLS-Einstellungen aller betroffenen Clients aktualisieren. Die bisherige Cluster-URL lässt sich nicht auf einen anderen Broker übertragen.
Retained-Nachrichten und die Wiederherstellung der Anwendung gesondert planen. Sitzungen, Abonnements, Offline-Warteschlangen und laufende Zustellungen werden nicht automatisch übertragen.
HiveMQ bietet berechtigten Nutzern auch eine kostenlose Migration-Lizenz für den Eigenbetrieb an. Diesen Broker betreiben Sie selbst; das Betriebsmodell unterscheidet sich von einem gehosteten Dienst.
Die Umstellung vor dem 31. Dezember 2026 abschließen. Laut HiveMQ werden Serverless-Cluster und ihre Daten nach der Stilllegung dauerhaft gelöscht.
Offizielle HiveMQ-Mitteilung lesen

Angaben zur Stilllegung am 20. Oktober 2026 geprüft. RunMQTT ist unabhängig von HiveMQ.

Für Teams, die den Broker-Betrieb abgeben möchten

Kompatible MQTT-Clientbibliotheken und Topic-Strukturen weiterverwenden. Vor dem Produktivwechsel alle für die Anwendung erforderlichen Verhaltensweisen prüfen.

Ein privater verwalteter Broker

Einen isolierten Broker mit TLS und WSS nutzen, ohne einen Server zu betreiben oder das Heimnetz freizugeben. Die gemeinsame öffentliche Sandbox dient nur kurzzeitigen Tests.

Nachvollziehbarer Gerätezugriff

Widerrufbare Gerätezugangsdaten und wiederverwendbare Publish-/Subscribe-Richtlinien einrichten. Erlaubte und verweigerte Zugriffe bei der Migration erneut testen.

Verhalten und Kapazität gemeinsam bewerten

Alle Tarife enthalten MQTT 3.1.1, MQTT 5, QoS 0/1, TLS und WSS. Growth und Scale enthalten zusätzlich QoS 2 und Retained-Nachrichten. Die Retained-Kompatibilität vor der Migration zustandsabhängiger Anwendungen prüfen.

Tatsächliche Grenzen prüfen

Monatskontingente garantieren keine Spitzenrate, Abonnementanzahl, Region oder Offline-Speicherung. Hochfrequente Gateways, fest codierte Endpunkte, Integrationen und Vertragsanforderungen bitte vorab mit uns prüfen.

Kosten vor dem Flottenumzug berechnen

Preise in USD, zuzüglich anwendbarer Steuern. Veröffentlichungen und jede Empfängerzustellung zählen in aufgerundeten 512-Byte-Einheiten. Backend-Verbraucher zählen als Verbindungen.

Monatliche RunMQTT-Tarife
TarifMonatspreisGleichzeitige VerbindungenNachrichteneinheiten pro Monat
Starter15 $1001.000.000
Growth39 $2.00010.000.000
Scale89 $10.00050.000.000

Beispiel: Jedes Gerät veröffentlicht kontinuierlich eine Nachricht mit bis zu 512 Byte pro Minute an einen Empfänger, 30 Tage lang. Die Schätzung enthält keine weiteren Nachrichten und ist keine Leistungsmessung.

  • 10 Geräte: 864.000 Nachrichteneinheiten in 30 Tagen.
  • 20 Geräte: 1.728.000 Nachrichteneinheiten in 30 Tagen.
  • 100 Geräte: 8.640.000 Nachrichteneinheiten in 30 Tagen.

Berechtigte Konten erhalten einmalig 7 Testtage. Ein Zahlungsmittel ist erforderlich. Vor dem angezeigten Testende kündigen, um die Tarifgebühr zu vermeiden. Es gibt keinen dauerhaft kostenlosen privaten Tarif.

Vorbereiten, prüfen, umstellen

Mit synthetischen Daten und einem repräsentativen Client beginnen. Die Anleitung enthält ein lokales Prüfskript, eine Checkliste und clientspezifische Schritte.

  1. 01

    Last erfassen

    Geräte und Backend-Verbindungen, Nachrichtengrößen, Empfänger, gespeicherte Zustände, Abonnements und die Aktualisierung der Client-Konfiguration erfassen.

  2. 02

    Broker und Zugriffsregeln einrichten

    Tarif auswählen, Richtlinienvorlagen erstellen und RunMQTT-Gerätezugangsdaten ausstellen. Der bisherige HiveMQ-Hostname und die Zugangsdaten werden nicht übertragen.

  3. 03

    Repräsentative Clients testen

    TLS und WSS, erlaubte und verweigerte Topics, Neuverbindungen, QoS, Retained-Nachrichten und die tatsächliche Senderate prüfen. Eine erfolgreiche Verbindung allein reicht nicht aus.

  4. 04

    Schrittweise mit Rückfalloption umstellen

    Geräte und Backend-Verbraucher koordinieren, benötigte Zustände erneut veröffentlichen und Zustellung sowie Verbrauch überwachen. Den alten Cluster bis zur Abnahme behalten und vor seiner Stilllegung umstellen.

Für eine Migrationsbewertung ungefähre Verbindungen, Nachrichtenrate, Nutzlastgröße, Funktionen, Clientsoftware und Zieldatum angeben. Keine Zugangsdaten oder Kundennachrichten senden. Den Umfang der Unterstützung vor der Umstellung vereinbaren.

Fragen vor der Migration

Ist RunMQTT eine kostenlose HiveMQ-Cloud-Alternative?

Berechtigte Konten erhalten einmalig 7 Testtage. Ein Zahlungsmittel ist erforderlich. Vor dem angezeigten Testende kündigen, um die Tarifgebühr zu vermeiden. Es gibt keinen dauerhaft kostenlosen privaten Tarif.

Ist eine Migration ohne Ausfall oder Nachrichtenverlust möglich?

Das hängt von Endpunktaktualisierung, Geräteverfügbarkeit, Anwendungswiederherstellung und Zustellungssemantik ab. Schrittweise Umstellung und Rückfall testen; eine neue Broker-Adresse überträgt keine Warteschlangen und garantiert keine unterbrechungsfreie Zustellung.

Kann ich Home-Assistant- oder ESP32-Clients umziehen?

Standard-MQTT-Clients lassen sich für RunMQTT konfigurieren. Konkrete Software, TLS-Vertrauen, Topic-Zugriff, Abonnements, Retained-Zustände und Neuverbindungen müssen geprüft werden. Die Clientanleitungen enthalten Abnahmeschritte und bekannte Retained-Einschränkungen.

Wie erleichtere ich einen späteren Wechsel?

Endpunkte aktualisierbar halten, Topic- und Richtlinieninventar sichern und Anwendungen auf erneute Zustandsveröffentlichung und neue Sitzungen vorbereiten. Für TLS den RunMQTT-Hostnamen verwenden; ein eigener CNAME allein ergibt keinen gültigen Endpunkt unter eigener Domain. SLA, Region und Kontinuitätsanforderungen vor Vertragsabschluss besprechen.