Procesos persistentes: workers de colas, Horizon y tus programas siempre en marcha

Hay aplicaciones que necesitan algo que en un hosting compartido no había: un programa que no termine nunca. Un worker que procese la cola en cuanto llega un trabajo, Horizon, un consumidor de mensajes o un bot.

Hasta ahora la salida era una tarea cron. En Laravel, el scheduler lanza cada minuto un queue:work --stop-when-empty, que procesa lo pendiente y se para. Funciona, pero un correo de bienvenida puede tardar hasta un minuto en salir, y lo que tiene que estar vivo todo el tiempo, como Horizon, no tenía dónde quedarse.

Ahora, en los planes Avanza, Max y Elástico, tienes procesos persistentes: programas que tu cuenta mantiene siempre en marcha.

Qué puedes dejar en marcha

En Hosting → tu servicio → Herramientas → Procesos hay un bloque nuevo, Procesos persistentes. Pulsas Añadir proceso y eliges:

• Worker de colas: php artisan queue:work con las colas que indiques, en orden de prioridad. Si los trabajos se acumulan, puedes poner varios sobre las mismas colas.
• Horizon: php artisan horizon, que reparte sus propios workers y trae su panel y sus métricas.
• Comando propio: una línea de shell para Symfony Messenger, un consumidor de mensajes, un bot o cualquier programa que trabaje en segundo plano.

Indicas la carpeta de la aplicación y, en el worker y en Horizon, la versión de PHP con la que tienen que correr. En menos de un minuto el proceso pasa de Arrancando a En marcha.

Avanza admite 3 procesos, Max 5 y Elástico 8.

Si se cae, vuelve a arrancar solo

Un vigilante revisa cada minuto los procesos de la cuenta y arranca el que esté caído. Si el programa termina por su cuenta, por ejemplo cuando un worker llega a su --max-time para soltar memoria, vuelve a arrancar en un segundo y recoge la versión publicada en ese momento.

Lo que no hace es insistir sin fin. Si un proceso cae cinco veces seguidas nada más arrancar, se queda En fallo y espera a que lo reinicies, para no gastar la CPU de tu cuenta en algo que no puede arrancar.

Para saber por qué, cada proceso tiene su registro, con una línea cada vez que arranca y otra cada vez que termina. Casi siempre la línea anterior a cada caída explica la causa: una carpeta mal escrita, una extensión de PHP que falta o un servicio al que la aplicación no llega. Lo corriges y pulsas Reiniciar.

Desde el mismo panel los paras, los arrancas, los editas o los borras. Todo corre con el usuario de tu cuenta y dentro de sus recursos, los mismos que usan tus webs.

Con Deploy+, sin acordarte de reiniciar

Un worker carga el código al arrancar y lo mantiene en memoria, así que después de publicar una versión nueva hay que reiniciarlo. Con Deploy+ no tienes que hacer nada: al terminar cada despliegue, y también al volver a una versión anterior, reinicia los procesos persistentes de esa aplicación. Cada worker acaba el trabajo que tiene entre manos y arranca con el código nuevo, y el registro del despliegue dice cómo ha quedado cada uno.

Si conectas un proyecto Laravel, el propio asistente de Deploy+ te ofrece dejar su worker de colas en marcha, con la carpeta ya puesta.

Lo que no cubre

Un proceso persistente es para trabajo en segundo plano. No es para programas que escuchan en un puerto, como un servidor Node.js, una aplicación Python o Laravel Reverb. Para WebSockets en Laravel te recomendamos un servicio compatible con Pusher, como Ably o el propio Pusher, que Laravel admite de serie; lo explicamos en WebSockets en Laravel. Si tu proyecto necesita su propio servidor, lo que necesitas es un VPS.

En Inicia, Webmaster y en las cuentas de un multicuenta no hay procesos persistentes. Las colas se pueden seguir procesando con el scheduler, con hasta un minuto de espera.

Si usas Horizon o quieres las colas en Redis, mira también el Redis persistente, que llega a la vez. Y tienes el paso a paso, con los estados, las opciones de cada tipo y qué hacer si uno se queda en fallo, en la guía de procesos persistentes.