Real-Time Laravel with Reverb and WebSockets

By Kokil Thapa | Last reviewed: August 2026

Implementing Real-Time Laravel with Reverb and WebSockets has fundamentally changed how we build interactive applications in the PHP ecosystem. For years, developers relied on external services like Pusher or complex Node.js setups, but Laravel Reverb now provides a first-party, high-performance WebSocket server directly within your application stack. This shift eliminates vendor lock-in and reduces latency for features like live notifications, chat systems, and dashboard updates.

If you are evaluating whether to adopt this for a client project or internal tool, understanding the architectural trade-offs is essential before writing code. I recently outlined broader backend considerations in my guide on hiring and working with Laravel developers in Nepal, where real-time capability is increasingly a baseline expectation for legal-tech portals and eCommerce platforms. Reverb fits squarely into modern stacks running Laravel 12.x and PHP 8.4, removing the friction that previously made WebSockets a "nice-to-have" rather than a standard feature.

How do you install and configure Real-Time Laravel with Reverb and WebSockets?

Setting up Reverb in a fresh Laravel 12 application is straightforward, but production readiness requires specific attention to environment configuration. Unlike previous community-driven packages, Reverb is officially maintained and integrates directly with Laravel's broadcasting system.

Installation Steps

1. Install the package: Run composer require laravel/reverb. This pulls in the ReactPHP-based WebSocket server and all necessary dependencies.
2. Publish configuration: Execute php artisan reverb:install. This command publishes the config/reverb.php file, adds the required environment variables to your .env, and sets up the broadcasting configuration automatically.
3. Verify environment variables: Ensure your .env contains the correct keys. In 2026, the default port is typically 8080, but you should verify this against your firewall rules.

<!-- .env Configuration Example -->
BROADCAST_CONNECTION=reverb
REVERB_APP_ID=your-app-id
REVERB_APP_KEY=your-app-key
REVERB_APP_SECRET=your-app-secret
REVERB_HOST="0.0.0.0"
REVERB_PORT=8080
REVERB_SCHEME=http

<!-- Frontend Vite Variables -->
VITE_REVERB_APP_KEY="${REVERB_APP_KEY}"
VITE_REVERB_HOST="ws.yourdomain.com"
VITE_REVERB_PORT="443"
VITE_REVERB_SCHEME="wss"

A common mistake I see on client projects is leaving REVERB_HOST as localhost. While fine for local development, production servers must bind to 0.0.0.0 to accept external connections through your reverse proxy. Always treat these credentials as secrets; never commit them to version control.

How does Reverb compare to Pusher and Socket.io for Laravel applications?

Choosing the right broadcasting driver depends on budget, compliance, and operational complexity. While Pusher remains popular for its zero-maintenance API, Reverb offers distinct advantages for teams managing their own infrastructure, particularly in regions like Nepal where data sovereignty or recurring USD costs are concerns.

In practice, Reverb wins for most Laravel shops because it speaks the Pusher protocol. This means you can switch drivers by changing a single environment variable without rewriting frontend code. For legal-tech platforms handling sensitive client documents, keeping traffic on-premise is often a non-negotiable requirement that SaaS providers cannot meet. If you are building a SaaS product yourself, my article on why Laravel is ideal for SaaS in Nepal covers similar cost-benefit analyses for infrastructure decisions.

How do you integrate Laravel Echo with Vite and Reverb?

The frontend experience defines whether your real-time features feel responsive or broken. Laravel Echo is the official client library, and in 2026, it pairs exclusively with Vite for asset bundling. Getting the handshake right between Vite's dev server and Reverb's WebSocket endpoint prevents the most common debugging headaches.

Frontend Setup Checklist

• Install dependencies: npm install --save-dev laravel-echo pusher-js. Even though you use Reverb, the pusher-js library is required because Reverb implements the Pusher protocol.
• Configure Echo: Create or update resources/js/echo.js. Point the key and wsHost to your Vite environment variables.
• Import in app.js: Ensure Echo is initialized before any component attempts to subscribe to channels.

// resources/js/echo.js
import Echo from 'laravel-echo';
import Pusher from 'pusher-js';

window.Pusher = Pusher;

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 ?? 8080,
    wssPort: import.meta.env.VITE_REVERB_PORT ?? 443,
    forceTLS: (import.meta.env.VITE_REVERB_SCHEME ?? 'https') === 'https',
    enabledTransports: ['ws', 'wss'],
});

During local development, Vite runs on port 5173 while Reverb runs on 8080. Cross-origin issues are common here. Ensure your config/cors.php allows the Vite dev server origin. In production, serving both the app and WebSocket traffic through the same domain (via subdomain or path) eliminates CORS entirely and simplifies cookie-based authentication for private channels.

How do you deploy and scale Reverb in production environments?

Running php artisan reverb:start in a terminal is not a production strategy. Reverb is a long-running process that must be managed by a process supervisor and protected behind a reverse proxy. On Ubuntu 24.04 servers, Supervisor and Nginx remain the standard combination for reliability.

Supervisor Configuration

Create a configuration file at /etc/supervisor/conf.d/reverb.conf. This ensures the WebSocket server restarts automatically after crashes or deployments.

[program:reverb]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/html/artisan reverb:start --host=0.0.0.0 --port=8080
autostart=true
autorestart=true
stopasgroup=true
killasgroup=true
user=www-data
numprocs=1
redirect_stderr=true
stdout_logfile=/var/log/reverb.log
stopwaitsecs=3600

Nginx Reverse Proxy for WSS

WebSockets require persistent connections. Your Nginx config must explicitly upgrade HTTP requests to WebSocket protocol. Without these headers, clients will fail to connect or drop intermittently.

server {
    listen 443 ssl http2;
    server_name ws.yourdomain.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        
        # Critical for WebSocket stability
        proxy_read_timeout 86400s;
        proxy_send_timeout 86400s;
    }
}

For high-traffic applications, horizontal scaling requires Redis Pub/Sub. When running multiple Reverb instances across different servers, Redis acts as the message bus to synchronize events. Enable this in config/reverb.php under the servers.reverb.scaling array. I've detailed similar scaling patterns in scaling Laravel queues for high traffic, as the Redis infrastructure overlaps significantly.

What are common debugging strategies for WebSocket connection failures?

Even with perfect configuration, real-time systems fail silently. Browser consoles show generic "connection closed" errors that hide the root cause. After debugging dozens of production deployments, I rely on a systematic checklist to isolate issues quickly.

Diagnostic Workflow

1. Verify the server is listening: Run sudo netstat -tulpn | grep 8080 on the server. If nothing appears, Supervisor may have crashed or the port is blocked by UFW.
2. Test raw connectivity: Use wscat -c wss://ws.yourdomain.com/app/your-key from an external machine. This bypasses browser-specific issues and confirms SSL/proxy configuration.
3. Check CORS and headers: Inspect the Network tab in DevTools. Failed handshakes often return 403 or 400 status codes before the upgrade occurs. Verify Access-Control-Allow-Origin matches your frontend domain exactly.
4. Validate authentication: For private channels, inspect the /broadcasting/auth request payload. Ensure the user session is valid and the channel name matches the authorization pattern in channels.php.
5. Review logs: Check /var/log/reverb.log and Laravel logs simultaneously. Reverb logs connection lifecycle events, while Laravel logs broadcasting failures and auth exceptions.

A frequent gotcha in Nepal and similar regions involves ISP-level filtering or corporate firewalls blocking non-standard ports. Always serve WebSockets over port 443 (WSS) through your existing SSL certificate. This not only improves security but also ensures compatibility with restrictive network environments. If you're integrating payment webhooks alongside real-time updates, ensure your webhook endpoints don't conflict with your broadcasting routes; my guide on Laravel payment integrations covers route isolation strategies.

Conclusion

Adopting Real-Time Laravel with Reverb and WebSockets in 2026 gives you full ownership of your application's interactive layer without sacrificing developer experience or performance. The combination of native Laravel integration, Pusher protocol compatibility, and self-hosted economics makes it the pragmatic choice for everything from legal-tech client portals to high-volume eCommerce notifications. Start with a single-node Supervisor setup, validate your SSL termination early, and scale horizontally with Redis only when metrics demand it.

If you need help architecting a real-time system for your Laravel application or troubleshooting an existing WebSocket deployment, contact me to discuss your project requirements.