Laravel Reverb + Nginx: Guía Completa 2026

Laravel Reverb es el servidor WebSocket oficial de Laravel que requiere ser expuesto a través de Nginx como proxy reverso: Nginx escucha en puerto 443 (HTTPS), Supervisor mantiene activo el proceso Reverb en puerto interno 8080, y la comunicación se configura en .env con variables públicas (REVERB_HOST, REVERB_SCHEME=wss) y variables internas (REVERB_SERVER_HOST=127.0.0.1, REVERB_SERVER_PORT=8080).

Laravel Reverb es el servidor WebSocket oficial de Laravel que integra comunicación en tiempo real directamente en la aplicación. A diferencia de servicios externos tipo Pusher o Socket.io, Reverb corre como proceso PHP en tu propio servidor y se comunica con los clientes a través del protocolo WebSocket (wss:// en producción).

¿Qué es Laravel Reverb y por qué lo necesitas en producción?

Reverb no es una librería más. Es un server que levantás en tu máquina y que escucha conexiones WebSocket. Cuando alguien abre tu aplicación en el navegador, no solo carga HTML/CSS/JS, sino que establece una conexión bidireccional persistente hacia Reverb. Cualquier evento que suceda en tiempo real (un nuevo mensaje de chat, una notificación, una actualización de datos) se puede brodcastear a todos los clientes conectados sin que tengan que estar haciendo refresh de la página.

Ahora bien, en desarrollo podés correr Reverb así nomás con php artisan reverb:start, abrir tu navegador y funciona. En producción no podés hacer eso. ¿Por qué? Porque si el proceso se muere, se queda muerto. Nadie se da cuenta, los clientes no pueden conectarse, y tu chat, tu sistema de notificaciones, todo lo que depende de WebSocket se rompe silenciosamente.

Acá entra Supervisor. Es un gestor de procesos que dice “vos ejecutá este comando, yo me encargo de mantenerlo activo”. Si Reverb falla, Supervisor lo reinicia. Si lo detenés manualmente, Supervisor lo levanta de nuevo. Es lo que hace que tu aplicación sea confiable en producción.

Arquitectura: Nginx como proxy reverso hacia Reverb

Imaginá el flujo:

Un usuario abre tu dominio (ejemplo.com). Su navegador hace HTTPS (puerto 443). Ese tráfico llega a Nginx, que es tu broker de tráfico público. Nginx no sabe de WebSockets reales (spoiler: sí sabe, pero el punto es que no los maneja directamente). Nginx ve “esto es una conexión a /app/…”, chequea que sea válido, y hace un proxy reverso hacia 127.0.0.1:8080, que es donde Reverb escucha. Reverb es interno, nunca expongas puerto 8080 directamente a internet.

SSL termination sucede en Nginx. El certificado SSL está en Nginx, no en Reverb. El cliente ve HTTPS. Entre Nginx y Reverb es HTTP plano (127.0.0.1 es loopback, está blindado). En ejecuta procesos locales sin depender de APIs externas profundizamos sobre esto.

Requisitos previos y preparación

Para que esto funcione necesitás:

• Laravel 10 o superior (Reverb no existe en versiones anteriores).
• Nginx ya instalado y sirviendo tu sitio Laravel normal.
• Certificado SSL válido (Let’s Encrypt es gratis y recomendado).
• Supervisor instalado. Si no lo tenés: sudo apt-get install supervisor -y
• Haber ejecutado php artisan install:broadcasting en tu proyecto Laravel (te lo pediremos confirmar en el paso siguiente).

Verificá que los archivos config/reverb.php y routes/channels.php existan en tu proyecto. Si no, algo anduvo mal con el install.

Paso 1: Instalar Laravel Reverb en tu proyecto

Ejecutá en la raíz de tu proyecto Laravel:

php artisan install:broadcasting

El comando te hace preguntas. Decí que sí a todo. Esto instala automáticamente el paquete Reverb de Laravel, Laravel Echo (librería del cliente), y pusher-js en el frontend. Reverb usa el protocolo Pusher bajo el capot (es compatible, eso hace que funcione con Laravel Broadcasting nativo).

Verificá que te creó los archivos. Si no los ves, revisá la salida del comando para errores.

Paso 2: Configurar variables de entorno (.env) para Reverb

Eso sí, acá es donde la mayoría la mete. Hay variables que ve el cliente (el navegador) y variables internas del servidor. Confundirlas es el error clásico.

• BROADCAST_CONNECTION=reverb (decile a Laravel que use Reverb)
• REVERB_APP_KEY=tu-app-key-aleatorio (generá algo random, 32+ caracteres)
• REVERB_APP_ID=1 (ID único de la app, podés dejar 1 si es la única)
• REVERB_APP_SECRET=tu-secret-aleatorio (otro random, 32+ caracteres)
• REVERB_HOST=ejemplo.com (tu dominio público, lo que ve el navegador)
• REVERB_PORT=443 (puerto público, siempre 443 en producción HTTPS)
• REVERB_SCHEME=wss (WebSocket Secure, porque usás HTTPS)
• REVERB_SERVER_HOST=127.0.0.1 (SOLO interno, dónde corre Reverb en tu servidor)
• REVERB_SERVER_PORT=8080 (SOLO interno, el puerto donde escucha Reverb)

Además, configurá las variables de Vite para el frontend:

VITE_REVERB_APP_KEY="${REVERB_APP_KEY}"
VITE_REVERB_HOST="${REVERB_HOST}"
VITE_REVERB_PORT="${REVERB_PORT}"
VITE_REVERB_SCHEME="${REVERB_SCHEME}"

El error común: poner valores públicos en SERVER_*. La máquina nunca debe exponer 8080 directamente. Nginx es la puerta.

Paso 3: Configurar Nginx como proxy reverso para Reverb

Entrá al archivo de configuración de tu sitio en Nginx (típicamente /etc/nginx/sites-available/ejemplo.com o similar). Relacionado: asegura la infraestructura con las mejores prácticas.

Agregá al bloque server un bloque upstream antes de cualquier cosa:

upstream reverb {
server 127.0.0.1:8080;
}

Luego, dentro del server block, agregá dos locations:

location /app {
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_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;
proxy_read_timeout 3600s;
proxy_send_timeout 3600s;
}

location /apps {
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_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;
proxy_read_timeout 3600s;
proxy_send_timeout 3600s;
}

Lo crítico acá: proxy_http_version 1.1 (obligatorio para WebSocket), Upgrade y Connection: upgrade (le dicen a Nginx que cambie el protocolo), y los timeout en 3600 segundos porque las conexiones WebSocket son de larga duración (no querés que Nginx las cierre por inactividad a los 30 segundos).

Testea la sintaxis antes de recargar:

nginx -t

Si dice “syntax is ok”, entonces:

systemctl reload nginx

Paso 4: Configurar Supervisor para mantener Reverb en marcha

Supervisor es la pieza que falta. Es lo que dice “mirá, cuando falla esto, reinicialo solo”.

Creá un archivo en /etc/supervisor/conf.d/reverb.conf con este contenido:

[program:reverb]
process_name=%(program_name)s
command=php artisan reverb:start
autostart=true
autorestart=true
user=www-data
redirect_stderr=true
stdout_logfile=/var/log/supervisor/reverb.log
directory=/ruta/a/tu/proyecto

Reemplazá /ruta/a/tu/proyecto con el path real de tu Laravel.

El tema es que www-data (el usuario de Nginx/PHP-FPM) es quien corre Reverb. Si usás otro usuario, adaptá ahí. Sobre eso hablamos en optimiza el rendimiento de aplicaciones en producción.

Ahora decile a Supervisor que relea sus configuraciones:

sudo supervisorctl reread
sudo supervisorctl update

Levantá el proceso:

sudo supervisorctl start reverb

Verificá que esté corriendo:

sudo supervisorctl status

Debería decir reverb RUNNING. Si dice FATAL o BACKOFF, hay un error. Mirá los logs:

sudo supervisorctl tail reverb

Paso 5: Verificación, testing y troubleshooting

Ahora viene la parte de confirmar que todo anda. Hacé estas verificaciones en orden:

1. ¿Reverb escucha en 8080?

netstat -tlnp | grep 8080

Debería decirte que hay algo escuchando en 127.0.0.1:8080. Si no sale nada, Reverb no levantó. Revisá los logs de Supervisor.

2. ¿Supervisor lo mantiene activo?

sudo supervisorctl status reverb

Debería decir RUNNING con uptime. Si dice STOPPED, ejecutá sudo supervisorctl start reverb.

3. ¿El proxy de Nginx funciona?

curl -v http://127.0.0.1:8080

Esto testea si Reverb responde. No te preocupes si no ves HTML (Reverb no es un servidor web), mirá que no te dé Connection refused.

4. ¿El cliente JavaScript conecta?

Abrí tu aplicación en el navegador. Andá a DevTools → Console. Deberías ver logs de Laravel Echo conectando. Si ves errores tipo “WebSocket connection failed”, verificá que Nginx está recarguando bien y que los timeouts en la config de Nginx son los correctos.

Revisá también /var/log/nginx/error.log en el servidor. Debería estar limpio o solo tenerte algunos warnings de headers. Más contexto en elige la plataforma para tu flujo de despliegues.

Errores comunes y cómo evitarlos

Error 1: “502 Bad Gateway”

Significa que Nginx intentó conectar a 127.0.0.1:8080 y no había nada. Causas posibles: Reverb no está levantado, Supervisor no lo inició, el puerto en la config de Nginx no coincide con el de Reverb. Verificá que REVERB_SERVER_PORT=8080 en .env y que Supervisor status dice RUNNING.

Error 2: “Connection reset” o timeout en WebSocket

El cliente conecta pero se desconecta al instante. Causas: proxy_http_version no está en 1.1 en la config de Nginx, los headers Upgrade y Connection no están, o los timeouts son demasiado bajos. La config que te puse tiene timeouts en 3600 segundos (1 hora), que es lo recomendado.

Error 3: “403 Forbidden” o errores de autenticación

Reverb verifica que REVERB_APP_KEY y REVERB_APP_SECRET coincidan entre cliente y servidor. Verificá que las variables .env en el servidor son exactamente las mismas que compilaste en tu JS. Si cambiaste .env, ejecutá npm run build (o yarn build) de nuevo para que Vite recompile con los valores nuevos.

Error 4: Supervisor “BACKOFF” o “FATAL”

El proceso no levanta. Mirá supervisorctl tail reverb stderr para ver el error exacto. Causas comunes: ruta al proyecto incorrecta, usuario www-data no tiene permisos, o hay un error PHP en el proyecto.

Preguntas Frecuentes

¿Qué es Laravel Reverb exactamente?

Es el servidor WebSocket oficial de Laravel, lanzado en 2024, que integra comunicación en tiempo real sin dependencias externas. Corre como proceso PHP en tu servidor, escucha conexiones WebSocket, y permite que el backend envíe datos al frontend sin que el cliente tenga que hacer polling. Alternativa a Pusher o Socket.io pero de primera parte.

¿Puedo usar Reverb sin Nginx?

Técnicamente sí, si exponés directamente el puerto 8080. Pero es mala idea en producción: perderías SSL termination en Nginx, expondrías el puerto interno, y no tendrías un broker de tráfico. Nginx es el estándar. Si usás otro proxy reverso (Apache, Cloudflare, etc.), aplica la misma lógica.

¿Cuántos clientes puede manejar Reverb en un proceso?

Depende de tu servidor. Un proceso de Reverb con PHP 8.2+ y buena memoria puede manejar miles de conexiones simultáneas (10k+). Si necesitás escalar más, podés correr múltiples procesos de Reverb y distribuir conexiones entre ellos (horizontal scaling), pero eso requiere Redis y arquitectura más compleja.

¿Reverb requiere Redis?

No para un único servidor. Si tenés una máquina con Reverb, no necesitás Redis. Redis se requiere si escalás horizontalmente (múltiples servidores corriendo Reverb) y querés que se pasen mensajes entre instancias. Para una sola máquina, Supervisor + Reverb alcanza.

¿Cómo monitoreo si Reverb sigue vivo?

Supervisorctl status te dice si el proceso está running. Además, podés chequear el log: sudo supervisorctl tail reverb. Para monitoreo más avanzado (memoria, CPU), podés agregar a tu aplicación un endpoint que testee la conexión WebSocket y exponga métricas. Algunos usan Prometheus + Grafana para esto, pero es escalera arriba de lo que cubrimos acá.

Conclusión

Configurar Laravel Reverb en producción con Nginx no es complicado si respetás la arquitectura: Nginx es el broker público (SSL, proxy reverso), Reverb corre silencioso en puerto 8080, Supervisor lo mantiene vivo. Tres componentes, cada uno con un trabajo claro.

La mayoría de los errores viene de confundir puertos, olvidar headers en Nginx, o no setear Supervisor. Hacé el checklist que te puse en el paso 5 y confirma cada punto. Una vez que los clientes se conectan, la comunicación es bidireccional y en tiempo real. Si necesitás alojamiento confiable para una aplicación con Reverb, donweb.com ofrece servidores dedicados y VPS con full control sobre Nginx y Supervisor.

La próxima vez que veas un chat en tiempo real, notificaciones al instante, o actualizaciones de datos sin refresh, recordá que detrás hay un servidor WebSocket como este manteniéndose vivo 24/7.

Fuentes

• How to Configure Laravel Reverb with Nginx in Production — Guía práctica con ejemplos reales de configuración de Nginx y Supervisor.
• Documentación oficial de Laravel Reverb v12 — Documentación canónica del servidor WebSocket de Laravel.
• Repositorio oficial de Laravel Reverb en GitHub — Código fuente, issues y discusiones técnicas.
• How to Set Up Nginx for Laravel Reverb — Configuración detallada de proxy reverso en Medium.
• Deploying Laravel Reverb with Nginx as Proxy — Documentación de FlashPanel sobre deployment con Nginx.