Managed hosting from
£25/month equivalent +VAT
Small resource profile: 1 vCPU, 2 GB RAM, 10 GB SSD storage. Typically suits device fleets and telemetry feeds into your own applications. Billed hourly against our rate card with no commitments; deployment, upgrades, daily backups, monitoring, SSL and UK hosting included, with no per-user fees. How our pricing works
A broker for your devices, without the per-message meter
MQTT is how devices, sensors and services talk when bandwidth is scarce and connections are unreliable. The cloud IoT platforms will happily carry those messages and bill you per million of them, per connection-minute and per rule fired. Node runs Eclipse Mosquitto, the most widely deployed open source MQTT broker, in your own tenant on UK infrastructure, for a flat monthly rate whatever it carries.
What Mosquitto is
Eclipse Mosquitto is an open source message broker implementing MQTT, the publish and subscribe protocol that has become the default for device and telemetry messaging. Devices publish messages to topics; anything that cares about those topics subscribes to them. Publishers and subscribers never need to know about each other, which is what makes it a good fit for fleets that change shape over time.
MQTT itself is a genuine standard rather than a vendor protocol: MQTT 3.1.1 was ratified as an OASIS Standard in 2014 and published as ISO/IEC 20922 in 2016, and MQTT 5.0 became an OASIS Standard in 2019. Mosquitto speaks 5.0, 3.1.1 and 3.1. In the Eclipse Foundation's 2024 IoT and Embedded Developer Survey, MQTT led industrial IoT protocols at 56% adoption among roughly 750 developers surveyed, up from 49% the year before.
Mosquitto is a Mature project of the Eclipse Foundation, dual-licensed under the Eclipse Public License 2.0 and the Eclipse Distribution License. It is a Docker Official Image with more than 600 million pulls. Home Assistant ships it as its official MQTT broker add-on and Zigbee2MQTT names it the recommended broker, which is a fair summary of its standing: when a project needs a broker that simply works, this is the one it reaches for.
What we run, and what it does not do yet
We would rather set the boundaries out here than let you find them after you have bought.
Devices connect over MQTT on WebSockets, on port 443. Every public route into our platform runs through an encrypted tunnel from our edge, which means there is no raw public MQTT port to point a device at. We publish a TLS-secured WebSocket endpoint instead. Every current MQTT client library supports this, and port 443 has the practical advantage of working from restrictive networks without a firewall change. Native MQTTS on port 8883 runs inside your tenant and over a private link to your own site, but it is not published on the public internet today. If you have devices that speak only raw MQTT and cannot reach us privately, say so before you buy.
There is no per-topic access control yet. Every valid credential on your broker can currently read and write any topic. The broker is private to your tenant, so this is about separation between your own devices and people, not about exposure to anyone else. But if one fleet must not be able to read another's data, that is a conversation to have before you deploy, not after.
It is a single instance, not a cluster. Mosquitto is a single-threaded broker with no clustering, which is a known and fair criticism of it at very large scale. We run one instance per tenant on a backed-up volume. For the message rates this product is sold for that is the right trade; if you are heading for millions of concurrent connections, MQTT is still right but Mosquitto probably is not, and we would rather tell you.
Metrics are not in our dashboards yet. The broker publishes its own statistics and the collector for them is written but not switched on. We are not going to claim observability we have not shipped.
Why a managed broker instead of a metered cloud service
Flat cost instead of a meter you cannot forecast. You pay for the resources the broker runs on, from our published rate card, no matter how many messages cross it. Metered services charge per million messages, per connection-minute and per rule fired, with messages counted in fixed-size increments so a slightly larger payload silently doubles the count.
Your telemetry stays in your tenant. Device and sensor data is more revealing than it looks: occupancy, energy use, production rates and movement patterns are all inferable from it. It stays on UK infrastructure in your own namespace under an Article 28 data processing agreement.
Standard MQTT, so nothing is locked in. Any MQTT client works against it and the broker can bridge to another broker. There is no proprietary SDK, device shadow format or rules language to rewrite if you leave.
Credentials your team controls. Each workspace member issues, rotates and revokes their own MQTT login from the portal, with every action audit-logged, rather than raising a ticket with us.
How it compares
| Metered cloud IoT services | Mosquitto, managed by Node | |
|---|---|---|
| Billing | Per million messages, per connection-minute, per rule action | Flat monthly rate from the published rate card |
| Message accounting | Counted in fixed increments, so payload size drives the bill | Not counted |
| Protocol support | Varies by vendor; some support only MQTT 3.1.1 | MQTT 5.0, 3.1.1 and 3.1 |
| Data location | Vendor region and account | Your tenant, UK infrastructure, Article 28 DPA |
| Portability | Vendor SDKs, device shadows and rules engines | Standard MQTT and broker bridging |
| Scale ceiling | Very high, managed by the vendor | Single-instance broker, sized to your fleet |
Published prices as of July 2026, for the shape rather than a like-for-like total: AWS IoT Core in the Europe (London) region bills $1.20 per million messages metered in 5 KB increments, plus $0.096 per million connection-minutes, plus $0.18 per million rules triggered and again per million actions executed; its free tier lasts twelve months from account creation rather than indefinitely. Azure IoT Hub in UK South starts at £7.58 per unit per month for 400,000 messages a day, counted in 4 KB blocks, and supports only MQTT 3.1.1 (Microsoft states plainly that it is not a full-featured MQTT broker). HiveMQ Cloud starts from $0.34 per hour plus $0.80 per million messages. EMQX serverless bills $2.00 per million session minutes plus traffic and rule actions, rounding any sub-minute connection up to a full minute.
For context on how this market treats customers: CloudMQTT closed to new signups on 1 May 2024 and shut down entirely on 27 January 2025, and its customers had to move. A broker running on standard MQTT in your own tenant is not exposed to that decision being made for you.
Where it fits with the rest of your stack
A broker is only useful for what it feeds. In the same tenant and on the same private network you can subscribe Home Assistant to it for dashboards, automations and device control, which is the pairing we most often deploy. Route events into n8n to raise a ticket or notify a team when a threshold is crossed. Where you need a durable, replayable log of every event rather than a live message bus, Apache Kafka is the right tool and the two work well together. Build reporting over the history with Metabase or Apache Superset.
How Node runs Mosquitto for you
Deployment: deployed from your portal into your own tenant with your hostname and certificate, a TLS WebSocket endpoint for devices, persistence on a backed-up volume, and your first credential issued.
Upgrades and maintenance: we track upstream releases and keep the broker and the platform underneath it patched.
Backups: the broker's persistence volume is covered by your tenant's backup schedule alongside everything else we run for you.
Support: our team is available when a device fleet stops reporting and you need to know whether the problem is the broker, the network or the device.
Where it stands: this is a generally available application on our platform, supported like everything else we run. Per-topic access control and broker metrics in our dashboards are both still to come, and it runs as a single instance rather than a cluster. Those are stated above rather than buried here, and if any of them bear on what you are building, raise it with us before you deploy.
Metered messaging punishes the useful deployment: a handful of devices sending a message a day costs almost nothing on a metered IoT service, which is exactly why the pricing looks reasonable when you evaluate it. The bill arrives later, when the fleet has grown, the sample rate has gone up and someone has added a rules action per message. A managed broker is a flat, predictable rate-card cost for the resources it runs on, with your telemetry staying in your own tenant in the UK. See pricing for how our flat rates work.
Open source provenance
Mosquitto
is
EPL-2.0 OR BSD-3-Clause
software maintained upstream
(source, ref v2.0.21).
Node provides managed hosting, configuration and support. We are not the publisher.
- Hosting for paying customers: permitted under this licence.
Adoption and community
11.1k+ GitHub stars Eclipse Mosquitto is a Docker Official Image with over 600 million pulls, and a Mature project of the Eclipse Foundation. Home Assistant ships it as its official MQTT broker add-on and Zigbee2MQTT names it as its recommended broker. In the Eclipse Foundation's 2024 IoT and Embedded Developer Survey, MQTT led industrial IoT protocols at 56% adoption among the roughly 750 developers surveyed.
“A standalone MQTT broker like Mosquitto is rock solid, had 2 minor updates this year, and could run on the most minimal of hardware/LXC.”
Hacker News
“+1 on paho-mqtt for python and mosquitto. It has been rock solid and a joy to develop against.”
Hacker News
“Pretty rock solid and easy to diagnose issues via mqtt tools.”
Hacker News
Quotes are from public community discussions, linked to their original sources.
Frequently asked questions
How do devices connect to the broker from outside your network?
Over MQTT on WebSockets, secured with TLS, on the standard HTTPS port. Every public route into our platform runs through an encrypted tunnel from our edge, so we publish a WebSocket endpoint rather than a raw MQTT port on the public internet. Any current MQTT client library speaks MQTT over WebSockets, and using port 443 means devices on restrictive networks connect without a firewall change. Native MQTTS on port 8883 is available inside your tenant and across a private link to your site, but it is not published publicly today. If you have devices that can only speak raw MQTT and cannot be reached privately, tell us before you buy.
What are the credentials, and is it single sign-on?
It is not, and it should not be. MQTT clients are unattended devices, not people with browsers, so a browser sign-on flow does not apply to them. Instead each member of your workspace can create their own MQTT username and password from the portal, and revoke or rotate it there. Every issue, reveal and revocation is recorded in the audit log.
Can we restrict which topics a credential can publish or subscribe to?
Not yet, and this is the most important thing to know before you deploy. Today every valid credential on your broker can read and write every topic, including the broker's own statistics topics. Your broker is private to your tenant, so this is a question of separation between your own devices and users rather than exposure to anyone else, but if you need one device fleet to be unable to read another's data, we need to talk first. Per-topic access control is a documented next step and we will build it against a real requirement.
Is anything lost if the broker restarts?
Retained messages and subscription state persist to a volume that is backed up on your tenant's schedule. Beyond that, be aware of how MQTT brokers of this kind behave: Mosquitto is a single process writing its persistence file periodically, so an abrupt crash can lose recently acknowledged messages. If you need a guaranteed durable log of every event, that is a different tool, and we would point you at Apache Kafka for it rather than sell you the wrong thing.
How does this compare on cost with AWS IoT Core or Azure IoT Hub?
The honest answer is that the meters are not comparable. The hyperscalers bill per million messages, per connection-minute, and per rules-engine action, with messages counted in 5 KB or 4 KB increments, so an identical workload produces very different bills depending on message size and chattiness. We bill a flat monthly rate for the resources the broker runs on, whatever it carries. For a chatty fleet that is usually cheaper and always more predictable; for a handful of devices sending a message a day, a metered service may well cost less. Send us your message volume and rate and we will work it through with you rather than guess.
What state is this in today?
Generally available: you can buy it, deploy it from your portal and put real device traffic through it, and it is supported like everything else we run. Two things are deliberately not in it yet, and we would rather you heard them from us than found them later. There is no per-topic access control, so every credential on your broker can read and write every topic. And broker metrics are not in our dashboards yet, so we watch the pod and the volume rather than message rates and connection counts. It also runs as a single instance rather than a cluster. If any of those matter for what you are building, talk to us before you deploy.
Talk to us about MQTT.
Tell us what your devices speak, how many there are and how often they report, and we will tell you whether a managed broker is the right shape and what it will cost.