Laravel Reverb in Production: Scaling WebSockets Beyond a Single Server

The Gap Between Demo and Production

Laravel Reverb ships with a compelling zero-dependency story: one php artisan reverb:start command and you have a WebSocket server. That works brilliantly on a single Forge server. The moment you add a second app server — or your connection count climbs past a few thousand — you need a deliberate scaling plan.

This article covers the three concrete problems you will face and how to solve each one.

Problem 1: Multiple App Servers, One Reverb Node

Your Laravel app runs on two EC2 instances behind a load balancer. Both instances dispatch broadcast events. Only one instance runs Reverb. The instance that doesn't host Reverb still needs to push messages to it.

Reverb solves this with a Redis pub/sub backend. Configure it in config/reverb.php:

'servers' => [
    'reverb' => [
        // ...
        'scaling' => [
            'driver' => 'redis',
            'connection' => 'default', // your Redis connection name
        ],
    ],
],

With this in place, every app server publishes broadcast events to Redis. The Reverb process subscribes and fans them out to connected clients. Your app servers never need a direct TCP connection to Reverb.

Important: Use a dedicated Redis logical database or a separate Redis instance for Reverb pub/sub. Mixing it with your cache or queue database makes debugging latency spikes much harder.

Problem 2: Horizontal Reverb Scaling

A single Reverb process is single-threaded by design (it runs on ReactPHP's event loop). You can scale vertically to a point, but eventually you need multiple Reverb processes.

Run multiple Reverb workers and put a sticky-session-aware load balancer in front of them. Nginx with ip_hash is the simplest option:

upstream reverb {
    ip_hash;
    server 10.0.0.10:8080;
    server 10.0.0.11:8080;
}

server {
    listen 443 ssl;
    location / {
        proxy_pass http://reverb;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
        proxy_set_header Host $host;
        proxy_read_timeout 3600s;
    }
}

Sticky sessions ensure a client's WebSocket upgrade and subsequent frames all hit the same Reverb worker. Because all workers share the Redis pub/sub channel, a broadcast from any app server reaches every connected client regardless of which worker they landed on.

Problem 3: Reconnect Storms After a Deploy

When you restart Reverb (e.g., during a deploy), every connected client disconnects simultaneously. Laravel Echo's default reconnect strategy uses a fixed 1-second delay, so thousands of clients hammer the server at once.

Override Echo's reconnect options on the client side:

import Echo from 'laravel-echo';
import Pusher from 'pusher-js';

window.Echo = new Echo({
    broadcaster: 'reverb',
    key: import.meta.env.VITE_REVERB_APP_KEY,
    wsHost: import.meta.env.VITE_REVERB_HOST,
    wsPort: import.meta.env.VITE_REVERB_PORT,
    forceTLS: true,
    enabledTransports: ['ws', 'wss'],
    // Pusher-js reconnect options
    activityTimeout: 30000,
    pongTimeout: 6000,
});

Pusher-js uses exponential backoff internally; the key is ensuring activityTimeout is long enough that routine Reverb restarts (< 5 s) don't trigger a reconnect at all. Pair this with a zero-downtime Reverb restart using Supervisor:

[program:reverb]
command=php /var/www/artisan reverb:start --host=0.0.0.0 --port=8080
autostart=true
autorestart=true
stopwaitsecs=10

Supervisor's stopwaitsecs gives Reverb time to drain existing connections before the new process starts.

Tuning Connection Limits

Reverb inherits ReactPHP's file-descriptor limits. On Linux, the default is 1024 open files per process. Raise it in your Supervisor config:

[program:reverb]
; ...
minfds=65536

And confirm your OS-level limit:

ulimit -n 65536

Takeaways

• Enable the Redis scaling driver so all app servers can publish through a single Reverb cluster.
• Use sticky-session load balancing (Nginx ip_hash) in front of multiple Reverb workers.
• Tune Echo's activityTimeout to survive short Reverb restarts without a reconnect storm.
• Raise file-descriptor limits in Supervisor and at the OS level before you hit connection ceilings.
• Keep Reverb's Redis pub/sub on a dedicated database to isolate latency from cache/queue traffic.