Cómo alojar un bot de Discord 24/7 en un VPS con Node.js y PM2

Si el usuario ya existe, no vuelvas a crearlo: comprueba su home, grupo y shell. Para un bot que solo inicia una conexión saliente al Gateway no hace falta abrir un puerto entrante. Antes de activar UFW, sustituye la regla SSH si tu servidor usa un puerto distinto y confirma que el panel del proveedor ofrece una consola de recuperación.

Un dashboard, un receptor de webhooks o un callback OAuth2 sí cambia este modelo: expón únicamente el puerto del proxy HTTPS necesario, no el proceso Node.js directamente.

2. Instala una rama LTS soportada de Node.js

A fecha de corte del 31 de julio de 2026, Node.js 24 está en Active LTS y Node.js 22 en Maintenance LTS. El security release del 29 de julio publicó 24.18.1 y 22.23.2. Para producción, el proyecto Node recomienda una rama Active LTS o Maintenance LTS en su calendario de releases.

El siguiente bloque instala el binario oficial 24.18.1 para AMD64 o ARM64 y verifica su checksum antes de extraerlo. Si una dependencia exige Node 22, cambia NODE_VERSION a 22.23.2. En una revisión futura, sustituye la versión por el parche LTS vigente tras leer sus notas de seguridad.

Los dos últimos comandos son validaciones que debes ejecutar: revisa que indiquen la rama instalada; este tutorial no presupone su salida.

3. Publica una release reproducible

La estructura releases/ más el enlace current permite cambiar de versión y volver atrás sin sobrescribir la anterior. Prefiere un tag inmutable o un commit revisado, no la punta cambiante de main.

Opción A: clonar con Git

Reemplaza la URL de ejemplo y el tag. En un repositorio privado usa una deploy key de solo lectura; nunca pongas un token personal dentro de la URL.

Guarda el hash que obtengas como parte de tu registro de despliegue; no asumimos cuál será.

Opción B: copiar el proyecto desde tu equipo

Desde tu máquina local, copia el código sin .env, node_modules ni logs:

Después, en el VPS, publícalo con propietario y permisos correctos:

4. Saca el token de Git e instala dependencias

El secreto vivirá en /opt/discord-bot/shared/.env, fuera de cada release. Ábrelo en un editor interactivo para que el token no quede en el historial del shell.

El archivo tendrá esta forma; sustituye el marcador dentro del editor, nunca en un comando compartido:

Aplica permisos y compruébalos. La salida debe mostrar modo 600 y propietario discordbot.

Mantén además esta política en el .gitignore del proyecto y verifica todos los nombres habituales con git ls-files -- '.env' '.env.*'. Solo .env.example puede aparecer, y únicamente si no contiene secretos:

npm ci exige un lockfile y reproduce sus versiones. Si el proyecto compila TypeScript u otros assets con dependencias de desarrollo, genera y prueba el artefacto en CI o instala temporalmente todas las dependencias, ejecuta el build y termina con npm prune --omit=dev. No improvises un npm install en producción que cambie el lockfile.

Antes de PM2 puedes ejecutar una prueba breve en primer plano, sustituyendo src/index.js por tu entrada real. Hazlo solo mientras la instancia local está apagada para no abrir dos sesiones con el mismo bot; detén la prueba con Ctrl+C después de observar el evento Ready.

Si el token apareció en Git, logs, una captura o un comando visible, considera que está comprometido: regénéralo en el Developer Portal, actualiza el archivo y reinicia el proceso. Borrarlo del último commit no invalida la copia expuesta.

Declara solo los Gateway intents y permisos que necesita cada función. La Developer Policy de Discord limita el uso de datos de API a lo necesario para la funcionalidad declarada; pedir más eventos también aumenta caché, superficie de fallo y exposición de datos.

5. Configura PM2 bajo el mismo usuario

Instala PM2 en el prefijo del usuario discordbot. Todos los comandos posteriores de PM2 deben ejecutarse con esa identidad; PM2 mantiene un estado separado por usuario, y mezclar root con discordbot produce listas y daemons distintos.

Crea /opt/discord-bot/ecosystem.config.cjs. El sufijo .cjs conserva module.exports como CommonJS incluso si el proyecto declara "type": "module". Cambia script por la entrada de tu bot.

El ecosystem file de PM2 centraliza el directorio, el script y las políticas de reinicio sin guardar el token. Para un bot pequeño se usa una instancia en modo fork: duplicar procesos sin diseñar sharding, locks y trabajos idempotentes puede duplicar respuestas o tareas programadas.

restart_delay, min_uptime y max_restarts contienen un crash loop; no corrigen la causa. El umbral de max_memory_restart es solo un ejemplo que debes ajustar por debajo de la capacidad del VPS dejando margen al sistema. Reiniciar por memoria puede limitar el impacto inmediato, pero no sustituye perfilar y reparar una fuga.

6. Añade una comprobación de disponibilidad

PM2 conoce el estado del proceso, no el del Gateway. Integra una ruta local en el módulo donde ya existe client. Este ejemplo para discord.js 14.x devuelve 200 solo cuando client.isReady() es verdadero y escucha en loopback, por lo que no abre una superficie pública. Comprueba la API en la documentación de Client de la versión instalada.

Adapta el import si tu proyecto es CommonJS, confirma que DISCORD_TOKEN coincida con el nombre que consume tu aplicación y cierra el servidor en tu manejo de señales si ya tienes apagado ordenado. Luego valida sintaxis, inicia la declaración y revisa estado y logs:

Salir de la vista de logs con Ctrl+C no detiene el bot. Cuando los logs indiquen Ready, ejecuta la prueba local:

La validación completa tiene tres capas: PM2 debe mostrar el proceso online; /healthz debe responder con un estado listo; y un comando slash seguro en un servidor de prueba debe recibir respuesta. No automatices esa prueba iniciando sesión como un usuario normal. Para monitorización externa, haz que el bot emita una señal saliente o publica la ruta solo detrás de HTTPS y autenticación.

7. Restaura el bot después de un reboot

La documentación de startup de PM2 separa dos acciones: registrar el servicio de inicio y guardar la lista que ese servicio restaurará. Como discordbot, ejecuta:

PM2 imprimirá un comando específico para tu sistema, usuario, home y PATH. El exit del bloque vuelve a la cuenta administrativa; desde ella, copia y ejecuta exactamente ese comando generado. No construyas uno a mano ni reutilices el de otro servidor. Después vuelve al usuario del bot y guarda el estado actual:

Programa una ventana de prueba, reinicia el VPS y vuelve a conectar:

Tras recuperar SSH, comprueba el mismo usuario, el servicio, PM2 y la disponibilidad real:

Si el comando generado creó otro nombre de servicio, úsalo en lugar de pm2-discordbot. No marques el despliegue como terminado hasta superar este reboot test. Si actualizas la instalación de Node.js, PM2 recomienda regenerar su startup script para que apunte al runtime vigente; vuelve a ejecutar el flujo de pm2 unstartup/pm2 startup siguiendo los comandos que genere tu host y guarda de nuevo la lista.

8. Controla logs sin llenar el disco

PM2 guarda por defecto los logs en $HOME/.pm2/logs y permite filtrarlos por proceso, como documenta su guía de gestión de logs. Consulta una ventana finita para diagnósticos y vigila también el espacio libre.

Instala la rotación con el mismo usuario. Los valores siguientes son una política inicial, no universal: ajústalos al volumen, espacio y obligaciones de retención de tu bot.

No registres el token, cabeceras de autorización, datos privados ni cargas completas innecesarias. Conserva mensajes útiles: arranque, Ready, desconexión con código, reanudación, error con contexto y apagado.

9. Actualiza por tag y conserva un rollback

Prueba cada tag en CI y, si es posible, en un entorno de staging. En el VPS crea una release nueva sin tocar la activa, instala dependencias y guarda la ruta anterior antes del cambio atómico:

Adapta la comprobación de sintaxis a tu entrada y a tu pipeline; no sustituye tests funcionales. Valida la release antes de guardar el estado:

Si falla, vuelve al enlace anterior. Este rollback cambia código y dependencias, pero no deshace migraciones ni datos:

Para SQLite o cualquier estado mutable, diseña migraciones compatibles hacia atrás o un procedimiento de restauración probado. Mantén al menos una release anterior conocida como buena hasta confirmar la nueva.

10. Copias de seguridad y mantenimiento

• Código: conserva tags/commits inmutables y package-lock.json. Un repositorio remoto no respalda datos creados en producción.
• Secretos: guarda el token en un gestor de secretos o copia cifrada con acceso restringido; nunca en Git ni en un tar sin cifrar.
• Datos: respalda SQLite, archivos subidos y configuraciones persistentes con un método consistente para la aplicación. Una copia de una base activa puede ser irrecuperable si no usa su mecanismo de backup.
• Configuración: conserva una copia revisada de ecosystem.config.cjs —sin secretos— y registra la versión de Node, PM2 y el commit desplegado.
• Restauración: prueba periódicamente que puedes recuperar datos, publicar una release y ejecutar pm2 resurrect a partir de la lista guardada.

Si usas SQLite, su CLI oficial ofrece el comando .backup para copiar la base abierta. Ajusta ambas rutas, guarda el archivo fuera del VPS mediante un canal cifrado y prueba la restauración. Este ejemplo no incluye .env:

Como rutina, revisa alertas de Node y dependencias, aplica parches del sistema en una ventana, comprueba reinicios de PM2, latencia del Gateway, crecimiento de memoria y disco, y prueba un reboot tras cambios en Node, PM2 o systemd.

Diagnóstico: síntomas frecuentes

Con estas comprobaciones, “24/7” deja de significar una terminal abierta y pasa a ser una operación reproducible: proceso supervisado, arranque persistente, señal de salud, datos recuperables y una versión anterior lista para volver.