HiveMQ Cloud Serverless is retiring: how to choose your next MQTT broker
Featured
Oct 20, 2026
3 min read
UllrAI

HiveMQ Cloud Serverless is retiring: how to choose your next MQTT broker

Understand the December 31, 2026 Serverless retirement, compare operating models, and prepare clients, state, and costs before a broker move.

MQTTMigrationOperations

HiveMQ Cloud Serverless Free and PAYG retire on December 31, 2026. New Serverless clusters are already unavailable. Existing projects must move their clients; the old cluster URL cannot transfer. HiveMQ says clusters and data will be permanently deleted after retirement. This concerns the Serverless plans, not all HiveMQ services. Check the official retirement notice, reviewed for this article on October 20, 2026.

Choose who will operate the broker

Begin with the operating model. HiveMQ offers eligible users a free self-managed Migration license. That gives an option to keep using HiveMQ on infrastructure you operate. A hosted service remains a different choice when you want someone else to handle broker operations.

Compare the complete workload and responsibilities, including credentials, topic permissions, support, regional needs and recovery. A small device count can conceal a busy gateway or a large number of downstream deliveries. Choose an alternative against your actual requirements rather than assuming all standard MQTT brokers behave identically.

The RunMQTT alternative overview explains our private broker workflow, plans and boundaries. RunMQTT is independent of HiveMQ and has no permanent free private plan. Its 7-day trial requires a payment method and cancellation before the displayed end to avoid the selected subscription charge.

Count the traffic that your bill counts

Connections are only one dimension. In RunMQTT, both publications and subscriber deliveries count, in rounded-up 512-byte units. Twenty devices publishing one small message per minute to one subscriber consume about 1.73 million units over 30 days. Starter's 100-connection ceiling does not make that workload fit its 1-million-unit allowance.

Use the capacity calculator, then check feature needs. Retained messages and QoS 2 require Growth or Scale. Monthly quotas do not promise a particular burst rate, offline queue duration or subscription count. Check the billing guide and agree required operational limits before committing.

A new address is not a state transfer

Inventory applications and firmware that must receive the replacement hostname, credentials and TLS settings. Treat hard-coded endpoints and devices that may remain offline for weeks as early migration risks.

Rebuild access rules and test denials. Recreate subscriptions on the new broker. Decide how to republish current state, recover outstanding business events and coordinate command publishers. Existing persistent sessions, offline queues and in-flight exchanges are not moved by reusing the same Client ID. A duplicate-tolerant consumer still needs an explicit cutover plan.

For retained-dependent clients, test both the replayed value and packet behavior. RunMQTT has documented a retained packet-flag limitation; review sessions and delivery and validate your application before accepting the move.

Start with one representative client

Follow the step-by-step migration guide, run its local verifier using synthetic data, and test normal traffic, restarts, network interruption and permissions. Follow the ESP32 and Node-RED guide or the Home Assistant acceptance checklist for client-specific checks.

Move a small batch before the rest of the fleet. Keep the source available during a defined rollback window and verify every required backend as well as devices before deleting the old cluster. Save the topic and policy inventory, keep endpoint settings updateable, and make applications able to recover from a fresh session. Those practices reduce the cost of the next infrastructure change too.

Compare the production path

Review the production controls and cost model before choosing an operating path.