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

MQTT broker

Fast, secure, and free public MQTT broker with MQTT 5.0 support, private namespace, WSS, ACLs, and rich API.

Also check out MQTT Board - our MQTT 5.0 client tool for debugging and testing.

The list of MQTT 5.0 client libraries this or another way maintained by Gurtam developers:

MQTT.js - MQTT client for Node.js and the browser

gmqtt - python asynchronous MQTT client

luamqtt - pure Lua MQTT client

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

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.

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

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

5 easy steps to start

Create free account on flespi.io

Create an authorization token

Connect to mqtt.flespi.io via TCP or WebSocket

Authorize with flespi token as user name

Subscribe/publish to any topic

MQTT client

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.

Connection

Username:

Client ID:

Publish message

Topic (please use valid MQTT topic, should not start from '/'):

QoS:

Message:

Subscription

Topic:

QoS:

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