Build Real-Time MQTT Messaging with Cloudflare Pub/Sub (2026)

Cloudflare Pub/Sub is actually a client-side technology, not a server-side one, despite its name.

Let’s see it in action. Imagine you have a fleet of IoT devices, each running a small JavaScript application using Cloudflare Workers. These Workers can subscribe to specific topics. When a message is published to a topic, Cloudflare’s edge network routes that message directly to all subscribed Workers within milliseconds.

Here’s a simplified wrangler.toml configuration for a Worker that subscribes to a topic:

name = "mqtt-subscriber"
main = "src/index.ts"
compatibility_date = "2023-10-20"

[triggers]
crons = ["*/5 * * * *"] # Example: run every 5 minutes

And here’s a snippet from the Worker’s src/index.ts file, demonstrating how to subscribe and handle incoming messages:

import { serve } from 'cloudflare:workers';

// Assume 'pubsub' is globally available in Cloudflare Workers context
// and is initialized elsewhere or injected.

export default {
  async fetch(request: Request): Promise<Response> {
    // This Worker acts as a subscriber.
    // The actual subscription happens implicitly when the Worker is deployed
    // and configured to listen for specific topics, often via a dashboard or API.
    // For demonstration, we'll simulate receiving a message.

    // In a real scenario, Cloudflare's infrastructure would push messages to this Worker.
    // We can't directly "subscribe" in a client-side script that runs on demand.
    // The subscription is managed by Cloudflare's edge, and your Worker *becomes* a subscriber endpoint.

    if (request.method === 'POST' && request.url.endsWith('/publish')) {
      const message = await request.json();
      console.log('Received message:', message);
      // Process the message here
      return new Response('Message received', { status: 200 });
    }

    // This is a placeholder for the actual Worker logic that might be triggered by Pub/Sub.
    // In a real application, you wouldn't typically handle incoming Pub/Sub messages via HTTP POST.
    // Cloudflare's internal routing delivers them to your Worker.
    return new Response('Worker is running. Subscribe to topics via Cloudflare dashboard.', { status: 200 });
  },
};

// To publish a message, another Worker or service would use the Cloudflare API:
// fetch('https://api.cloudflare.com/client/v4/accounts/{ACCOUNT_ID}/pubsub/publish', {
//   method: 'POST',
//   headers: { 'Authorization': 'Bearer {API_TOKEN}' },
//   body: JSON.stringify({
//     topic: 'my-iot-topic',
//     message: { temperature: 25, humidity: 60 }
//   })
// });

The problem Cloudflare Pub/Sub solves is the need for low-latency, real-time communication between distributed clients without managing complex broker infrastructure. Traditional MQTT brokers require you to provision, scale, and maintain servers, which can be a significant operational burden. Cloudflare Pub/Sub leverages their global edge network to handle message distribution.

Internally, when a Worker is designated as a subscriber to a topic, Cloudflare associates that Worker instance with the topic. When a message is published via the Cloudflare API, Cloudflare’s edge locations identify which Workers are subscribed to that topic. The message is then asynchronously routed to the relevant Worker instances. This routing is highly optimized, often delivering messages within tens of milliseconds. The "client-side" aspect means that the subscribing endpoints are your Workers, running on Cloudflare’s edge, rather than a dedicated server you manage.

The exact levers you control are primarily the topics you define and the Workers you deploy to subscribe to them. You can also control the publishing mechanism, typically via the Cloudflare API, specifying the topic and the message payload. The pubsub object, if available in the Worker context, might offer programmatic ways to interact with Pub/Sub, but the core management is often done through Cloudflare’s dashboard or API.

A common misconception is that you need to explicitly "connect" your Worker to a Pub/Sub service like you would with a traditional MQTT client. Cloudflare’s model is more declarative: you define your topics, and your Workers are automatically provisioned to receive messages for those topics when deployed. The underlying infrastructure handles the persistent connections and message queuing.

The next concept you’ll likely explore is handling message ordering and ensuring exactly-once delivery semantics in a distributed system.