Recently, I built a proof of concept for a feature using Laravel’s Broadcasting feature. While I was familiar with its existence, it was my first time actually using it for something. 

With broadcasting, we’re referring to the concept of transmitting server-side events to one or more clients; typically, this is done through WebSockets. In order to do this, you need the following:

  • A server-side broadcasting driver that will broadcast your events.
  • A client to subscribe to your broadcasted events (with Laravel, this will be Laravel Echo by default).

For the server-side component, Laravel ships with several drivers. The most common one is Pusher, which is a paying service and ideal for production usage.

However, when developing locally, I try to avoid using the same external services that are used in production. I don’t want events I send out locally to accidentally affect production users. 

Most of the time, these services offer some kind of sandbox or testing environment you can use for this purpose, but, in the case of Pusher, this was not available. They do offer a Sandbox plan that you can use for free, but this would mean everyone on the team has to set up their own account, which complicates the onboarding process of a new team member.

Instead, I looked for alternative solutions that could be run locally. There were a few criteria:

  • It should be easy to install as part of our existing Sail environment.
  • It should mimic the usage of the Pusher driver used in production.

The Redis driver

Out of the box, Laravel provides a Redis driver. Since we were already using Redis for other reasons, this felt like a good candidate to explore first. The official documentation does not contain a lot of information on how to set it up, but thankfully, there are some blog posts that were very helpful!

When using Redis as the driver, you are expected to run a server yourself that leverages Redis’s Pub/Sub to dispatch events to the connected clients. This is where Laravel Echo Server comes in, and it also comes with a Docker Image for running the server as part of Sail.

The downside of this driver is that you will need to maintain two different connection protocols depending on the environment, which adds additional complexity. 

The Pusher driver with Laravel Echo Server

Laravel Echo Server also offers an HTTP API that is compatible with Pusher’s API. This means you can use the Pusher driver both locally and on production, avoiding the need to maintain two different connection protocols on the client-side.

However, Laravel Echo Server does not appear to be actively maintained, so it’s uncertain if they can maintain feature parity with the Pusher API.


Soketi is the spiritual successor of Laravel Echo Server. It is a well-maintained, well-documented, open-source project that follows the latest Pusher protocols. As a bonus, it integrates directly with Sail and Echo.

To conclude – Pusher alternatives

If you’re looking for an alternative to using Pusher on local environments, then I would definitely recommend looking into Soketi if you’re already using Sail. For us, it has been a great addition, and we haven’t run into any limitations with it.