Real-Time Laravel with Reverb and WebSockets

By Khimananda Oli | Last reviewed: August 2026

Building responsive applications requires moving beyond traditional HTTP polling, and implementing real-time Laravel with Reverb and WebSockets is now the standard for PHP developers in 2026. Unlike legacy solutions that demanded separate Node.js processes or expensive third-party SaaS subscriptions, Reverb provides a high-performance, native PHP WebSocket server directly within your application stack. This guide covers the exact configuration, security hardening, and infrastructure patterns I use when deploying production-grade real-time systems on AWS and VPS environments.

How do you install and configure real-time Laravel with Reverb and WebSockets?

Setting up the foundation correctly prevents debugging nightmares later. Before touching any WebSocket code, ensure your server meets the minimum requirements: PHP 8.2+ with the pcntl, posix, and mbstring extensions enabled. If you are provisioning a fresh environment, follow my guide on securing a fresh Ubuntu VPS to establish a safe baseline before installing application dependencies.

Installation and credential generation

Reverb integrates deeply with Laravel's native broadcasting system. Install it via Composer and run the dedicated artisan command to publish the configuration file and generate your unique app keys:

composer require laravel/reverb
php artisan reverb:install

This command updates your .env file with critical variables like REVERB_APP_KEY, REVERB_APP_SECRET, and REVERB_HOST. Never commit these secrets to version control. In production environments managed via Terraform or CI/CD pipelines, inject these values through your secrets manager or environment variable store. For teams automating their deployments, integrating this step into your GitLab CI pipeline for Laravel ensures credentials are rotated and injected securely without manual intervention.

Broadcasting configuration

Update your config/broadcasting.php (or the new bootstrap/app.php structure in Laravel 11+) to set the default broadcaster to reverb. Verify that your frontend Echo configuration matches the backend credentials exactly. A common mistake in 2026 is mismatching the port or scheme between local development and production; always use environment variables for the WebSocket host and port in your frontend build process.

How do you deploy Reverb securely behind Nginx in production?

Never expose the raw Reverb TCP port directly to the public internet. In every production deployment I have architected, Nginx sits in front of Reverb to handle SSL termination, rate limiting, and connection buffering. This allows your WebSocket server to listen on localhost while Nginx manages the encrypted WSS protocol externally.

Nginx reverse proxy configuration

Add the following location block to your existing Nginx server configuration. This assumes Reverb runs on port 8080 internally and your domain has valid SSL certificates provisioned via Certbot:

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

    ssl_certificate /etc/letsencrypt/live/ws.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ws.yourdomain.com/privkey.pem;

    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;
        
        # Timeout settings critical for long-lived WebSocket connections
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
    }
}

The Upgrade and Connection headers are non-negotiable; without them, Nginx treats the request as standard HTTP and drops the WebSocket handshake. The extended timeouts prevent Nginx from prematurely closing idle connections during periods of low activity. For teams managing multiple domains or needing automated certificate renewal, refer to my tutorial on setting up free SSL with Let's Encrypt to automate this prerequisite.

Process management with systemd

Running php artisan reverb:start in a terminal session is unacceptable for production. Create a systemd service unit to ensure automatic restarts, logging integration, and graceful shutdowns during deployments:

[Unit]
Description=Laravel Reverb WebSocket Server
After=network.target redis.service

[Service]
User=www-data
Group=www-data
WorkingDirectory=/var/www/html
ExecStart=/usr/bin/php artisan reverb:start --host=127.0.0.1 --port=8080
Restart=always
RestartSec=5
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Enable and start the service with systemctl enable --now laravel-reverb. This guarantees your WebSocket server survives reboots and integrates with standard Linux monitoring tools.

How does Reverb compare to Pusher and Soketi for Laravel?

Choosing the right real-time driver depends on your operational constraints, budget, and compliance requirements. While Pusher remains popular for its zero-maintenance model, self-hosted alternatives have matured significantly. Understanding these trade-offs is essential when architecting real-time Laravel with Reverb and WebSockets for cost-sensitive or regulated environments.

For Nepal-based businesses or startups operating under strict data residency requirements, self-hosting eliminates cross-border data transfer concerns entirely. Reverb’s advantage lies in its unified stack: your team maintains one runtime (PHP), one deployment pipeline, and one monitoring dashboard. Soketi offers similar cost benefits but introduces Node.js operational overhead. Pusher remains viable for teams prioritizing developer velocity over infrastructure control, provided budget and compliance allow.

How do you scale and monitor Reverb for high-traffic production workloads?

A single Reverb instance handles thousands of concurrent connections efficiently, but production systems demand observability and horizontal scalability planning. Monitoring real-time Laravel with Reverb and WebSockets requires tracking both infrastructure metrics and application-level channel activity.

Observability and health checks

Reverb exposes a health endpoint at /up by default. Configure your load balancer and monitoring stack to poll this endpoint every 30 seconds. Integrate Reverb’s internal metrics with Prometheus by enabling the built-in metrics exporter in config/reverb.php. Key metrics to alert on include:

• Active connections: Baseline for capacity planning and anomaly detection
• Messages per second: Indicates throughput and potential backpressure
• Failed authentication attempts: Signals misconfigured clients or attack vectors
• Memory usage per worker: Detects leaks before OOM kills occur

For comprehensive monitoring setup, pair these metrics with the approach outlined in my Prometheus and Grafana complete setup guide to visualize connection trends and set meaningful alert thresholds.

Horizontal scaling strategies

When a single node reaches CPU or connection limits, scale horizontally using Redis Pub/Sub as the coordination layer. Each Reverb instance subscribes to a shared Redis channel, ensuring messages broadcast from any node reach all connected clients regardless of which server they’re attached to. Deploy multiple Reverb containers behind a sticky-session-aware load balancer if your application uses private channels extensively, though Redis Pub/Sub typically makes stickiness unnecessary for public broadcasts.

Resource tuning and limits

Tune your PHP-FPM and Reverb worker counts based on actual connection profiles, not theoretical maximums. Each WebSocket connection consumes memory; profile your specific workload with memory_get_usage() logging during load testing. Set systemd memory limits 20% above observed peak usage to prevent runaway processes from destabilizing the host. On containerized platforms, define explicit resource requests and limits in your Kubernetes manifests or Docker Compose files to guarantee scheduling predictability.

Next Steps for Production Real-Time Systems

Implementing real-time Laravel with Reverb and WebSockets gives you full ownership of your real-time infrastructure without sacrificing performance or developer experience. Start with the single-node Nginx setup described here, validate your monitoring alerts, then scale horizontally only when metrics justify it. Avoid premature optimization; most applications never exceed a single well-tuned Reverb instance. If your team needs assistance architecting, securing, or scaling your real-time Laravel infrastructure for production, reach out to discuss your specific requirements.