Laravel 13 + Reverb: tiempo real con WebSockets sin pagar Pusher

Reverb, el servidor WebSocket nativo de Laravel, habla el protocolo de Pusher: con Laravel 13 montas notificaciones y dashboards en tiempo real en PHP puro, sin Node.js y sin servicios de pago. Esta guía recorre la instalación, un ejemplo funcional y el despliegue en producción.

Qué es Reverb y por qué importa en 2026

Reverb es el servidor WebSocket de primera parte de Laravel, construido sobre ReactPHP y lanzado en 2024. Su particularidad: habla el protocolo de Pusher, lo que lo convierte en un reemplazo directo del sistema de broadcasting de Laravel y de Echo en el frontend, sin depender de ningún tercero. Desde su lanzamiento se ha convertido en la opción por defecto de la mayoría de equipos Laravel, y con Laravel 13, publicado el 17 de marzo de 2026, el stack queda completo: un servidor de tiempo real que corre en el mismo lenguaje que tu aplicación.

El protocolo Pusher y la integración con Echo

La clave del ecosistema es que Reverb implementa el protocolo de Pusher. Eso significa que Laravel Echo, la librería de cliente que ya usas para escuchar eventos, funciona sin cambios: solo cambias la URL del servidor. Tampoco necesitas adaptar tus eventos ni tus canales: el sistema de broadcasting de Laravel se encarga de publicar los eventos y Reverb los distribuye a los clientes suscritos. La curva de aprendizaje es prácticamente nula si ya has trabajado con broadcasting.

Reverb frente a Pusher y Soketi

La comparativa de 2026 es sencilla. Pusher es un servicio alojado con una DX excelente y una integración impecable, pero su coste crece con el número de conexiones y canales, y a escala acaba pesando en la factura. Soketi es una alternativa autohospedada que también habla el protocolo de Pusher, pero exige mantener un proceso Node.js aparte, una pieza más de infraestructura que operar. Reverb se queda con lo mejor de ambos: corre íntegramente en PHP, no necesita servicios externos y su coste es el de tu propio servidor.

Lee también

Pest 3: el testing elegante de PHP que Laravel usa por defecto

Requisitos e instalación con Laravel 13

Necesitas Laravel 11 o superior (Laravel 13 funciona perfectamente) y PHP 8.2 o posterior. La instalación se hace con Composer en dos pasos:

composer require laravel/reverb

php artisan reverb:install

El comando de instalación publica la configuración y añade las variables de entorno necesarias. Reverb necesita un app id, una key y un secret propios, distintos de la APP_KEY de tu aplicación, para autenticar las conexiones. En el archivo .env quedan así:

BROADCAST_CONNECTION=reverb

REVERB_APP_ID=local-app-id
REVERB_APP_KEY=local-app-key
REVERB_APP_SECRET=local-app-secret
REVERB_HOST=localhost
REVERB_PORT=8080
REVERB_SERVER_HOST=0.0.0.0
REVERB_SERVER_PORT=8080

Conviene entender la diferencia entre los dos grupos de variables: REVERB_SERVER_HOST y REVERB_SERVER_PORT indican dónde escucha el servidor Reverb, mientras que REVERB_HOST y REVERB_PORT son la dirección que Laravel y los clientes usan para conectarse a él. En desarrollo ambos coinciden; en producción apuntan a dominios o puertos distintos, como verás más adelante.

Broadcasting: del evento al navegador

El flujo de tiempo real en Laravel es siempre el mismo: un evento se lanza en el servidor, el broadcasting lo publica en un canal y los clientes suscritos a ese canal lo reciben al instante. Reverb solo interviene en el reparto: recibe el evento de Laravel y lo empuja a las conexiones WebSocket correctas.

Configurar BROADCAST_CONNECTION=reverb

La variable BROADCAST_CONNECTION=reverb le dice a Laravel qué driver usar para publicar los eventos. Con eso, cualquier evento que implemente ShouldBroadcast se envía automáticamente a Reverb, y de ahí a los clientes. No hay que tocar nada más en la configuración de broadcasting.

Un evento de ejemplo y su canal privado

Imagina una tienda que notifica al cliente cuando su pedido cambia de estado. El evento se define así:

use Illuminate\Broadcasting\PrivateChannel;
use Illuminate\Contracts\Broadcasting\ShouldBroadcast;

class OrderShipped implements ShouldBroadcast
{
    public function __construct(public Order $order) {}

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

Los canales privados exigen autorización: el servidor debe verificar que el usuario tiene derecho a escuchar ese canal. La regla se declara en routes/channels.php:

use Illuminate\Support\Facades\Broadcast;

Broadcast::channel('orders.{orderId}', function (User $user, int $orderId) {
    return $user->id === Order::findOrFail($orderId)->user_id;
});

Si la devolución de la función es true, la suscripción se permite; si es false, se rechaza. Es la misma mecánica que con Pusher, así que migrar una base de código existente es cuestión de minutos.

Ejemplo práctico: notificaciones en vivo

Con el evento y la autorización listos, el frontend solo necesita Laravel Echo suscrito al canal. En el archivo de arranque de Echo se cambia la configuración del broadcaster para apuntar a Reverb:

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

window.Echo = new Echo({
    broadcaster: 'pusher',
    key: import.meta.env.VITE_REVERB_APP_KEY,
    wsHost: import.meta.env.VITE_REVERB_HOST,
    wsPort: import.meta.env.VITE_REVERB_PORT,
    forceTLS: false,
    encrypted: true,
    disableStats: true,
});

Como Reverb habla el protocolo de Pusher, el broadcaster sigue siendo 'pusher' en Echo: solo cambian la URL y la key. La suscripción y la escucha del evento son idénticas a las de siempre:

Echo.private('orders.' + orderId)
    .listen('OrderShipped', (e) => {
        toast(`Tu pedido ${e.order.id} está en camino`);
    });

Ese es el ejemplo completo de notificaciones en vivo: un evento en el servidor, una regla de autorización y una suscripción en el cliente. El mismo patrón sirve para chats, dashboards con métricas en tiempo real o marcadores de partidos deportivos.

Producción: Supervisor, Redis y escalado horizontal

Pasar Reverb a producción es más un ejercicio de operaciones que de código. Estos son los tres frentes que hay que cubrir.

Mantener Reverb vivo con Supervisor

Reverb es un proceso de larga duración que debe reiniciarse si falla o si el servidor se reinicia. La forma estándar es Supervisor, el gestor de procesos de Linux. Un archivo de configuración mínimo:

[program:reverb]
command=php /home/forge/example.com/artisan reverb:start --host=0.0.0.0 --port=8080
directory=/home/forge/example.com
autostart=true
autorestart=true
redirect_stderr=true
stdout_logfile=/home/forge/example.com/storage/logs/reverb.log
user=forge

Además, conviene subir el límite de archivos abiertos (ulimit) del proceso: cada conexión WebSocket abierta consume un descriptor de archivo, y el límite por defecto de muchos sistemas (1024) se queda corto en cuanto tienes tráfico real. Un nodo de Reverb soporta del orden de decenas de miles de conexiones simultáneas; el límite práctico son los puertos libres y la memoria.

Escalar con Redis pub/sub y sticky sessions

Cuando un solo proceso no basta, Reverb escala horizontalmente con Redis pub/sub: todos los nodos se suscriben al mismo canal de Redis y se reenvían los eventos entre ellos, de modo que un cliente conectado a cualquier nodo recibe los mensajes publicados desde cualquier otro. En el .env, REVERB_SERVER_HOST se convierte en el host interno del balanceador y REVERB_HOST en la URL pública, normalmente detrás de un proxy con soporte WebSocket. Hay un matiz importante: el balanceador debe usar sticky sessions, porque una conexión WebSocket queda ligada al nodo con el que se estableció; si el balanceador la reenvía a otro nodo, la conexión se rompe. Los presence channels, que trackean quién está conectado, también dependen de Redis para mantener el estado compartido entre nodos.

Monitorizar con Laravel Pulse

Laravel Pulse, el panel de monitorización de Laravel, incluye una tarjeta para Reverb que muestra las conexiones activas, los mensajes enviados y el uso de memoria del servidor en tiempo real. Es la forma más directa de detectar picos de conexiones, nodos con problemas o fugas de memoria antes de que afecten a los usuarios. Con la tarjeta en el panel y las alertas de Supervisor configuradas, el sistema de tiempo real queda monitorizado sin herramientas adicionales.

Conclusión

Reverb convierte el tiempo real en una característica accesible para cualquier equipo Laravel: nada de servicios de pago, nada de procesos Node.js, solo PHP y la infraestructura que ya tienes. Empieza por el ejemplo de notificaciones de esta guía y, cuando lo tengas en producción, escala con Redis y Supervisor con confianza. Si te ha gustado, sigue leyendo el blog para más tutoriales de Laravel y desarrollo web.