Para comparar PM2 vs Supervisor vs systemd, empezaría por el problema que quieres resolver: un servicio que no vuelve tras reiniciar el servidor, un worker que conserva código antiguo o un proceso que arranca dos veces. Cambiar de gestor sin reproducir el fallo puede añadir trabajo sin corregir su causa.
Esta guía ayuda a elegir la supervisión de procesos. Si el proceso vuelve pero repite acciones o pierde tareas, revisa la recuperación del trabajo de bots tras un reinicio: esa decisión también depende de la aplicación y de la cola.
Qué elegir según el entorno y el equipo
| Opción | Cuándo la valoraría | Qué comprobar antes |
|---|---|---|
| PM2 | Aplicaciones Node.js cuyo equipo aprovecha su configuración y gestión de instancias. | Arranque con el usuario correcto, lista de procesos guardada y parada compatible con la aplicación. |
| Supervisor | Workers PHP, Python o Node con una operativa común que el equipo ya conoce. | Proceso en primer plano, reinicio tras salida normal o fallo y tiempo de parada suficiente. |
| systemd | Servicios en un host que ya lo utiliza y cuyo equipo mantiene unidades y logs del sistema. | Usuario, entorno, dependencias, política de reinicio y límites de parada. |
| Gestor de la plataforma | Un servicio gestionado o contenedores donde la plataforma ya controla las instancias. | Qué arranca la plataforma y qué responsabilidad justificaría añadir otro supervisor. |
No migraría un Supervisor bien documentado solo por preferencia. Tampoco daría por hecho que cualquier Linux utiliza systemd. La decisión debe reducir un problema observable y dejar una operativa que el equipo pueda mantener.
Una cadena de supervisión con responsabilidades claras
systemd puede arrancar el servicio de PM2 y PM2 gestionar sus aplicaciones. Es una integración prevista en la documentación de arranque de PM2. El conflicto aparece si otra unidad intenta lanzar además la misma aplicación por su cuenta.
Documentaría la cadena completa: host → gestor → comando → cola o puerto. Para cada nivel, registraría quién inicia, detiene y repone el proceso. En Laravel, Horizon y Supervisor tienen responsabilidades distintas; gestionar una cola y mantener vivo su proceso no son tareas equivalentes.
Qué cambia entre una API Node.js y un worker Laravel
Una API debe dejar de aceptar conexiones y resolver las que mantiene abiertas según su política de parada. El modo cluster de PM2 distribuye conexiones entre procesos Node.js, pero no convierte automáticamente un consumidor de cola en un trabajo seguro con varias instancias. Un reload puede terminar recurriendo a un restart si no completa la recarga.
Un worker Laravel mantiene código en memoria. La documentación de colas de Laravel 12.x explica cómo queue:restart solicita su salida al terminar el trabajo y requiere que el gestor lo arranque de nuevo. Hay que comprobar el cache usado para esa señal y la política ante una salida normal. Consulta la documentación de la versión instalada.
En conexiones que utilizan retry_after, el timeout del worker debe ser menor que ese plazo; SQS utiliza su tiempo de visibilidad. El gestor tiene además su propio tiempo de parada. Son controles diferentes que deben encajar con la duración del trabajo. La guía de colas Laravel en producción desarrolla la parte de aplicación.
Pruebas para aceptar un cambio de gestor
Propondría estas pruebas en un entorno controlado y con datos de prueba. Cada una debe guardar versión, configuración, resultado y responsable:
- Arranque del host: aparece el número previsto de procesos, con usuario y entorno correctos, sin abrir una sesión SSH.
- Caída del proceso: se aplica la política prevista y queda evidencia del motivo del reinicio.
- Fallo persistente: los reinicios siguen la política acordada, generan una alerta y permiten detener el servicio.
- Despliegue con trabajo activo: la parada respeta el límite acordado y los nuevos procesos cargan la versión esperada.
- Vuelta a la versión anterior: se verifica compatibilidad de configuración y datos, además de recuperar el binario o código.
- Resultado funcional: una petición o tarea de prueba produce el resultado esperado; un estado “running” no basta.
En Supervisor revisaría autorestart, stopsignal y stopwaitsecs según su referencia de configuración. En systemd, Restart, RestartSec y TimeoutStopSec según la referencia de unidades de servicio. Los valores deben salir del comportamiento medido, no de copiar una configuración genérica.
Qué observar después del despliegue
Relacionaría reinicios y versión desplegada con edad de la cola, errores y último resultado válido. La guía de alcance de logs, alertas y monitorización ayuda a definir quién recibe una señal y qué debe revisar.
El caso Adslyfy muestra ejecuciones, workers, alertas y capturas para investigar actividad. Es evidencia de visibilidad operativa; no una comparativa medida entre estos gestores ni una garantía de disponibilidad.
Qué incluir al encargar la revisión
Para acotar una intervención pediría el sistema operativo y versiones, mapa de procesos, configuración de arranque sin secretos, procedimiento de despliegue, incidentes repetidos y duración de las tareas. Acordaría qué procesos revisar, qué pruebas ejecutar y qué cambios quedan fuera.
La entrega puede incluir el mapa corregido, configuración versionada, evidencias de las pruebas y procedimiento de recuperación. El esfuerzo depende de hosts, runtimes, diferencias entre entornos y capacidad de probar una parada. La guía para comparar presupuestos de software ayuda a separar diagnóstico, implementación y mantenimiento.
Revisar antes de sustituir herramientas
Dentro de mi trabajo de CTO externo e infraestructura puedo revisar estas decisiones con tu equipo y concretar la implementación necesaria. La atención continuada a incidencias requiere acordar su cobertura.
Si los reinicios o despliegues están interrumpiendo la operación, cuéntame qué proceso falla y qué resultado deja pendiente. Con ese contexto podemos delimitar una primera revisión.