Alojar bots: VPS, contenedores, PaaS y serverless comparados

Ajusta el entorno al modelo de entrega

Opciones en detalle

Serverless y edge (Cloudflare Workers, AWS Lambda, Google Cloud Run, Deno Deploy). Pagas por petición, escala a cero y el TLS va incluido. Los límites de tiempo de ejecución y la ausencia de sockets persistentes obligan a diseñar con webhooks, colas y estado externo. Excelente para la mayoría de bots de chat. Consulta bots en Cloudflare Workers.

Plataforma como servicio (Render, Railway, Fly.io y similares). Subes un repositorio o un contenedor y obtienes un servicio en marcha, workers en segundo plano, registros y bases de datos gestionadas. Un buen término medio para bots de Gateway.

VPS (Hetzner, DigitalOcean, OVHcloud, Linode y otros). Control total y coste predecible desde pocos dólares al mes. Tú te encargas de actualizaciones, cortafuegos, TLS, supervisión de procesos y copias.

Tu propio ordenador sirve para desarrollar. En producción pierde contra cortes de luz, de red y la suspensión; usa un túnel solo para pruebas.

Ejecutar en un VPS con systemd

# /etc/systemd/system/mybot.service
[Unit]
Description=Mi bot de Discord
After=network-online.target
Wants=network-online.target

[Service]
User=mybot
WorkingDirectory=/opt/mybot
EnvironmentFile=/etc/mybot.env
ExecStart=/usr/bin/node dist/index.js
Restart=always
RestartSec=5
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
ReadWritePaths=/opt/mybot/data

[Install]
WantedBy=multi-user.target

sudo useradd --system --home /opt/mybot mybot
sudo chmod 600 /etc/mybot.env
sudo systemctl daemon-reload && sudo systemctl enable --now mybot
journalctl -u mybot -f

El bot se ejecuta como usuario sin privilegios, se reinicia si falla, lee los secretos de un archivo propiedad de root y ve el sistema en solo lectura.

Ejecutar con Docker Compose

services:
  bot:
    build: .
    restart: unless-stopped
    env_file: .env            # nunca subas este archivo al repositorio
    read_only: true
    tmpfs: [/tmp]
    depends_on: [redis]
    healthcheck:
      test: ["CMD", "node", "healthcheck.js"]
      interval: 30s
      retries: 3
  redis:
    image: redis:7-alpine
    restart: unless-stopped
    volumes: [redis-data:/data]
volumes:
  redis-data:

Usa una imagen base pequeña, ejecuta como usuario no root en el Dockerfile y fija versiones de dependencias con un lockfile.

Webhooks en un VPS

Pon un proxy inverso (Caddy, nginx) delante de tu app para el TLS, o usa un túnel como Cloudflare Tunnel para no abrir puertos de entrada. Expón solo las rutas del webhook; deja los paneles de administración en localhost o tras autenticación.

Lista de operaciones

• Salud: un endpoint /healthz para servicios de webhook, o un latido para workers que vigile un monitor externo.
• Registros: JSON estructurado por stdout, recogido por journald, la plataforma o un servicio de logs. Redacta tokens y datos personales.
• Alertas: bucles de reinicio, tasa de errores, profundidad de la cola y silencio del webhook (sin eventos durante un periodo inusual).
• Copias: bases de datos y cualquier estado local, con una restauración probada.
• Actualizaciones: parches de seguridad automáticos del sistema, actualización periódica de dependencias y despliegues reproducibles.
• Instancia única: solo un proceso debe hacer polling de getUpdates o mantener una sesión de Gateway por shard. Dos copias causan conflictos y respuestas duplicadas.

Consejos de coste

Un bot comunitario típico con webhooks no cuesta nada en los niveles gratuitos de serverless. Los bots de Gateway caben en unos cientos de megas de RAM en un VPS pequeño. Lo caro suele ser la IA y el procesamiento multimedia: mídelos por separado y pon cuotas antes de hacerte viral.