Pusher rents you channels and presence as a hosted pub/sub service, one connection at a time. 23blocks ships the same primitives as an open-source Realtime block — channels, presence, WebRTC — that you can run on our shared platform or graduate to your own cloud, with no code rewrite either way.
Prices and connection quotas change constantly on both sides. What doesn't change is the structure — whether the realtime layer is a point service you subscribe to, or a block you can own outright.
| Approach | Pusher | 23blocks |
|---|---|---|
| What you're adopting | A hosted pub/sub and presence service | An open-source Realtime block on a shared platform |
| Billing unit | Per connection, per message | Running the platform, not licensing the code |
| Source code | Proprietary, Pusher-operated | Open source, yours to fork |
| Where it runs | Pusher's infrastructure, no alternative | Our shared platform, your own cloud, or self-hosted |
| Identity and tenants | You wire your own auth into channel auth hooks | Shares one user and company model with the rest of the platform |
| Moving off later | Rewrite channel and presence logic against a new provider | Graduate to your own infra, same code, no rewrite |
| Adoption model | A standalone point service for one job | One block among 20+, already integrated |
A realtime layer is a distributed system, not a feature. These are the hard, unglamorous calls the Realtime block has already made so you don't have to make them from scratch.
Public, private, and presence channels with typing indicators and read receipts, so "who's online" and "who's typing" are already solved instead of hand-rolled.
On reconnect, clients replay from the last acknowledged offset instead of guessing — no silently dropped messages while a connection was flapping.
Every channel connect is authorized server-side, not left as a client-trusted handshake — a decision that matters the first time a security review asks about it.
Peer-to-peer video and audio with signaling and TURN fallback already wired in, for the moment two peers behind symmetric NATs can't find each other directly.
Per-channel message ordering holds even as broadcast fans out to thousands of subscribers, so delivery to the slowest client never reorders it for the rest.
Message history for scrollback, broadcast events for fan-out, and webhooks for bridging channel activity into the rest of your stack — all in the same block.
The moment you wire a channel, you need to know who's on the other end of it — Auth is already on the shelf, sharing the same user model as the socket that just opened.
Multi-tenant apps need to know which company a channel belongs to before they authorize it — Companies is already there, on the same user model, no separate lookup to build.
A live dashboard tile or notification badge needs a source event — sales and rewards blocks already emit them, ready to drive the channel you just opened.
With Pusher, wiring in "who's connected" and "which tenant" is work you do yourself, against your own auth system, through channel authorization hooks you write and maintain. With 23blocks, that same channel authorization call resolves against a user model that Auth and Companies already populate — the identity and the tenant were never separate problems from the socket, because they live on the same platform as it. You didn't set out to buy a platform. You set out to open a WebSocket. But the moment that channel needs an authorized user and a tenant boundary, the rest of the shelf is already there, sharing the same data instead of asking you to reconcile three separate systems.
Pusher is a well-built, mature product and it fits real situations. We'd rather tell you when than pretend it doesn't.
You need a point service, not a platform — realtime is the only backend problem you have, and you'd rather not touch auth, tenants, or events at all.
You're already invested in Pusher's ecosystem — existing channel auth hooks, dashboards, and client libraries you don't want to re-wire.
You want zero operational involvement — a fully managed service with no interest in ever running or reading the underlying code.
Your integration needs are narrow and stable — a single notification stream bolted onto an otherwise finished stack, unlikely to grow into more.
None of that is wrong — it's just a different bet. 23blocks is built for teams who expect the realtime layer to grow into identity, tenants, and events, and who want the option to run it on their own infrastructure without a rewrite. If that's not your situation, Pusher is a solid choice.
Yes. As of July 31, 2026, the Realtime block's code is open source. You can read it, fork it, and run it yourself. What you pay for, if anything, is running the platform — not the software.
Pusher is a hosted pub/sub service you subscribe to: you rent channels and presence as a managed point service. 23blocks ships the same channel, presence, and broadcast primitives as an open-source block you can run on the shared platform or graduate to your own cloud, already integrated with auth and tenants instead of standing alone.
No, the Realtime block works on its own. But the moment you need to know who is connected or which tenant a channel belongs to, Auth and Companies are already on the shelf and share the same user model — no separate identity system to wire up.
You graduate to your own cloud account with a reversible migration and no code rewrite — the same open-source Realtime block, the same channels and presence logic, just running on infrastructure you control.
Start free on the shared platform, open source underneath, and never rewrite your code to move.
Get product updates, engineering posts, and new block announcements delivered to your inbox.