Laravel Reverb en alojamiento compartido: límites y alternativas

Hay funcionalidades que se programan en una tarde y se despliegan en producción en cinco minutos. Y hay otras que, cuando llegan al servidor, descubren que el problema no estaba en el código, sino en dónde vive ese código. La comunicación en tiempo real fue, para este proyecto, del segundo tipo.

Este artículo documenta la experiencia de intentar integrar Laravel Reverb en una aplicación Laravel desplegada en un plan de alojamiento compartido. No es una guía de instalación ni una reseña de ningún proveedor. Es el relato de qué se quería hacer, qué se encontró por el camino y qué se aprendió sobre la diferencia entre tener Laravel disponible y tener un entorno capaz de ejecutar todo lo que Laravel puede hacer.

El proyecto y lo que se quería conseguir

Serna Studio Lab es la aplicación interna que utilizo para gestionar proyectos, documentar pruebas y centralizar el trabajo técnico del estudio. Está construida sobre Laravel 11 y se despliega actualmente en un plan de alojamiento compartido.

El objetivo era concreto: incorporar comunicación en tiempo real al panel de administración. Notificaciones inmediatas, actualizaciones de estado sin recargar la página, esa sensación de que la aplicación responde al instante en lugar de esperar a que el usuario pulse F5. Laravel ofrece una solución de primera parte para esto: Laravel Reverb, el servidor WebSocket oficial del framework.

Lo que parecía una integración directa terminó convertido en una investigación sobre los límites del alojamiento. Esto es lo que ocurrió.

Qué es Laravel Reverb y qué necesita para funcionar

Laravel Reverb es el servidor WebSocket oficial de Laravel, presentado junto con Laravel 11. Se integra con el sistema de broadcasting del framework y sustituye a servicios externos como Pusher o Ably para aplicaciones que necesitan comunicación en tiempo real sin depender de un tercero.

El flujo tiene tres piezas:

• Laravel Echo es la biblioteca JavaScript que se ejecuta en el navegador. Se suscribe a canales y escucha los eventos emitidos desde el servidor.
• El broadcasting de Laravel es el mecanismo que permite emitir eventos desde la aplicación PHP hacia esos canales.
• Reverb es el servidor que mantiene las conexiones WebSocket abiertas y retransmite los eventos a los clientes suscritos.

La diferencia con una petición HTTP convencional es fundamental. Una petición HTTP llega, se procesa, se responde y se cierra. Un servidor WebSocket se ejecuta como un proceso persistente: php artisan reverb:start levanta un servicio que permanece a la escucha de conexiones entrantes. Si ese proceso se detiene, las conexiones se caen y la funcionalidad en tiempo real desaparece. No hay reintento silencioso ni recuperación automática: o el proceso vive, o no hay WebSocket.

En producción, la documentación oficial de Laravel indica que Reverb debe ejecutarse bajo un gestor de procesos como Supervisor, que lo reinicia si falla y lo mantiene activo tras un reinicio del servidor. Además, el servidor web (Nginx, Apache) tiene que redirigir las conexiones WebSocket que llegan por el puerto 443 hacia el puerto interno donde escucha Reverb, y encargarse de la terminación TLS.

Nada de esto es exótico. Es la arquitectura estándar de cualquier aplicación con WebSockets en producción. El problema aparece cuando el entorno donde se despliega la aplicación no permite ejecutar ese proceso persistente ni modificar el enrutado del servidor web.

El problema al desplegarlo en alojamiento compartido

La instalación de Reverb a nivel de dependencias de Composer no presentó problemas. La configuración del archivo config/reverb.php y de las variables de entorno seguía la documentación de Laravel. El código de la aplicación estaba preparado. Hasta ahí, todo dentro de lo esperado.

El problema apareció al intentar ejecutar Reverb como servicio.

Los planes de alojamiento compartido suelen imponer límites estrictos sobre la ejecución de scripts PHP. El más habitual es un tiempo máximo de ejecución que ronda los 60 segundos. También son frecuentes las restricciones sobre el número de procesos PHP simultáneos y sobre la duración de las tareas programadas, que se cancelan si exceden ese mismo umbral. Son límites razonables para un modelo de hosting basado en peticiones HTTP de corta duración, que es exactamente lo que la mayoría de webs necesita.

Un servidor WebSocket no encaja en ese modelo. No es un script que se ejecuta, termina y devuelve una respuesta. Es un proceso que debe permanecer vivo de forma indefinida. Los límites habituales del alojamiento compartido están diseñados para otro tipo de carga, y esa diferencia de modelo es la que hace inviable la arquitectura de Reverb en ese entorno.

Qué características no suelen ofrecer estos planes

Merece la pena concretar qué se echa en falta, porque “procesos persistentes” suena abstracto hasta que se traduce en una lista:

• Ejecución de procesos más allá del tiempo máximo de PHP. Cualquier script que supere el límite configurado se cancela, independientemente de lo que esté haciendo.
• Instalación de un gestor de procesos como Supervisor o systemd. Sin él, un servicio que se cae no se reinicia solo, y tras un reinicio del servidor no vuelve a levantarse.
• Apertura de puertos adicionales para conexiones entrantes. En hosting compartido solo se expone lo que el proveedor decida.
• Modificación del enrutado del servidor web para desviar las conexiones WebSocket hacia el proceso interno. Sin esto, aunque Reverb estuviera corriendo, nadie podría hablar con él desde fuera.
• Control sobre la versión de PHP y las extensiones a nivel de sistema. Algunos planes ofrecen varias versiones entre las que elegir, pero no permiten instalar extensiones que no vengan preinstaladas.
• Acceso a los logs del servidor más allá de los que genera la propia aplicación. Sin esos logs, diagnosticar por qué un servicio no arranca se convierte en adivinación.
• Control sobre el número máximo de procesos simultáneos, que en planes compartidos suele ser bajo y se comparte con el resto de vecinos del servidor.

Esta lista no es una acusación. Es una descripción del modelo. El alojamiento compartido está pensado para sitios que se ejecutan a base de peticiones puntuales, y lo hace bien. Lo que ocurre es que Laravel Reverb no encaja en ese modelo, y quien lo descubre tarde paga el tiempo perdido en intentos que no podían funcionar.

El tiempo perdido: cuando el alojamiento también forma parte del problema

Hay una diferencia importante entre un error de programación y una limitación del entorno. Un error de programación se detecta, se depura y se corrige. Una limitación del entorno obliga a replantear la arquitectura.

En este caso, el código estaba escrito. Las dependencias estaban instaladas. La configuración era correcta. Pero el servicio que hacía funcionar todo eso no podía ejecutarse de forma continuada. No era un problema de Laravel Reverb ni de Laravel Echo. Era un problema de infraestructura.

Este tipo de situaciones son especialmente frustrantes porque no aparecen en el entorno de desarrollo local. En local, php artisan reverb:start funciona. En local, no hay límites de ejecución de 60 segundos ni restricciones sobre procesos persistentes. La diferencia entre desarrollo y producción no está en el código: está en las condiciones de ejecución.

La lección es directa: antes de comprometerse con una arquitectura que requiere procesos persistentes, conviene verificar que el alojamiento permite ejecutarlos y supervisarlos. No basta con que el proveedor ofrezca PHP y MySQL. La aplicación necesita algo más.

Long-polling como alternativa

Cuando el WebSocket no es viable, queda el long-polling. En este proyecto se utilizó como mecanismo de respaldo para mantener parte de la funcionalidad en tiempo real.

El long-polling funciona así: el cliente lanza una petición HTTP al servidor y la mantiene abierta hasta que hay una novedad o hasta que se agota un tiempo de espera. Cuando recibe respuesta, lanza inmediatamente otra petición. Es un ciclo continuo de peticiones y respuestas que simula la actualización en tiempo real sin mantener una conexión persistente.

La diferencia con WebSocket es notable. Un WebSocket establece una conexión bidireccional única que permanece abierta: el servidor puede enviar datos al cliente en cualquier momento sin que el cliente haya preguntado. Con long-polling, el servidor solo puede responder cuando el cliente pregunta. La latencia es mayor y el coste en recursos también: cada ciclo inicializa el framework, autentica la sesión, consulta la base de datos y genera una respuesta. Multiplicado por varios usuarios conectados, el impacto en el servidor puede ser considerable.

No se han realizado mediciones reales de latencia ni de consumo en este proyecto, así que no voy a inventar cifras. Lo que sí se puede afirmar es que el long-polling permitió mantener cierta funcionalidad operativa, pero no es equivalente a una implementación WebSocket. Es una solución de compromiso, no un sustituto.

¿El problema era Laravel Reverb, Laravel Echo o el alojamiento?

Es tentador buscar un culpable único, pero la realidad es más matizada.

• Laravel Reverb hace lo que debe hacer: levantar un servidor WebSocket. Su documentación es clara sobre los requisitos de ejecución. No tiene un defecto que impida su funcionamiento.
• Laravel Echo es la pieza del cliente. Sin un servidor WebSocket al que conectarse, no puede hacer nada. Su papel no es la causa del problema.
• El alojamiento compartido ofrece un producto con unos límites diseñados para otro modelo de uso. No es un fallo del proveedor: es una característica del producto, pensada para peticiones HTTP de corta duración.

La conclusión técnica es que el problema no fue un error de código ni una configuración incorrecta. Fue una incompatibilidad entre los requisitos de la arquitectura y las capacidades del plan de alojamiento contratado. Esa incompatibilidad no siempre es evidente antes de intentar el despliegue, y ese es precisamente el problema.

Alojamiento compartido frente a VPS

Un VPS no es una solución automática. Es un entorno con más control, pero también con más responsabilidad. La siguiente tabla compara ambos modelos en los aspectos que más afectan a una aplicación Laravel con Reverb.

Un VPS ofrece el control necesario para ejecutar Reverb, pero no garantiza que funcione. Hay que configurar el servidor web, gestionar los certificados TLS, supervisar el proceso y asegurar el servidor. Es un cambio de responsabilidad, no una solución mágica.

También conviene distinguir entre un VPS autoadministrado y uno administrado por el proveedor. En el segundo caso, parte de ese mantenimiento vuelve al proveedor, pero también se recuperan algunas de las restricciones que se querían evitar. Merece la pena leer bien qué incluye cada modalidad antes de contratar.

La alternativa que se está valorando

En el momento de escribir este artículo, se está evaluando el traslado de la aplicación a un VPS con mayor control sobre el entorno de ejecución. La decisión no está tomada y no se ha probado la compatibilidad de Reverb en ese nuevo entorno. Lo digo claro para que nadie lea esto como un tutorial de “cómo lo hice y funcionó”.

La migración implicaría revisar, como mínimo:

• La aplicación y sus dependencias de Composer y npm.
• La base de datos, actualmente MariaDB, con PostgreSQL como parte de la arquitectura futura que se está considerando. PostgreSQL no es un requisito de Reverb ni tiene nada que ver con este incidente.
• Las variables de entorno y la configuración de broadcasting.
• Las colas de trabajo, las tareas programadas y los procesos persistentes.
• La configuración de TLS y el enrutado de WebSocket en el servidor web.
• El DNS, que se gestiona a través de Cloudflare.
• Las copias de seguridad y el plan de restauración.
• La seguridad del sistema y la monitorización.
• Un plan de reversión por si algo sale mal a mitad de camino.

No basta con copiar los archivos. Una migración mal planificada puede resolver un problema y crear tres nuevos.

Qué comprobar antes de contratar alojamiento para Laravel Reverb

Si estás valorando usar Reverb en producción, estas preguntas deberían tener respuesta antes de firmar el contrato:

Algunas de estas preguntas solo tienen sentido en un VPS. En un alojamiento compartido, la respuesta suele ser “no” antes de llegar a la mitad de la lista.

Conclusiones

Laravel Reverb funciona. La arquitectura es sólida y la integración con Laravel es limpia. El problema no está en la herramienta, sino en las condiciones del entorno donde se pretende ejecutar.

El alojamiento compartido, con sus límites de ejecución para scripts PHP, no está diseñado para procesos persistentes. Eso no es un defecto oculto ni una estafa: es una característica del modelo de hosting que, sencillamente, no encaja con lo que Reverb necesita.

La conclusión práctica es que elegir alojamiento para una aplicación Laravel implica algo más que comprobar que soporta PHP y MySQL. Implica verificar que soporta los procesos, los puertos y las configuraciones que la arquitectura de la aplicación requiere. Un VPS ofrece ese control, pero también exige asumir la responsabilidad de la configuración y el mantenimiento.

El long-polling permitió mantener parte de la funcionalidad, pero no es una solución equivalente. Es un parche que funciona hasta que la aplicación crece o las necesidades de tiempo real se vuelven más exigentes.

Preguntas frecuentes

¿Qué es Laravel Reverb?

Es el servidor WebSocket oficial de Laravel, integrado con el sistema de broadcasting del framework. Permite comunicación en tiempo real sin depender de servicios externos como Pusher.

¿Necesita Laravel Reverb un proceso en ejecución?

Sí. Reverb se ejecuta como un proceso persistente mediante php artisan reverb:start. Si el proceso se detiene, las conexiones WebSocket se pierden.

¿Puede utilizarse Reverb en un alojamiento compartido?

Depende del proveedor y del plan. En general, los planes de alojamiento compartido no permiten procesos persistentes ni conexiones WebSocket entrantes. Es imprescindible verificar las condiciones del plan concreto antes de intentarlo.

¿Es lo mismo Laravel Echo que Reverb?

No. Laravel Echo es la biblioteca JavaScript del cliente que se suscribe a canales. Reverb es el servidor WebSocket que gestiona las conexiones y retransmite los eventos.

¿Puede sustituirse Reverb por long-polling?

El long-polling puede mantener cierta funcionalidad en tiempo real, pero no es equivalente a WebSocket. La latencia es mayor y el consumo de recursos del servidor también. Es una alternativa de compromiso, no un sustituto.

¿Un VPS resuelve automáticamente los problemas de WebSockets?

No. Un VPS ofrece el control necesario para ejecutar Reverb, pero requiere configurar el servidor web, gestionar TLS, supervisar el proceso y asegurar el servidor. Es una solución viable, pero no automática.

¿Qué hay que comprobar antes de contratar un alojamiento para Laravel?

Principalmente, si permite ejecutar procesos persistentes, si existen límites de tiempo de ejecución para scripts PHP y si el servidor web se puede configurar para redirigir las conexiones WebSocket hacia el proceso de Reverb. También conviene preguntar al soporte si están familiarizados con esta arquitectura.