flespi MQTT broker - MQTT 5.0 compliant, secure, fast, and free

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).

Configuration
Host	mqtt.flespi.io
Port	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

Authorization
Username	Password	ClientID
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
Feature	Explanation
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.
MQTT limitations	Broker accepts messages with maximum payload size of 60MB Maximum outgoing (pending to client) messages queue size is 256MB Maximum QoS=1 unacknowledged messages queue size is 100MB Maximum single retain message size is 8MB If using multiple topics per one subscribe/unsubscribe request, broker accepts maximum 16 topics in it

MQTT 5.0 compliance checklist
Feature	Description	Status
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

MQTT broker

5 easy steps to start

MQTT client

Connection

Publish message

Subscription