Fast, secure, and free public MQTT broker with MQTT 5.0 support, private namespace, WSS, ACLs, and rich API.
You can follow flespi MQTT broker changelog on flespi forum.
The list of MQTT 5.0 client libraries this or another way maintained by Gurtam developers:
Also check out MQTT Board - our MQTT 5.0 client tool for debugging and testing.
Perform and scale better with MQTT 5.0
The number of sensors in the IoT and M2M systems is skyrocketing. The flespi team has been working hard to add the MQTT 5.0 specification support into the broker to enhance the productivity and scalability of your projects. Most MQTT 5.0 features already implemented! Let us know if you need something that we are missing.
Be the boss in the isolated MQTT namespace
Each flespi user operates in an isolated MQTT topics namespace. It's only you who chooses how to name messages topics and what kind of hierarchy to use.
Operate the broker via REST API
Manage sessions, publish messages, read and delete retained messages, and access logs via a flexible REST API.
Fine-tune access to topics
We take security and privacy seriously. To make sure each subscriber gets the data they need but cannot cause harm by their negligence or accidental actions, we devised a flexible access control system. It allows creating tokens with different ACLs and lifetime settings to finely customize what different parties can access within a topic.
Use shared subscriptions for easy load-balancing
When incoming messages start heavily bombarding the handler of your business app, you might lose data. We don’t want that! flespi offers shared subscriptions and even their extended sticky version to spread the load across multiple service workers in a smart manner.
Never hit the speed limit
It’ frustrating when your technological partner can’t live up to your needs. We don’t want to be a bottleneck as your business grows. flespi MQTT broker can receive one million messages per second and send three million messages per second. Impressive, huh?
Stay safe with SSL-protected MQTT and WS connections
We care about the security of the messages you entrust to our MQTT broker. That’s why we support MQTT over SSL and MQTT over Secure WebSocket. Also, you can create an isolated namespace with any name (except /flespi).
MQTT over TCP: 8883 (SSL) or 1883 (non-SSL)
MQTT over WebSockets: 443 (SSL) or 80 (non-SSL)
|MQTT version||3.1, 3.1.1, 5.0|
|QoS supported||QoS 0, QoS 1, QoS 2|
|REST API||Yes, it's possible to publish messages, read and delete retained messages, manage connected and offline sessions, and access broker logs via MQTT broker REST API|
|ACL||Yes, topics access is adjustable via token ACL setting|
|Shared subscriptions||Yes, implemented according to MQTT 5.0 specification. Allows load-balancing published messages between multiple subscribers in the same shared group with sticky distribution scheme on top of this|
|Retained messages||Yes, with limited storage according to restrictions|
|Logs||MQTT broker logs available via either REST API or MQTT|
|your flespi token||not used *||any|
|* Alternatively, if it's more convenient and secure for your client library, you can put a flespi token into the Password field instead of Username.|
|flespi MQTT broker specifics|
|Topics selectors||When using HASD database for storage purposes or in general
to achieve maximum performance on large volumes we introduced topic selectors in subscriptions.
Here's how it works: if you subscribe to 'topic/a,b/e,f/field', you end up with retained and online messages from 'topic/a/e/field', 'topic/b/e/field', 'topic/a/f/field', 'topic/b/f/field'.
The logic of the subscription is similar to 'topic/+/+/field' but the first '+' wildcard will filter out all topics except 'a' and 'b' and the second '+' will filter out all topics except 'e' and 'f'.
|Wildcard deletion of retained messages||If you publish a message with an empty payload to a topic that contains wildcards ("#" or "+"), flespi will perform bulk deletion of retained messages that match the published topic mask.|
|Shared group sessions storage||If the message arrives at the shared group but no sessions are online, for clean=false or non-zero expiration timeout sessions that were previously subscribed to this shared group, the message will sit in the storage until such sessions connect again. As shared groups are mostly used for load balancing, this feature prevents any data loss when all such sessions are offline for whatever reason.|
|Sticky shared subscriptions||
In some cases, it is desirable to redirect specific topics to the same subscriber within the shared group (unlike in a traditional use for load balancing).
This approach allows for implementing more efficient cache between shared subscribers.
With 'sticky' shared subscriptions, you can specify the initial word position and words count to calculate the topic fingerprint, e.g. '$share/group_name:from:count/...' (a simpler form is '$share/group_name:count/...' for zero-based 'from' topics). The broker will calculate the topic fingerprint and assign it and future topics with the same fingerprint to the same subscriber.
|"timestamp" user property (publish)||If not set by the publisher flespi broker will attach this property to the published message with the current UNIX time value. This property is used to sort which message will be the last in retained storage. In case broker received few messages with same timestamp from one connection, special user property "seqno" will be attached to messages to distinguish the latest and more actual one.|
|"token_id" user property (publish)||Every message published by the user is signed by the broker with a "token_id" user property containing the ID of the flespi token used by the sender for authorization. This property can be used on receivers to distinguish message senders.|
|"modified_since" user property (subscribe)||If valid value is specified, the subscriber will receive only newer retained messages than the given UNIX timestamp.|
|"cid" user property (publish/subscribe)||ID of flespi account that originally generated this message. Upon subscribe it is possible to subscribe only to messages available to specified flespi account ID. This feature is useful only for Commercial Plan users which split MQTT operations into multiple subaccounts.|
|CONNACK user properties||Session connection acknowledgment packet contains additional information about the session including ACL settings for the session authorization token and its current subscriptions.|
You may play with flespi MQTT broker with this mqtt.js based MQTT client or try full-featured MQTT client tool. Feel free to open multiple instances simulateniously — e.g. you may publish messages from one tab and subscribe to them from other tab. You may also subscribe to everything, e.g. # — this token provides read-only access to a couple of GPS trackers installed on vehicles that periodicaly update their positions.
|MQTT 5.0 compliance checklist|
|Shared groups||Load-balancing; delivering messages to a single subscriber from the group|
|Message expiry interval||Limiting the messages TTL (for both queued and retained)|
|Response topic||Subscriber response to received topic (executing commands and getting response)|
|Receive maximum||Client limits the number of inflight messages sent by the broker|
|Maximum packet size||Client limits the max size of messages sent by the broker|
|Topic alias||Replacing a topic name with the 2-byte index (to save traffic)|
|Will delay interval||Delaying the generation of a will message|
|Subscription identifier||Client specifies own index upon subscription; broker specifies according to which subscription the message is sent to the client|