Cloudflare Docs
PubSub
Edit this page on GitHub
Set theme to dark (⇧+D)

MQTT compatibility

Pub/Sub supports the core parts of the MQTT v5.0 specification, and any MQTT v5.0 compatible client should be able to connect to a Pub/Sub Broker.

MQTT is one of the most pervasive “messaging protocols” deployed today. There are tens of millions (at least!) of devices that speak MQTT today, from connected payment terminals through to autonomous vehicles, cell phones, and even video games. Sensor readings, telemetry, financial transactions or mobile notifications and messages are all common use cases for MQTT, and the flexibility of the protocol allows developers to make trade-offs around reliability, topic hierarchy, and persistence specific to their use case.

Pub/Sub supports the following MQTT protocol features.

Protocol featureSupportedDetails
User Name & Password AuthenticationYesPub/Sub uses signed JSON Web Tokens in place of passwords for authenticating clients.
For more information on how authentication works, refer to Authentication and Authorization.
Mutual TLS (TLS Client Credentials)Not yet supportedNone yet
Enhanced AuthenticationNot supportedCommonly used to support Kerberos.
Delivery: At Most Once (QoS 0)Yes (default)This is the default QoS level in MQTT and relies on the underlying TCP connection and system for basic delivery guarantees and network-level re-transmissions.
Delivery: At Least Once (QoS 1)Not yet supportedThe broker will return a DISCONNECT with Reason Code 0x9B (QoS not supported) if a client attempts to send a message with an unsupported Quality of Service mode.
Delivery: Exactly Once (QoS 2)Not yet supportedThe broker will return a DISCONNECT with Reason Code 0x9B (QoS not supported) if a client attempts to send a message with an unsupported Quality of Service mode.
RetainNot yet supportedThe Broker will return a DISCONNECT Reason Code of 0x9A (Retain not supported) if a client attempts to send a message with the Retain bit set to any value other than zero (0).
Will MessagesNot yet supportedWill messages (sometimes called “Last Will” messages) are not currently supported and will be ignored by a broker.
Receive MaximumNot yet supportedOnly applies to QoS 1 and QoS 2 messages, which are not currently supported.
Single-level Wildcard (+ character)Not yet supportedThe broker will return a DISCONNECT Reason Code of 0x90 (Topic Name invalid) if a client attempts to subscribe to a Topic with a wildcard (+ or # character).
Multi-level Wildcard (# character)Not yet supportedThe broker will return a DISCONNECT Reason Code of 0x90 (Topic Name invalid) if a client attempts to subscribe to a topic with a wildcard (+ or # character).
Shared SubscriptionsNot yet supportedClients that attempt to SUBSCRIBE to a Shared Subscription, which are prefixed with a literal $share/ string, the server will return a DISCONNECT with Reason Code 0x9E (Shared Subscriptions not supported).
Subscription IdentifiersNot yet supportedClients that send a SUBSCRIBE packet with a Subscription Identifier will receive a DISCONNECT with Reason Code of 0xA1 (Subscription Identifiers not supported).
User PropertiesNot yet supportedUser Properties included in a PUBLISH packet will not be forwarded to subscribers.

​​ Permissions and IAM

During the beta period, users need the Super Administrator or Administrator permission to create, modify, or delete namespaces or brokers associated with an account.

In the future, Pub/Sub will have brokers-specific IAM permissions for:

  • Admin - Create, edit, and delete namespaces; create, edit, and delete brokers
  • User - Create, edit, and delete brokers (only); view namespaces but cannot create or delete namespaces
  • Viewer - View brokers. Can view config but cannot issue new credentials or modify config

Longer term, Pub/Sub will allow users to scope those permissions per namespace to better support isolated environments and distributed teams.