PM2 vs Supervisor vs systemd para Node.js y Laravel

Si estas comparando PM2 vs Supervisor vs systemd para Node.js y Laravel, empieza por una regla simple: elige la herramienta mas pequena que te de reinicios fiables, propiedad clara y logs utiles. El gestor equivocado rara vez falla de forma espectacular. Suele crear inestabilidad silenciosa que luego aparece como jobs duplicados, workers desaparecidos o caidas aleatorias tras desplegar.

Esto importa todavia mas cuando tu aplicacion ya depende de colas, schedulers, APIs y servicios web que tienen que comportarse con consistencia. Es la misma disciplina operativa que hay detras de separar bien Nginx y Laravel y aislar infraestructura con criterio: menos misterio, mejor recuperacion.

Para que sirve realmente cada opcion

Las tres herramientas pueden mantener un proceso vivo. Eso no significa que resuelvan el mismo problema.

• PM2 resulta comodo para apps Node.js, cluster mode, variables de entorno y cierta operativa rapida.
• Supervisor es un monitor generico de procesos que funciona en varios lenguajes y se entiende facil.
• systemd es el gestor nativo de servicios en Linux y suele ser la opcion mas limpia para produccion.

La pregunta util no es cual puede reiniciar un proceso. La pregunta util es cual encaja mejor con tu modelo de despliegue, tu ruta de logs y tus limites de fallo.

Mi regla por defecto

En la mayoria de servidores Linux en produccion, systemd deberia ser el punto de partida. Ya forma parte del sistema operativo, encaja con arranque, permisos y journaling, y evita una capa extra de tooling.

PM2 tiene sentido cuando la carga es muy Node.js y el equipo realmente aprovecha sus capacidades. Supervisor sigue encajando en stacks mixtas o patrones operativos heredados, pero no lo anadiria por defecto a un servidor nuevo si systemd ya cubre la necesidad con claridad.

Casos tipicos segun la stack

API Node.js
  -> systemd por defecto
  -> PM2 si el modo cluster y la operativa Node aportan valor real

worker de colas Laravel
  -> systemd por defecto
  -> Supervisor si el equipo ya lo usa bien y esta documentado

host mixto con scripts y utilidades
  -> systemd para servicios base
  -> evita apilar varios gestores sin una razon concreta

Esa ultima linea importa. Cuando un servidor usa PM2 para Node.js, Supervisor para colas y systemd para lo demas, la propiedad operativa se vuelve confusa enseguida.

Errores comunes

El primer error es apilar herramientas sin necesidad. Ejecutar PM2 dentro de un servicio ya controlado por systemd puede funcionar, pero muchas veces oculta quien manda realmente sobre reinicios y apagados.

El segundo error es tratar los bucles de reinicio como si fueran health checks. Un proceso que se reinicia solo puede parecer vivo y seguir fallando en el trabajo de negocio.

El tercer error es mandar los logs a demasiados sitios. Si stdout va a un lado, Laravel a otro y los fallos de cola a un tercero, investigar incidencias se vuelve lento al instante.

El cuarto error es ignorar la semantica del despliegue. Una estrategia de reinicio valida para una API stateless en Node.js puede ser mala para un worker largo de Laravel.

El quinto error es olvidar cumplimiento y trazabilidad. Si los logs incluyen metadatos de request, identificadores de usuario o evidencia sobre datos publicos, retencion y accesos deben estar definidos. La comodidad operativa no justifica un agujero de auditoria.

Checklist practico antes de elegir

• define si el proceso es stateless, en cola o de larga duracion
• decide donde viviran stdout, stderr y logs de aplicacion
• documenta quien reinicia el servicio en cada despliegue
• configura backoff o limites de restart para evitar ruido
• separa con claridad web y workers de cola
• guarda variables de entorno en una ruta controlada
• anota que servicios tocan datos de cliente o datos publicos
• prueba arranque, reinicio y recuperacion en un servidor real
• deja un responsable claro por grupo de procesos
• evita doble supervision salvo razon explicita

Ejemplos que siguen siendo legibles

Una unidad simple de systemd para una API Node.js suele ser suficiente.

[Unit]
Description=Node API
After=network.target

[Service]
WorkingDirectory=/var/www/api/current
ExecStart=/usr/bin/node server.js
Restart=on-failure
User=www-data
Environment=NODE_ENV=production

[Install]
WantedBy=multi-user.target

Una configuracion documentada de Supervisor para workers Laravel tambien puede ser correcta si el equipo la opera bien.

[program:laravel-worker]
command=php /var/www/app/current/artisan queue:work --sleep=3 --tries=3
process_name=%(program_name)s_%(process_num)02d
numprocs=2
autostart=true
autorestart=true
stdout_logfile=/var/log/laravel-worker.log
stopwaitsecs=3600

La sintaxis no es lo importante. Lo importante es que reglas de reinicio, apagado y destino de logs se entiendan de un vistazo.

Como afecta esto a la estabilidad

Estabilidad no es solo uptime. Estabilidad es que un despliegue no mate workers que no debe, que un reboot recupere exactamente los servicios correctos y que un fallo se pueda seguir hasta una definicion de servicio concreta en vez de tres capas superpuestas.

Aqui la monitorizacion deja de ser opcional. Si el gestor de servicios dice "running" pero la cola acumulada, la tasa de error o la antiguedad de jobs dicen lo contrario, sigues teniendo una incidencia. Por eso esta decision conecta directamente con logs, alertas y monitorizacion y tambien con disciplina de acceso como dar SSH sin exponer el servidor.

Cuando tiene sentido contratar a alguien tecnico

Si tu equipo ya sufre jobs duplicados, workers que desaparecen, reinicios poco claros tras cada deploy o servidores donde nadie sabe si manda PM2, Supervisor o systemd, el problema ya no es de sintaxis. Es propiedad operativa.

Ahi es donde servicios tecnicos o apoyo directo mediante CTO tecnico fractional puede ayudar. El trabajo util es mapear procesos, simplificar supervision, cerrar el flujo de logs y decidir que debe quedar explicito antes de que el siguiente fallo lo haga por las malas.

Conclusion

Usa systemd por defecto cuando Linux ya te da las primitivas correctas. Usa PM2 cuando el tooling especifico de Node.js mejora la operativa de verdad. Mantiene Supervisor cuando ya funciona limpio y documentado, no solo por costumbre.

Si necesitas desenredar un host que mezcla Node.js, Laravel y workers con logica de reinicio confusa, usa contacto e incluye el mapa actual de procesos, el flujo de despliegue y donde suelen aparecer los fallos. Con eso se puede simplificar la stack bastante rapido.