WebSockets and MQTT are first-class transports in Air Pipe — pub/sub with wildcards, presence, history-rewind and retained messages, on the same config that already serves your HTTP APIs. The difference from a realtime relay: the same connection can run your pipeline on every message — validate it, enrich it, write it to a database, call an API — and gate channels with your own auth.
WebSockets and MQTT, both first-class
One product speaks both. Browsers and apps connect over WebSockets; devices and IoT fleets connect over MQTT with real broker semantics — wildcards, retained messages, persistent sessions and QoS 0/1/2. Both run on one in-process broker per node, so you're not operating a separate message bus.
WebSocket channel API — subscribe, publish, wildcards, retained
Full MQTT broker per node — sessions, QoS 0/1/2, retained
Global reach — nodes are geo-routed and fan out across a mesh
Pub/sub with presence, history and retain
The WebSocket channel API has the features you'd otherwise buy a dedicated realtime service for. Presence tracks who's on a channel with join/leave events and a cross-node member list. History lets a subscriber rewind the last N messages on connect. Retained hands every new subscriber the last value immediately. MQTT reaches the same delivery guarantees the native broker way — persistent sessions, QoS 1/2 and retained messages.
Presence — enter/leave events and a live member list
History-rewind — replay the last N messages on subscribe
Retained — last value delivered on (re)subscribe, cross-node
Run your logic on every message
This is the part a relay can't do. A realtime service moves bytes between clients; Air Pipe can run your config on each message — assert on it, transform it, write it to Postgres or MongoDB, call an upstream API — before it fans out. Presence and history are queryable in your pipeline too, so a join or a replayed event can drive real backend logic, not just a client-side update.
Realtime for your website's users — no org key in the browser
Your app's end-users connect with their own JWT, not an org API key. A browser opens a WebSocket with ?token=<jwt>; Air Pipe verifies the token against your JWKS and gates each channel by the user's claims — with your pipeline logic as the channel ACL. Per-user identity and channel-level access control, and no secret ever shipped to the client.
Browser end-users authenticate with their own JWT via ?token=
Channels gated by JWT claims and your own pipeline logic
No org API key ever ships to the browser
One vendor, managed or self-hosted
Transport, per-user auth, the compute that runs on each message, and billing are one product with one bill — not a relay plus your own backend plus the glue between them. Run it on our managed cloud or self-host the same single binary; realtime runs on nothing-shared infrastructure either way, with no external broker or Redis to operate.
Frequently asked questions
Does Air Pipe support both WebSockets and MQTT? Yes — both are first-class transports on the same platform. Browsers and apps typically use the WebSocket channel API; devices and IoT fleets use MQTT with full broker semantics (wildcards, retained messages, persistent sessions and QoS 0/1/2). Both run on one in-process broker per node, so there's no separate message bus to operate.
How is this different from Ably or Pusher? On the realtime fundamentals — pub/sub, presence, history, retained messages, delivery and global reach — Air Pipe is at parity. The difference is what happens to a message: a relay moves it between clients, while Air Pipe can run your config on it — validate, enrich, write to a database, call an API — and use your own logic as the channel ACL. It's transport, per-user auth, compute and billing in one vendor rather than a relay you wire your own backend behind.
Can my website's users connect without an API key? Yes. Browser end-users connect over WebSockets with their own JWT passed as ?token=, which Air Pipe verifies against your JWKS and uses to gate channels by the user's claims — no org API key is shipped to the browser. MQTT connections still authenticate with an org key, so use WebSockets for browser end-users today.
What does “run your logic on the message” mean? The same connection that carries realtime traffic can run an Air Pipe pipeline on each message before it fans out — asserting on it, transforming it, writing it to Postgres or MongoDB, or calling an upstream API. Presence and replayed history events are available to that pipeline too, so realtime events can drive real backend logic rather than only client-side updates.
Can I self-host realtime? Yes. WebSockets and MQTT run on the same single self-hosted binary as the managed cloud, on nothing-shared infrastructure — there's no external broker or Redis to run alongside it. Self-hosted realtime connections aren't billed; managed connections draw request units for connection time and throughput.