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 without your org API key. A browser opens a WebSocket with ?token=<jwt>, verified against your JWKS, a shared secret, or a token Air Pipe mints for you — then channels are gated by the user's claims with your pipeline logic as the ACL. Or make an interface public and connections need no credential at all. MQTT works the same way — anonymous/public or org-authenticated — so the open model spans both transports, and it's multi-tenant-safe: anonymous only reaches interfaces you mark public.
WebSocket end-users bring their own JWT via ?token= — or a public interface needs no credential
Full auth ladder: open, Air Pipe-issued, shared-secret (HS256), or your JWKS (RS256/ES256)
MQTT too: anonymous/public interfaces, multi-tenant-safe; no org key in 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 — on both transports. Over WebSockets, browser end-users connect with their own JWT via ?token=, which Air Pipe verifies against your JWKS, a shared secret, or a token it mints for you, then gates channels by the user's claims — no org key in the browser. Or go fully open: a public interface accepts connections with no credential at all. MQTT supports the same open/anonymous model on public interfaces (no password). Public access is multi-tenant-safe — anonymous connections reach only the interfaces you mark public, per-org limits still bound them, and a private topic is never exposed.
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.