Laravel Broadcasting: run Reverb yourself, or use a hosted service?

Laravel Broadcasting gives you two good ways to push events to browsers. You can run Laravel Reverb, the WebSocket server the Laravel team released with Laravel 11, or you can point the pusher driver at a hosted service such as Pusher or Hibira. Both speak the Pusher protocol, and both work with Laravel Echo and pusher-js. Your events, channels and routes/channels.php don't change.

So the question isn't which one your code supports. It's who runs the WebSocket server.

What running Reverb asks of you

Reverb is a long-running PHP process built on an event loop. Getting it working locally is one command:

php artisan install:broadcasting php artisan reverb:start 

Production takes more:

• A process manager. Reverb has to stay up, so it runs under Supervisor or systemd and restarts on deploys.
• TLS and a proxy. Browsers need wss://, so Reverb usually sits behind Nginx or a load balancer that terminates TLS and upgrades the connection.
• Server limits. Each connection is an open file. You'll raise the open-file limit, and past about a thousand connections the Reverb docs recommend the ext-uv event loop.
• Scaling out. One Reverb process handles a lot, but more than one server means turning on Reverb's Redis-based scaling and putting a load balancer in front.
• Watching it. Reverb reports to Laravel Pulse. You'll still want alerts for when the process dies or connections spike.

None of this is unusual if you already run your own servers. It's the same work as any other daemon.

What a hosted service asks of you

With a hosted Pusher-compatible service you set a few values in .env and keep using the pusher driver:

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 

You don't operate a WebSocket process or its TLS yourself, but you still need to choose a plan sized for peak connections and deliveries. In exchange, you pay a monthly fee once you outgrow the free tier, your events pass through a third party, and you live with the plan's limits.

Side by side

How to choose

Run Reverb when:

• You already operate servers with a process manager and monitoring, and one more daemon is little extra work.
• Events must not leave your infrastructure.
• Your traffic is modest and in one region, close to your servers.

Use a hosted service when:

• You deploy to a platform where long-running processes are awkward (serverless, some PaaS plans).
• Nobody on the team wants to be paged for the WebSocket server.
• Your users are far from your servers. A WebSocket server near them shortens every event, even if your app stays where it is.
• You want what sits around the server: a debug console, usage per app, webhooks, push notifications to phones.

You can change your mind later

The shared protocol reduces migration work, but it does not make providers identical. Check your Laravel version and Echo configuration, channel types (including encrypted and cache channels), client events, webhooks, usage limits and peak concurrent connections before switching. Hosted removes server operations from your team; choosing an adequate plan is still capacity planning.

Because both speak the same protocol, moving between them is configuration, not code. Going from Reverb to a hosted service means switching BROADCAST_CONNECTION to pusher, setting the PUSHER_* values, and changing Echo's broadcaster from 'reverb' to 'pusher' with the same host options. Going the other way is the reverse.

Many teams start hosted to ship quickly and move to Reverb once traffic is predictable, or start on Reverb and move to hosted when the ops work stops being worth it. Either path is fine.

If you choose hosted, the Laravel guide has the full setup for Hibira, and the free plan covers development and small apps.

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.