HiveMQ is retiring its HiveMQ Cloud Serverless plan, including both Serverless Free and Serverless Pay As You Go clusters, on December 31, 2026. After that date MQTT clients can no longer connect to those clusters, and HiveMQ permanently deletes the clusters and their data. If your devices, dashboards or backend services connect to a hostname ending in hivemq.cloud on a Serverless cluster, you need a new broker and a migration plan before the end of the year.
This guide summarises what the HiveMQ Cloud Serverless end of life means in practice, what you can and cannot carry over, which options you have, and how to move to a private managed MQTT broker without interrupting your service. Every point about HiveMQ below is based on HiveMQ's own end-of-life documentation at the time of writing; always check the official page and the retirement email you received for the latest details.
What HiveMQ Announced
HiveMQ's documentation describes the retirement in a few clear rules:
| Topic | What HiveMQ states |
|---|---|
| Affected plans | HiveMQ Cloud Serverless Free and Serverless Pay As You Go clusters |
| New clusters | You can no longer create a Serverless cluster or upgrade a Serverless cluster to Pay As You Go |
| End-of-life date | December 31, 2026 |
| After the end-of-life date | MQTT clients can no longer connect to Serverless clusters |
| Data | HiveMQ permanently deletes all Serverless clusters and their data, including retained messages, client sessions, access credentials and permissions |
| Cluster URL | Cannot be transferred to a new broker |
| Automatic migration | None: clients, data and configuration are not moved for you |
| Migration offer | A free Migration license for the self-managed HiveMQ Enterprise Broker |
Until the end-of-life date you can still manage credentials and permissions, view connection details and delete your Serverless cluster. A deleted cluster cannot be recreated, so do not delete it until your clients run on the new broker.
What Stops Working on January 1, 2027
The practical impact depends on what is connected to your cluster:
- Devices and gateways that connect to
<cluster-id>.s1.eu.hivemq.cloud(or a similar Serverless hostname) will fail to connect and keep retrying. - Backend services such as data ingestion, rule engines or Node-RED flows that subscribe to the cluster will stop receiving data.
- Web dashboards that connect over secure WebSocket will show no live data.
- Retained messages and persistent sessions stored on the cluster will be gone, so the last-known state of each device must be rebuilt on the new broker.
Because the cluster URL cannot move, every client needs at least a new hostname and new credentials. That is the single most important fact for planning: the effort scales with the number of clients and how hard each one is to reconfigure. A web dashboard is a configuration change; a battery-powered sensor in the field may need a firmware update.
The Migration License, Briefly
HiveMQ offers eligible users a free Migration license for the self-managed HiveMQ Enterprise Broker. According to HiveMQ, it allows 100 concurrent connections and 100 messages per second for 12 months, needs no credit card, and then continues as a free Lab license with lower limits (currently 25 concurrent connections and 25 messages per second). You can claim it if your user account owned a Serverless cluster when the retirement was announced.
The key word is self-managed. With the Migration license you install, run, secure, patch and monitor the broker yourself, on your own server or Kubernetes cluster. That is a good fit for some teams and a significant new responsibility for others, especially those who picked Serverless precisely because they did not want to operate infrastructure. We compare both paths in detail in HiveMQ Migration License vs a Managed MQTT Broker.
Your Options After HiveMQ Cloud Serverless
| Option | Who operates the broker | Good fit when |
|---|---|---|
| Self-managed broker (for example with the HiveMQ Migration license) | You | You have operations capacity and want the broker on your own infrastructure |
| Another serverless MQTT service | The provider, on a shared cluster | You want the same "no servers" experience you had on Serverless |
| A dedicated managed MQTT broker | The provider, on a cluster just for you | You run production fleets and want isolation and predictable performance |
| Bring Your Own Cloud | The provider, inside your cloud account | Data must stay in your own cloud account |
Most Serverless Free users had small fleets and prototypes; most Pay As You Go users were already in production. Those two groups usually land in different places, which is why we wrote separate guides for the serverless alternative and the managed cloud alternative.
Where ConnectMQ Fits
ConnectMQ is a managed MQTT platform with the same kind of deployment choices, and it speaks standard MQTT 3.1.1 and MQTT 5.0, so the client libraries you already use keep working.
- ConnectMQ Cloud Serverless MQTT Broker. A private broker on a shared, isolated multi-tenant cluster, ready in minutes. The free Serverless plan supports up to 25 concurrent connections, QoS up to 1, 256 KB messages, retained messages and wildcard subscriptions, and needs no credit card. Serverless (Paid) raises this to up to 1,000 connections, QoS 2, 1 MB messages and shared subscriptions.
- ConnectMQ Managed Cloud MQTT Broker. A Dedicated cluster operated by ConnectMQ for your organisation alone, with BYOC (Bring Your Own Cloud) and Self Managed Enterprise options for data residency and on-premises requirements.
- Standard endpoints. Port 1883 (MQTT), 8883 (MQTT over TLS), 8083 (WebSocket) and 8084 (secure WebSocket, path
/mqtt) with a publicly trusted Let's Encrypt certificate. - Built-in tooling. An in-browser MQTT client, live topic explorer, dashboard, ISA-95 device view and threshold alert rules, so you can verify migrated traffic without installing anything.
A Migration Plan in Five Steps
- Inventory. List every client, its client ID, the topics it uses, QoS levels, retained topics and how it can be reconfigured. Use our HiveMQ migration checklist as a template.
- Choose the target and plan credentials. Size the plan to your peak connection count and decide how credentials and client IDs map to devices.
- Create and test a private broker. Connect a test client, publish and subscribe with your real topic structure, and measure latency from your device locations.
- Dual-run and move in waves. Relay traffic between the old and new broker while you move consumers first, then devices in batches. Details are in zero-downtime HiveMQ migration.
- Cut over before the deadline. Leave a buffer of several weeks before December 31, 2026, then delete the old cluster once nothing connects to it any more.
The full, step-by-step procedure is in our HiveMQ Cloud Serverless migration guide, and a week-by-week schedule is in the HiveMQ Serverless migration timeline.
Do Not Wait for the Last Week
Migrations take longer than expected for three reasons: devices that cannot be updated remotely, retained state nobody documented, and integrations that quietly depend on the old hostname. If you start now, you have time to discover those surprises while the old cluster still works. If you start in late December, every surprise becomes an outage.
You can create a free ConnectMQ Serverless broker in a couple of minutes at app.connectmq.com and point one test client at it today. For the broader background on hosting models, read our managed MQTT broker guide and the cloud MQTT broker overview.
Frequently Asked Questions
When does HiveMQ Cloud Serverless shut down?
HiveMQ retires the Serverless plan, both Free and Pay As You Go, on December 31, 2026. After that date MQTT clients can no longer connect to Serverless clusters, and HiveMQ permanently deletes the clusters and their data.
Will HiveMQ migrate my devices automatically?
No. HiveMQ states that it does not move MQTT clients, data or configuration automatically. You must reconfigure each client with a new hostname, port, credentials and TLS settings.
Can I keep my HiveMQ cluster URL?
No. The Serverless cluster URL cannot be transferred to a new broker. To make future changes easier, keep the broker hostname, port and credentials in configuration that you can update remotely instead of compiling them into firmware.
What happens to retained messages and sessions?
They are deleted together with the cluster, along with credentials and permissions. Have devices republish their state and resubscribe on the new broker, and export anything you need to keep before the deadline.
Is ConnectMQ compatible with clients built for HiveMQ Cloud?
Yes, for standard MQTT 3.1.1 and 5.0 clients. You change the host, port, credentials and client ID. Note that ConnectMQ binds client IDs to the issued credentials, so each device uses its issued client ID or a _suffix variant of it.
