Compatibility
A Pusher-compatible realtime backend
PushCaster speaks the Pusher Channels protocol version 7 on the wire. Moving is configuration, not a rewrite — and this page is the exact list of what changes.
No application rewrite. Only connection configuration changes are required. Three to six lines per application; for Laravel, a .env change and nothing else. Not drop-in and not zero-config: the host has to be set, and the credentials are new.
What stays the same
The wire, the libraries and the auth handshake
Compatibility here means the protocol, not a resemblance — compatible request/response formats, event semantics and authentication scheme.
| Area | What is unchanged |
|---|---|
| Protocol | Pusher Channels protocol version 7 on the wire. |
| Client libraries | pusher-js, Laravel Echo and the official mobile libraries, unmodified. |
| Server libraries | pusher-php-server, pusher-http-node, and the Python, Go, Ruby and Java libraries. |
| Signatures | Compatible signing and canonicalization scheme. |
| Channel types | Public, private, presence and private-encrypted, same prefixes. |
| Subscription auth | POST /pusher/auth keeps its request and response shape. |
| Client events | Between subscribers on private and presence channels, as before. |
| Webhooks | Same field names and headers, including channel_occupied, member_added and cache_miss. |
Tested SDK versions
Compatible with the listed Pusher SDK versions without modifying those SDKs.
| SDK | Version tested |
|---|---|
| pusher-js (browser) | 8.6.0 |
| pusher/pusher-php-server | 7.3.0 |
| pusher (Node.js) | 5.3.4 |
| pusher (Python) | 3.3.4 |
| pusher-http-go | v5.1.1 |
| pusher (Ruby) | 2.1.1 |
| laravel/framework (Echo) | ^13.0 |
What changes
The host, and the credentials
pusher-js hardcodes ws-<cluster>.pusher.com unless wsHost is supplied, and the server libraries default to api-<cluster>.pusher.com unless host is supplied. Overriding those is the migration.
const pusher = new Pusher(APP_KEY, {- cluster: 'eu',+ wsHost: 'ws-eu1.pushcaster.io',+ wsPort: 443,+ forceTLS: true, })The full change, per language
// before — talking to Pushernew Pusher(KEY, { cluster: 'eu' })// after — talking to PushCaster (the key & secret are new)new Pusher(KEY, { wsHost: 'ws-eu1.pushcaster.io', wsPort: 443, forceTLS: true,})Setting the host is easy to miss. Left at its default the library talks to Pusher's servers, and the error names a bad key rather than a wrong destination.
The app id, key and secret are new. Existing credentials do not transfer. Pick a cluster at the same time — it is part of the host.
Known differences
Three things that are not the same
A compatibility claim is only useful with its exceptions. These three can change a design decision.
One cluster, no federation
A cluster is an isolation boundary, not a region hint: its own nodes, NATS and Redis, and no delivery between clusters. An application lives in exactly one, so two that must talk to each other belong in the same one.
The host is not the cluster name
cluster: "eu" on its own does not reach PushCaster. You set wsHost on the client and host on the server library. It is a three-option edit, and every migration makes it.
No statistics API
Pusher's dashboard statistics endpoint has no equivalent here. Usage comes from our own API and operational metrics from Prometheus. No official server SDK calls that endpoint, so this affects your tooling rather than your application.
Migrating
Test private and presence channels first
Public channels keep passing when something is wrong — they ask your server nothing. A stale host or a mismatched secret surfaces only on private and presence channels.
- 01Create the applicationThe cluster you pick is part of every host you are about to configure.
- 02Set the host in both placesThe client needs wsHost, the server needs host. Miss either and half your app still talks to Pusher.
- 03Swap the credentialsAll three change together. A new key with an old secret fails only on signed subscriptions — which is why it survives a smoke test.
- 04Subscribe to a private channelExercises POST /pusher/auth and proves the secret pairs with the app id.
- 05Join a presence channelConfirms the member list and join/leave events.
- 06Publish from the serverConfirms the publish host and the signature end to end.
Create an application and point one client at it.
Pusher is a trademark of its respective owner. PushCaster is an independent service and is not affiliated with or endorsed by Pusher. Library names are used descriptively.