Migrating from Pusher Channels: change the host, keep your code

Hibira speaks the Pusher Channels protocol. Your client libraries, server libraries, channel names, events and auth endpoints keep working. What changes is the host they connect to and the credentials they use. This post walks through a migration from start to finish, including how to keep old and new clients served during a gradual cutover. Dual publishing reduces gaps, but it does not guarantee zero missed or duplicate events.

What stays the same

• Client libraries: pusher-js, Laravel Echo, PusherSwift, pusher-java-client and the other Pusher clients.
• Server libraries: the official pusher packages for Node.js, PHP, Python, Go, Ruby, Java and .NET all take a host option.
• Channels and events: public, private, presence and encrypted channels, client events, the HTTP API (trigger, batch, channel queries), cache channels, user authentication and watchlists.
• Webhooks: requests carry the same X-Pusher-Key and X-Pusher-Signature headers, so your handler verifies them unchanged.

The full list, side by side, is on the migration page.

Step 1: create an app

Sign up, create an app and copy its app ID, key and secret. On the Free plan, list the domains your site runs on as allowed origins; browsers on other origins are refused.

Step 2: point your server at the new host

Every official server library takes a host. In Node.js:

const Pusher = require('pusher'); const pusher = new Pusher({ appId: process.env.PUSHER_APP_ID, key: process.env.PUSHER_APP_KEY, secret: process.env.PUSHER_APP_SECRET, host: 'ws.hibira.io', port: '443', useTLS: true, }); pusher.trigger('orders', 'order-shipped', { id: 1024 }).catch(console.error); 

In Laravel, Broadcasting already reads the host from .env:

BROADCAST_CONNECTION=pusher PUSHER_APP_ID=your-app-id PUSHER_APP_KEY=your-app-key PUSHER_APP_SECRET=your-app-secret PUSHER_HOST=ws.hibira.io PUSHER_PORT=443 PUSHER_SCHEME=https PUSHER_APP_CLUSTER=hkg 

Check that config/broadcasting.php passes host, port, scheme and useTLS into the pusher connection's options. Configs from older Laravel versions sometimes pass only the cluster, which sends traffic to pusher.com.

Step 3: point your clients at the new host

pusher-js needs the host, the port and the transports:

const pusher = new Pusher('your-app-key', { cluster: 'hkg', wsHost: 'ws.hibira.io', wsPort: 443, wssPort: 443, forceTLS: true, enabledTransports: ['ws', 'wss'], }); 

The cluster value is required by pusher-js but ignored once wsHost is set. Put your app's Hibira cluster there (hkg for Hong Kong, shown on the app page), the way you would name a Pusher cluster such as ap1. enabledTransports keeps the client on WebSockets instead of falling back to Pusher's HTTP transports. Laravel Echo takes the same options. Your channel names, event names and authorization endpoint don't change.

Mobile clients are the same idea: PusherSwift and pusher-java-client take a host option. Ship that change in an app release.

Step 4: recreate your webhooks

If you use webhooks (channel occupied and vacated, member added and removed, client events, cache misses), add your webhook URL on the app page. Hibira signs requests with your app secret the same way Pusher does.

Step 5: switch over without downtime

What “without downtime” means: Dual publishing can keep both old and new clients receiving updates during rollout, but it is not an atomic transaction across providers. One publish may succeed while the other fails; retries can also duplicate events. Give application events stable IDs, use an outbox or retry queue where delivery matters, and have clients refetch authoritative state after reconnecting. Verify that your auth endpoint signs for the correct app secret during the overlap.

Clients and servers rarely update at the same moment, especially with mobile apps in the stores. The safe order:

1. Publish to both. Change your server to send each event to Pusher and to Hibira. Two clients, one call each.
2. Release the client change. New clients connect to Hibira; old clients stay on Pusher, and both receive every event.
3. Wait. Watch connections move over on the app page. For mobile apps this can take weeks.
4. Stop publishing to Pusher once old clients are few enough, then remove the Pusher credentials.

Presence channels are the one thing to think about during the overlap: members on Pusher and members on Hibira don't see each other. If presence lists matter, keep the overlap short or show presence only to clients on the new host.

What to check after the move

• Private and presence channels authorize: your auth endpoint signs with the new secret.
• Webhooks arrive and verify.
• The app page's debug console shows your events as they're published.

If you hit something we don't support yet, write to support@hibira.io. For other stacks, the integration guides show the same change for 12 libraries.

Originally published on the Hibira blog. Hibira is a hosted, Pusher-compatible WebSocket service with servers in Hong Kong; the Free plan needs no card.