← Topics

Soketi alternatives: where to move a Pusher-protocol server

Soketi’s last release was in March 2024. The Pusher-compatible options to move to, what changes in your configuration, and how to switch without downtime.

Soketi made the Pusher protocol easy to self-host, and many Laravel and Node.js apps still run on it. The project has slowed down, though, so teams that depend on it are asking where to go next. Because Soketi speaks the Pusher protocol, the answer can be a configuration change rather than a rewrite.

Where Soketi stands

From the Soketi repository and its releases, checked on 2026-10-26.

A server that works today can keep working for a long time. The risk is what comes later: a Node.js upgrade the server no longer builds on, a security fix nobody ships, or a bug you have to patch yourself. For the piece that holds every user's connection, that is worth planning for before it is urgent.

Pusher-compatible places to move

These keep pusher-js, Laravel Echo and the Pusher server libraries, so your channels, authorization endpoint and events stay as they are.

Prices are from Laravel Cloud's pricing docs and pusher.com/channels/pricing, checked on 2026-10-26.

Moving off the Pusher protocol, to Socket.IO, Centrifugo or Ably, is also possible but means new client and server code. The Pusher alternatives page covers those.

What changes in your configuration

Only the connection details. In a Laravel app on Soketi, .env usually points the Pusher driver at your own host on port 6001. For a hosted service it points at that service instead:

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

In pusher-js or Laravel Echo, change wsHost and the ports to match and keep forceTLS: true. Soketi's app manager settings, such as per-app connection limits or allowed origins, become app settings in the new service's dashboard.

Switching without downtime

1. Create an app on the new service and copy its credentials.
2. Have your server publish each event to both Soketi and the new service. The Pusher server libraries are cheap to instantiate twice.
3. Release the client change. New page loads connect to the new host; old tabs and app versions stay on Soketi.
4. When Soketi's connection count falls to zero, or close enough, stop publishing to it and shut it down.

Webhooks need the same treatment: register your endpoint on the new service before step 3. The migration guide has the same steps for moving from Pusher.

What you get from a hosted service

Beyond not running the server, a hosted service gives you the tools Soketi leaves to you: a dashboard with connection and message counts, a live debug console that shows every event, webhooks, and usage shown against your plan’s limits.

Common questions

Is Soketi still maintained?

Its last release, 1.6.1, came out on 2024-03-25, and later commits are dependency updates. The README itself notes infrequent updates and support. It still runs, but plan for a replacement.

What is the closest replacement for Soketi?

Laravel Reverb if you want to keep self-hosting, or a hosted Pusher-compatible service if you would rather not run the server. Both keep the Pusher protocol, so your code stays the same.

Do I have to change my client code to leave Soketi?

No, if you move to another Pusher-protocol server or service. You change the host, port, key and secret, in .env and in your pusher-js or Echo options.

Product names are trademarks of their owners.