¿Necesitas un VPS para un bot de Discord?

"¿Necesito un VPS para mi bot?" es una de las primeras dudas de quien saca el bot de la computadora de casa. Para decidir, compara lo poco que el bot exige de un servidor con el trabajo que trae un VPS.

¿Qué exige un bot de Discord de un servidor?#

Muy poco. Un bot es un proceso común de Node.js, Python o similar que abre una conexión WebSocket de larga duración con el Gateway de Discord y se queda recibiendo eventos. No hay servidor web, ni puerto abierto, ni IP fija: la conexión es saliente.

Lo que necesita de verdad:

• un proceso que siga encendido todo el tiempo y vuelva solo después de una caída;
• RAM suficiente para el runtime y la caché de la biblioteca (mira cuánta RAM usa un bot);
• una conexión de red estable para mantener el heartbeat. Si el bot no recibe la confirmación (ACK) del heartbeat, la conexión se considera zombi y hay que cerrarla y reconectar;
• una forma segura de guardar el token, en una variable de entorno.

Nada de esto exige acceso root, un kernel personalizado ni una arquitectura sofisticada. Por eso el VPS es una opción, no una necesidad.

¿Qué entrega un VPS?#

Un VPS es una máquina virtual con acceso root por SSH. Recibes CPU, RAM, disco y un sistema operativo, y puedes instalar lo que quieras. Para quien quiere aprender administración de servidores, o correr el bot junto a otros servicios, tiene mucho sentido.

Además, es barato. Los planes más pequeños de los proveedores internacionales, con 512 MB a 1 GB de RAM y 1 vCPU, suelen costar unos pocos dólares al mes; revisa los precios actuales en la página del proveedor, como la de Droplets de DigitalOcean.

¿Qué deja el VPS en tus manos?#

El precio de la máquina es la parte pequeña. El resto es trabajo:

1. Instalar el runtime en la versión que exige tu biblioteca.
2. Mantener vivo el proceso. Sin un supervisor, el bot muere con el primer error o reinicio.
3. Actualizar el sistema. En Ubuntu Server, unattended-upgrades ya viene instalado y aplica por sí solo las actualizaciones de seguridad, pero únicamente las del sistema. Tu aplicación y sus dependencias siguen siendo cosa tuya.
4. Proteger el acceso: claves SSH en lugar de contraseña, firewall, usuario sin privilegios.
5. Hacer el deploy en cada cambio: copiar archivos, instalar dependencias, reiniciar.
6. Monitorear: leer logs y darte cuenta de que el bot se cayó.

Un ejemplo mínimo de supervisor con systemd, en /etc/systemd/system/bot.service:

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

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

[Install]
WantedBy=multi-user.target

Después, sudo systemctl enable --now bot levanta el bot y lo vuelve a poner en línea tras una caída o un reinicio. El archivo .env guarda DISCORD_TOKEN=... y solo debe poder leerlo el usuario del bot (chmod 600). Los logs salen con journalctl -u bot -f.

Eso es solo el punto de partida: el firewall, las actualizaciones y el deploy siguen siendo tarea tuya.

¿VPS o plataforma de hosting para el bot?#

Para una comparación más amplia, mira VPS, cloud o plataforma de hosting.

¿Cuándo vale la pena un VPS para un bot?#

• Quieres aprender a administrar un servidor Linux.
• El bot depende de software de sistema específico o de una configuración de red poco común.
• Ya tienes un VPS con otros servicios y el bot cabe en él.
• Necesitas control total sobre el entorno.

Si eliges VPS, trata el mantenimiento como parte del costo. Un bot caído por un servidor desactualizado o sin supervisor sale más caro que la diferencia de precio.

¿Cuándo un VPS es excesivo?#

Casi siempre que el bot es "solo un bot": pocos servidores, una biblioteca estándar, ningún software de sistema especial. En ese caso quieres un proceso siempre encendido, y una plataforma de hosting te lo da sin que tengas que volverte administrador de servidores. Mira también cuánto cuesta alojar un bot y cómo mantener el bot en línea 24/7.

Un límite a tener en cuenta: a partir de 2.500 servidores el sharding es obligatorio, y el bot pasa a abrir varias conexiones con el Gateway (shards), muchas veces repartidas en procesos. Eso vale en cualquier hosting y es motivo para planificar la RAM con margen, no para contratar un VPS antes de tiempo.

Cómo hacerlo en Square Cloud#

Square Cloud sigue el camino de la plataforma de hosting, en modelo self-service: tú haces el deploy y controlas la aplicación, sin servidor que administrar. El bot corre en un contenedor aislado y siempre encendido, sin modo de suspensión, y el reinicio automático (activado por defecto en el deploy desde el panel) lo vuelve a levantar cuando el proceso termina con un error.

Para bots de Discord, acepta discord.js, discord.py, JDA, Discord.Net o cualquier biblioteca de Gateway, con sharding y voz. Haces el deploy subiendo un ZIP en el panel, con la CLI, con GitHub (un push hace el deploy) o con la extensión de VS Code. El archivo de configuración squarecloud.app es opcional: el panel lo genera en el deploy, con runtime, memoria y archivo principal, o lo escribes tú en la raíz del proyecto. El token va en las variables de entorno, que se aplican en el siguiente reinicio, sin rebuild.

La RAM del plan es un pool compartido entre las aplicaciones, con un mínimo de 256 MB por aplicación en segundo plano, como un bot. El plan Hobby cuesta R$12,49 al mes (1 GB de RAM), con pago por Pix o tarjeta y sin permanencia. Las demás funciones de hosting están en Funciones de Square Cloud.