PM2 y reinicio automático: cómo mantener vivo el proceso

Un proceso Node.js que lanza una excepción sin manejar simplemente muere. Si nadie lo vuelve a levantar, tu bot, API o sitio web se queda caído hasta que te das cuenta. Un supervisor de procesos resuelve eso: vigila tu app y la reinicia cuando se cae. En el ecosistema Node.js, el más usado es PM2.

¿Cómo instalas PM2 e inicias una app?#

Con Node.js instalado (consulta cómo hospedar una app Node.js), instálalo de forma global e inicia tu archivo principal:

npm install pm2 -g
pm2 start app.js --name mi-app
pm2 list
pm2 logs mi-app

pm2 list muestra el estado de cada proceso, pm2 logs sigue la salida en tiempo real y pm2 restart mi-app reinicia a mano. Para detener y quitar de la lista, usa pm2 stop mi-app y pm2 delete mi-app.

Por defecto, autorestart es true: si la app falla o termina, PM2 la vuelve a levantar. Para un script de una sola ejecución (una migración, por ejemplo), desactívalo con --no-autorestart.

¿Cómo usas un ecosystem file?#

Pasar flags por la línea de comandos no escala. El ecosystem file reúne toda la configuración en un archivo versionado:

// ecosystem.config.js
module.exports = {
  apps: [
    {
      name: "mi-app",
      script: "./app.js",
      max_memory_restart: "300M",
      max_restarts: 10,
      restart_delay: 3000,
      kill_timeout: 5000,
      env: { NODE_ENV: "development" },
      env_production: { NODE_ENV: "production" },
    },
  ],
};

Inícialo con pm2 start ecosystem.config.js --env production. El bloque env_production solo se aplica cuando pasas --env production. Nunca guardes secretos (tokens, contraseñas) en ese archivo: léelos de variables de entorno. El archivo usa CommonJS (module.exports); si tu package.json tiene "type": "module", llámalo ecosystem.config.cjs.

¿Qué opciones de reinicio merecen la pena?#

Dos de estas opciones piden cuidado.

max_memory_restart esconde una fuga de memoria, no la arregla. Es un parche útil mientras investigas. Si la app se reinicia cada hora por memoria, el defecto sigue en el código.

Sin restart_delay, un error al arrancar se convierte en un bucle cerrado. La app se cae en milisegundos, PM2 la levanta y se vuelve a caer. Tras max_restarts fallos inestables seguidos, PM2 marca la app como errored y deja de intentarlo. Usa restart_delay o exp_backoff_restart_delay para dar margen a dependencias externas, como una base de datos que todavía está arrancando.

¿PM2 arranca solo cuando el servidor se reinicia?#

No, a menos que se lo pidas. Son dos comandos:

pm2 startup
pm2 save

pm2 startup detecta el sistema de init (systemd, por ejemplo) e imprime el comando que registra PM2 en el arranque: cópialo y ejecútalo (con sudo) antes de pm2 save. pm2 save guarda la lista actual de apps, y PM2 la restaura cuando el servidor arranca. Para restaurarla a mano, usa pm2 resurrect. Después de actualizar Node.js, ejecuta pm2 unstartup y otra vez pm2 startup, para que el servicio apunte al binario nuevo.

¿Cómo usas PM2 dentro de Docker?#

En un contenedor (consulta qué es Docker), usa pm2-runtime, un sustituto del binario node que se ejecuta en primer plano, como espera un contenedor:

FROM node:lts
WORKDIR /app
COPY . .
RUN npm install
RUN npm install pm2 -g
CMD ["pm2-runtime", "ecosystem.config.js"]

PM2 reenvía las señales de cierre a la app. Escucha SIGINT para cerrar conexiones antes de salir: PM2 espera 1600 ms por defecto antes del SIGKILL, algo que se ajusta con kill_timeout. Para un proceso por contenedor, añade --only nombre-de-la-app.

En la mayoría de los casos, sin embargo, PM2 dentro de Docker es redundante: la política de reinicio del propio contenedor ya recrea el proceso que murió.

¿Cuándo prescindir de PM2?#

PM2 solo tiene sentido cuando administras la máquina tú mismo, como en un VPS. Si la plataforma ya reinicia el proceso que se detuvo, se convierte en una capa más que mantener. Un contenedor bajo un orquestador, un servicio de systemd con Restart=always o un hosting con reinicio automático cumplen el mismo papel.

Ten en cuenta que PM2 solo recrea el proceso: no corrige el bug que tumbó la app. Registra los errores y lee los logs (consulta cómo leer los logs de una app) para encontrar la causa.

Cómo hacerlo en Square Cloud#

En Square Cloud, PM2 no es necesario ni recomendable. Los contenedores están siempre encendidos, sin modo de suspensión. El reinicio automático existe en todos los planes y viene activado cuando despliegas desde el panel (en un squarecloud.app escrito a mano, usa AUTORESTART=true): vuelve a levantar el proceso que termina con error.

Despliegas subiendo un ZIP, con la CLI, desde GitHub o con la extensión de VS Code. Si la app necesita configuración, define las variables de entorno en el panel: el cambio se aplica en el siguiente reinicio, sin rebuild. Los logs aparecen en tiempo real en el panel y en la CLI, lo que ayuda a encontrar el motivo de una caída.

Una salvedad: el reinicio automático recrea el proceso, pero no corrige un error de código ni una fuga de memoria. Si la app supera la RAM asignada, se detiene y no vuelve sola: aumenta la memoria en los ajustes, iníciala de nuevo e investiga la causa. Para ver cómo encaja esto en un bot, lee cómo mantener un bot de Discord 24/7.

Mira lo que incluye el hosting en Funcionalidades.