A Pusher alternative: Eventeer, Ably and Centrifugo compared
5 min readThe Eventeer team
Pusher Channels is a publish/subscribe service for realtime features. Apps subscribe to named channels, your system publishes to them, and the service offers presence channels, private channels, webhooks and client libraries covering browsers, mobile apps and IoT devices. It is built for realtime features inside apps.
People look for an alternative for reasons of fit, not because Channels is broken: they want the delivery guarantees or history of a different model, they want to self-host, or they find that what they are really moving is events from webhooks and devices, not chat-style messages. Last reviewed: November 2026.
What to look for in a Pusher alternative
Five questions decide most cases:
- Who publishes? If your server publishes and clients only listen, many tools qualify. If clients publish to each other, fewer do.
- Do you need presence? A “who is online” list for your app’s users is a specific feature, not a given.
- What happens to a client that was offline? Some tools keep short-term history and let a reconnecting client catch up; others only deliver to who is connected.
- Where do the events come from? App code, or provider webhooks and device traffic that you need stored and replayable?
- Do you want to host it? Managed service or software you run yourself.
The alternatives
Eventeer
Eventeer is an event hub. It ingests webhooks (listener URLs with token or HMAC auth), device WebSocket traffic and API calls, stores events for 7, 30 or 90 days depending on plan, and delivers them to WebSocket streams and to signed HTTPS destinations.
For the Pusher use case, the relevant part is streams. A stream has its own URL and token, scoped to chosen listeners with an optional single payload condition. Browsers connect over WebSocket with the token as a query parameter. Live frames are at-most-once, but a client that reconnects with since set to the last event id gets stored events replayed first (up to 1,000 per connect), then live ones. Replay can repeat a few events, so clients dedupe by id.
What it does not do, stated plainly: there is no presence for your app’s users, no client-to-client publishing (events come from your listeners, devices and sources, not from client messages), and no client SDK: clients use a plain WebSocket. It covers device WebSockets (ack per event, online status, last_seen_at, downlink messages to a connected device), outbound webhooks with retries and a delivery log, metrics, dashboards and alerts. It is not a chat backend.
It fits when events originate on your server side, in a provider’s webhook or on a device, and you want them stored and replayable.
Ably
Ably describes Pub/Sub as its core product: a cloud publish/subscribe platform where, per its docs, Ably handles missed, duplicated or out-of-order messages. Its presence feature lets clients see who is present on a channel, with enter, leave, update and present events; the docs say this suits chat rooms and multiplayer games. Channel history lets clients retrieve past messages, but persistence applies only when enabled and the docs describe it as short-term catch-up, not a database.
It fits when you want the Pusher model (channels, presence) with built-in history, as a managed service.
Centrifugo
Centrifugo is open-source, self-hosted real-time messaging software. Clients subscribe to channels over transports including WebSocket, SSE and HTTP-streaming. It supports presence and per-channel history with recovery of missed messages on reconnect, and has official browser and mobile SDKs. Client publishing is available but off by default: you enable it per channel namespace, and the docs warn the backend does not see or validate those payloads unless you proxy them.
It fits when you want Pusher-like features on infrastructure you run yourself.
Comparison
| Capability | Pusher Channels | Eventeer | Ably | Centrifugo |
|---|---|---|---|---|
| Pub/sub to browser clients | Yes | Yes (server-fed streams) | Yes | Yes |
| Presence for app users | Yes | No | Yes | Yes |
| Clients publish | Yes (client events) | No | Yes | Partly (opt-in) |
| Catch-up after disconnect | Not documented here | Yes (replay with since) |
Yes (short-term history) | Yes (history recovery) |
| Receives inbound webhooks and device traffic | Not documented here | Yes | Not documented here | Not documented here |
| Self-hosted | Not documented here | No | No (hosted platform) | Yes |
“Not documented here” means the pages reviewed for this post do not say, not that the answer is no. See the full Eventeer and Pusher matrix for more rows.
When to stay with Pusher
Stay if you are building chat, live cursors, multiplayer or any feature where users see each other: presence channels and client events exist for exactly that, and Eventeer has neither. Stay if you value maintained client libraries, or if your current setup works and your events never need storing or replaying.
Moving to Eventeer
Only the server-triggered part of your Pusher use moves.
-
List the channels your server publishes to and the event names clients bind to.
-
Create a listener, or ingest through the API, to get those events in:
curl -X POST https://app.eventeer.io/api/v1/listeners \ -H "Authorization: Bearer $EVENTEER_KEY" \ -H "Content-Type: application/json" \ -d '{"name":"orders","type":"webhook","auth_mode":"anonymous"}' -
Create a stream per channel with
POST /api/v1/streams(body fields:name,auth_modeofanonymousortoken,listener_ids, optionalfilter,replay_allowed). For atokenstream, create a token withPOST /api/v1/streams/:key/credentials(optionalname); the secret is returned once. -
Replace the Pusher subscription with a WebSocket to
/out/s/<stream_key>?token=..., passingsinceon reconnect. The real-time streams use case has a working snippet. -
Run both in parallel, compare what clients receive, then remove the Pusher publish calls.
Presence and client events have no equivalent, so keep Pusher for those. Check pricing against your volume.
Sources
Every statement about Pusher, Ably and Centrifugo in this post comes from these pages, last reviewed November 2026.