MQTT broker

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

Check broker changelog to track the development progress of this wonderful service.

Join in to establish MQTT connectivity with flespi

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. Check our MQTT 5.0 compliance checklist for details.

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 message 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’s 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.

Do testing & debugging easily

Our MQTT Board MQTT 5.0 client tool makes playing with MQTT connections handy thanks to a well thought-out interface and functionality.

5 easy steps to setup flespi MQTT broker

1
Create free account on flespi.io
2
Create an authorization token
3
Connect to mqtt.flespi.io via TCP or WebSocket
4
Authorize with flespi token as user name
5
Subscribe/publish to any topic
flespi MQTT broker 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
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. For MQTT clients with a 16-byte limit on username or password fields, you may use special authorization.
** ClientID should be unique for each connection. If you have few connections with the same client id they will be disconnected by the Broker in round robin fashion.
flespi MQTT broker specifics
Feature Explanation
Topics names Use any topic names except those starting with "flespi/...".
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.
"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.
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.
Number of subscribers to a topic Add a count_subscribers user property with 1 payload and publish a QoS(1) message. You can then find the subscribers_count user property in the received PUBACK.
Message filtering Subscription filter format:
$filter/cid={cid filter}&modified_since={timestamp}&payload={expression}&message={expression}/{filter topic}.
  • cid - allow only messages from specific subaccount ID.
  • modified_since - allow only messages with timestamp above specified value.
  • payload - apply expression to filter message by its payload. Can be used to filter both simple payloads like string, number, boolean or complex payloads such as JSON objects and arrays. More details and examples here.
  • message - apply expression to filter message by its timestamp, topics, user properties or payload(string only). Can be used to filter both simple payloads like string, number, boolean or complex payloads such as JSON objects and arrays. More details and examples here.
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 16MB
  • Maximum number of levels in the topic is 24
  • If using multiple topics per one subscribe/unsubscribe request, broker accepts maximum 64 topics in it

MQTT client

You may play with flespi MQTT broker via this mqtt.js-based MQTT client or try fully-featured MQTT client tool. Feel free to open multiple instances simultaneously — 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 periodically update their positions.

Connection


Publish message


Subscription

MQTT 5.0 client libraries

Here are some MQTT client libraries created or complemented by Gurtam developers:

  • MQTT.js — MQTT client for Node.js and the browser

  • gmqtt — Python asynchronous MQTT client

  • luamqtt — pure Lua MQTT client

MQTT 5.0 compliance checklist
Feature Description Status
Shared groups Load-balancing; delivering messages to a single subscriber from the group done
Message expiry interval Limiting the messages TTL (for both queued and retained) done
Response topic Subscriber response to received topic (executing commands and getting response) done
Receive maximum Client limits the number of incoming messages sent by the broker done
Maximum packet size Client limits the max size of messages sent by the broker done
Topic alias Replacing a topic name with the 2-byte index (to save traffic) done
Will delay interval Delaying the generation of a will message done
Subscription identifier Client specifies own index upon subscription; broker specifies according to which subscription the message is sent to the client done
Join in to establish MQTT connectivity with flespi