Lập trình · 20/09/2026

Laravel Reverb: Building Real-Time Applications for Production

Real-time updates are useful far beyond chat. Order notifications, background-processing progress, operational dashboards, and collaborative state all improve when the server can push changes to the browser. Laravel Reverb provides a WebSocket server that integrates directly with Laravel event broadcasting.

Laravel Reverb: Xây dựng ứng dụng realtime và vận hành trên production

Real-time updates are useful far beyond chat. Order notifications, background-processing progress, operational dashboards, and collaborative state all improve when the server can push changes to the browser. Laravel Reverb provides a WebSocket server that integrates directly with Laravel event broadcasting.

This guide covers the data flow, installation, private channels, and production concerns that are easy to miss. The goal is not merely to display one event, but to operate a real-time path that is secure, observable, and scalable.

When should an application use real-time updates?

Order, payment, or support-ticket status notifications.
Progress for imports, exports, media processing, and reports.
Operational, inventory, or live metric dashboards.
Presence indicators in collaborative workspaces.
Chat, live comments, and in-app notifications.

Not every change needs WebSockets. Low-priority data that can refresh every few minutes may remain simpler with caching and polling.

Understand the complete data path

Laravel dispatches an event implementing ShouldBroadcast.
The broadcast job normally enters a queue.
Laravel sends the payload to Reverb using application credentials.
Reverb forwards it to clients subscribed to the correct channel.
Laravel Echo receives the event and updates the interface.

Reverb is the WebSocket server, while the queue worker is a separate component. A healthy socket connection will not deliver queued broadcast events when no worker is processing them.

Install Reverb and broadcasting

php artisan install:broadcasting
npm install
npm run build

php artisan reverb:start
php artisan queue:work

Use --debug while diagnosing local messages, but avoid permanently verbose traffic logging in production.

Separate the listening address from the public address

In production, Reverb may listen internally on port 8080 while browsers connect to wss://ws.example.com on port 443.

REVERB_SERVER_HOST=0.0.0.0
REVERB_SERVER_PORT=8080

REVERB_HOST=ws.example.com
REVERB_PORT=443
REVERB_SCHEME=https

The REVERB_SERVER_* values control the process listener. The public host and port tell Laravel where to send broadcasts. Matching VITE_REVERB_* variables are compiled into the frontend, so rebuild assets after changing them.

Broadcast a minimal payload

final class OrderStatusChanged implements ShouldBroadcast
{
    use Dispatchable, InteractsWithSockets, SerializesModels;

    public function __construct(public Order $order) {}

    public function broadcastOn(): array
    {
        return [new PrivateChannel('orders.'.$this->order->id)];
    }

    public function broadcastWith(): array
    {
        return [
            'id' => $this->order->id,
            'status' => $this->order->status,
            'updated_at' => $this->order->updated_at?->toIso8601String(),
        ];
    }
}

Explicit payloads reduce bandwidth and lower the risk of exposing model fields or loaded relationships that clients do not need.

Authorize private channels

Broadcast::channel('orders.{orderId}', function (User $user, int $orderId): bool {
    return Order::query()
        ->whereKey($orderId)
        ->where('user_id', $user->id)
        ->exists();
});

Channel definitions live in routes/channels.php. Possessing the public application key does not grant access to private data; the authorization callback decides whether the authenticated user may subscribe.

Listen with Laravel Echo

Echo.private(`orders.${orderId}`)
    .listen('OrderStatusChanged', (event) => {
        updateOrderStatus(event.status);
    });

The interface should handle disconnects, reconnects, and delayed events. After reconnecting, fetch a fresh API snapshot before resuming live updates instead of assuming missed messages will be replayed.

Use a reverse proxy and TLS

Nginx or another public web server usually terminates TLS and proxies to an internal Reverb port. The proxy must preserve HTTP/1.1 and the Upgrade and Connection headers, and it must serve both Reverb WebSocket and API paths.

Restrict allowed_origins to real application domains. A wildcard is convenient during experiments but unnecessarily expands the accepted origins in production.

Supervise long-running processes

Run Reverb under Supervisor, systemd, or a managed platform so it starts after reboot and recovers from failures. During deployment, restart it gracefully:

php artisan reverb:restart

Restart queue workers as well when broadcast events use queues.

Monitor and scale

Laravel Pulse can record Reverb connections and messages. Alerts should also cover connection errors, unusual reconnect rates, broadcast latency, queue wait time, memory, and open file descriptors.

Reverb supports horizontal scaling through Redis pub/sub:

REVERB_SCALING_ENABLED=true

All Reverb nodes must share Redis and sit behind a load balancer. Before scaling out, verify operating-system file limits, the event loop, Nginx capacity, and process-manager limits because each WebSocket remains open.