Order confirmed, courier two stops away, price alert triggered: your backend publishes the event once, and every browser tab and mobile app that subscribed gets it instantly over MQTT on secure WebSockets — no polling, no socket server of your own.
No card required
PUBLISH orders/ord-58213/status
{"status":"out_for_delivery","eta":"14:35","stops_away":2,"courier":"c-221","ts":"2026-10-22T14:02:51Z"}QoS 1 · TLS 8883 · PUBACK
Apps that poll an API every few seconds load your backend and still feel slow. A home-made WebSocket service means writing reconnect logic, fan-out and horizontal scaling yourself — and a user who walks from Wi-Fi onto mobile data still misses the one update that mattered.
The order service, dispatch system or alerting job publishes a small JSON event to a topic such as orders/{order id}/status whenever something changes.
Web apps connect with MQTT.js over secure WebSockets, mobile apps with a native MQTT client, and subscribe to the topics that belong to that user.
ConnectMQ delivers each event to every subscribed client at once — the customer’s phone, their open browser tab and your support agent’s console.
The app moves the order tracker, updates a badge or shows an in-app banner. For apps that are closed, your own push service still sends through APNs and FCM.
MQTT over secure WebSockets lets browsers connect directly, to the same broker your backend reaches over MQTT with TLS.
Username/password authentication and per-topic ACLs keep a client to its own subtree, such as users/{id}/#, and let only your backend publish to it.
Retained messages hand the latest order status to an app the moment it subscribes; persistent sessions with QoS 1 deliver events missed during a short drop.
QoS 0 for frequent courier location ticks where only the newest matters, QoS 1 for status changes and alerts that must arrive.
orders/ord-58213/status (retained)
orders/ord-58213/courier/location
users/u-90417/notifications
users/u-90417/badge (retained)Both — MQTT runs over WebSockets. A plain WebSocket is only a pipe: you still have to build topics, fan-out, reconnect handling and delivery guarantees. MQTT over secure WebSockets adds publish/subscribe, QoS, retained messages and Last Will on top, and ConnectMQ runs the server side.
For apps that are open or in the foreground, yes: MQTT delivers updates faster and with richer data. When an app is closed, iOS and Android limit background connections, so keep APNs and FCM for those. A common pattern is to publish once and let a small service forward selected events to push.
Use MQTT.js: connect to your ConnectMQ secure WebSocket endpoint, subscribe to the user’s topics and update state on each message. Never ship a credential with broad permissions in front-end code — give browser clients credentials whose ACL only allows reading their own topics.
Start on the Free plan — no card required — connect your first devices today and upgrade when you go live.
