Cómo mantener tu bot de Discord en línea 24/7

Un bot de Discord solo responde mientras su proceso está en ejecución y conectado al Gateway de Discord. Cierras la terminal, la PC entra en suspensión o el programa falla, y el bot aparece desconectado. Mantenerlo en línea 24/7 significa resolver dos cosas: dónde corre el proceso y quién lo reinicia cuando muere. Los ejemplos usan Node.js y discord.js v14, pero la lógica sirve para cualquier lenguaje.

¿Qué significa mantener un bot en línea 24/7?#

Tu bot abre una conexión WebSocket con el Gateway y la mantiene viva enviando heartbeats. Según la documentación del Gateway, si un heartbeat queda sin confirmación la conexión se considera "zombi" y el cliente debe cerrarla y reconectar. La misma página indica que las desconexiones son esperables y pueden ocurrir en cualquier momento, y que el cliente debe intentar reanudar la sesión.

Las librerías populares manejan esa reconexión. Lo que no pueden hacer es revivir un proceso que murió. Por eso el "24/7" se apoya en tres capas:

1. Una máquina siempre encendida, con conexión estable.
2. Un supervisor que inicie el bot al arrancar y lo reinicie tras cualquier caída.
3. Código que no mata el proceso por errores previsibles.

¿Dónde puedo ejecutar el bot?#

Ejecutarlo en tu PC sirve para desarrollar; bot desconectado cuando se apaga la PC explica por qué. Las opciones sin costo suelen traer límites de horas o suspensión, como se explica en límites del hosting sin costo. Para comparar precios, mira cuánto cuesta hospedar un bot de Discord.

Paso 1: ¿cómo preparo el código para que no se caiga sin motivo?#

Guarda el token en una variable de entorno, nunca en el código (consulta cómo proteger el token de tu bot). Registra también manejadores para los errores que, sin tratar, terminan el proceso de Node.js:

// index.js (discord.js v14)
const { Client, Events, GatewayIntentBits } = require('discord.js');

const client = new Client({ intents: [GatewayIntentBits.Guilds] });

client.once(Events.ClientReady, (readyClient) => {
  console.log(`En línea como ${readyClient.user.tag}`);
});

client.on(Events.Error, (err) => console.error('Error del client:', err));
process.on('unhandledRejection', (err) => console.error('Promesa rechazada:', err));

client.login(process.env.DISCORD_TOKEN).catch((err) => {
  console.error('Fallo al iniciar sesión:', err);
  process.exit(1); // sale con error para que el supervisor lo note y reinicie
});

El manejador de unhandledRejection solo registra el error y mantiene vivo el proceso, así que úsalo para fallos puntuales. Un fallo al iniciar sesión (token inválido, intent sin habilitar) no se resuelve solo: el catch termina el proceso con código 1 en lugar de dejar el bot detenido en silencio. Si Node.js encuentra una excepción sin manejar, el proceso también termina. Por eso el supervisor del siguiente paso es imprescindible, incluso con buen manejo de errores. Para un tutorial del bot en sí, mira cómo hospedar un bot de discord.js o uno de discord.py.

Paso 2: ¿cómo reinicio el bot automáticamente?#

Elige un supervisor. Todos hacen lo mismo: iniciar el bot al arrancar y levantarlo tras una caída.

pm2 (Node.js)#

npm install -g pm2
DISCORD_TOKEN=tu_token pm2 start index.js --name mi-bot
pm2 startup   # imprime un comando con sudo; cópialo y ejecútalo
pm2 save      # guarda la lista para volver tras un reinicio

Según la documentación de pm2, pm2 startup detecta tu sistema de init e imprime el comando a ejecutar, y pm2 save guarda las apps para que reaparezcan tras un reinicio. Después de actualizar Node.js, ejecuta pm2 unstartup y pm2 startup de nuevo. Para no dejar el token en el historial del shell, usa un archivo de configuración de pm2 o carga un .env.

systemd (cualquier lenguaje, Linux)#

Crea /etc/systemd/system/mi-bot.service:

[Unit]
Description=Bot de Discord
After=network-online.target
Wants=network-online.target

[Service]
WorkingDirectory=/opt/mi-bot
EnvironmentFile=/opt/mi-bot/.env
ExecStart=/usr/bin/node index.js
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now mi-bot

Restart=always reinicia el servicio sea cual sea el motivo de la salida, y deja de hacerlo solo si lo detienes con systemctl stop (o si el código de salida figura en RestartPreventExitStatus=), según el manual de systemd. RestartSec=5 espera 5 segundos entre intentos (el valor por defecto es 100 ms, demasiado rápido para un bot con token inválido).

Docker#

docker run -d --name mi-bot --restart unless-stopped --env-file .env mi-bot

Según la documentación de Docker, unless-stopped reinicia el contenedor si termina o si se reinicia el daemon, pero respeta un docker stop manual.

¿Cómo verifico que el bot sobrevive a las caídas?#

No te quedes en "arrancó". Prueba el ciclo de fallo:

1. Revisa los logs (pm2 logs mi-bot o journalctl -u mi-bot -f) y confirma la línea "En línea como ...".
2. Mata el proceso a propósito (pm2 stop no cuenta; usa kill -9 <pid>) y comprueba que el supervisor levanta otro en segundos.
3. Reinicia la máquina y confirma que el bot vuelve solo.
4. Cierra la sesión SSH y verifica que sigue en línea en Discord.

¿Qué errores dejan el bot desconectado?#

• Ejecutar node index.js en una sesión SSH. Al cerrar la sesión, el proceso muere. Usa un supervisor.
• Bucles de reinicio. Un token inválido o una intent sin habilitar hacen que el bot salga al iniciar sesión y el supervisor lo reinicie sin parar. Lee el error en el log. Las causas están en por qué un bot de Discord se desconecta.
• Falta de memoria. El sistema mata el proceso cuando se agota la RAM. Mide el pico de uso y deja margen.
• Olvidar pm2 save o el enable de systemd. El bot funciona hasta el primer reinicio.
• Token en el código. Se filtra por el repositorio y Discord puede restablecerlo.

Cómo hacerlo en Square Cloud#

En Square Cloud, las tres capas de este artículo cambian de dueño. La máquina siempre encendida es el contenedor, sin modo de suspensión ni regla de inactividad. El supervisor es el reinicio automático, activado por defecto en el deploy desde el panel: cuando el proceso termina con error, la aplicación vuelve sola, así que no instalas pm2 ni escribes una unidad de systemd. El código sigue siendo tuyo, y el process.exit(1) del paso 1 es justo la señal que ese reinicio espera. Una salida con código 0 deja la aplicación detenida.

Conviene conocer dos límites desde el principio. Si el bot se queda sin memoria, la aplicación se detiene y no vuelve sola: sube la RAM en sus ajustes e iníciala de nuevo. Y un token inválido hace que el bot salga en el login en cada intento, así que lee el error en los logs en lugar de esperar que se resuelva solo. Los logs se ven en tiempo real en el panel, la CLI y la app móvil, y las líneas de antes de un reinicio siguen visibles.

El token entra como variable de entorno de la aplicación y se aplica en el siguiente reinicio. Haces el deploy por subida de ZIP, CLI, GitHub o la extensión de VS Code, con discord.js, discord.py, JDA, Discord.Net u otra librería de Gateway. El Hobby cuesta R$12,49 al mes con 1 GB de RAM, y un bot empieza en 256 MB. Consulta los detalles en hosting de bots de Discord.