Empieza por cómo recibe eventos el bot
La pregunta más importante no es el precio, sino si tu bot necesita una conexión permanente.
- Bots con webhooks (webhooks de Telegram, Events API de Slack por HTTP, WhatsApp Cloud API, interacciones de Discord por HTTP) solo se ejecutan cuando llega una petición. Encajan en plataformas basadas en peticiones, incluido serverless.
- Bots con gateway o socket (un bot de Discord que lee mensajes por el Gateway, Socket Mode de Slack, long polling de Telegram) mantienen una conexión abierta todo el tiempo. Necesitan un proceso que siga corriendo.
Si no tienes claro cuál estás construyendo, lee primero Webhooks o polling.
Las cinco familias de hosting
| Opción | Buena opción para | Cuidado con |
|---|---|---|
| Workers en el edge (por ejemplo Cloudflare Workers) | Bots con webhooks, baja latencia, tráfico global | Límites de CPU por petición, sin sockets persistentes en una petición normal |
| Funciones serverless (AWS Lambda, funciones de Google Cloud Run, Azure Functions) | Bots con webhooks y tráfico en ráfagas | Arranques en frío, límites de tiempo de ejecución, empaquetado propio de cada plataforma |
| Plataformas de contenedores (Cloud Run, Fly.io, Render, Railway) | La mayoría de los bots, incluidos bots de gateway pequeños | Algunos planes gratuitos suspenden servicios inactivos, lo que rompe los bots de gateway |
| Un VPS pequeño | Bots de gateway, control total, costo predecible | Tú actualizas el sistema, administras TLS y los reinicios |
| Autohospedaje (servidor en casa, Raspberry Pi) | Aprender, bots privados | Cortes de luz y de red, IP dinámicas, exponer puertos de forma segura |
Workers en el edge y serverless
Las plataformas basadas en peticiones encajan de forma natural con los bots de webhooks: pagas (o usas cuota gratuita) por petición, escalan con los picos y no hay servidor que actualizar. A cambio, hay límites. Cloudflare documenta límites de tiempo de CPU por petición y cuotas diarias de peticiones en su plan gratuito, y el trabajo largo debe pasar a una cola o a un mecanismo en segundo plano como ctx.waitUntil o Cloudflare Queues. AWS Lambda tiene un tiempo máximo de ejecución de 15 minutos por invocación: sobra para una respuesta, pero no para un socket permanente.
Reglas para que un bot serverless funcione bien:
- Confirma rápido a la plataforma y haz el trabajo lento después. Slack espera una respuesta HTTP en menos de 3 segundos y Discord espera la respuesta inicial a una interacción en menos de 3 segundos.
- Guarda el estado fuera de la función: una base de datos, un almacén clave-valor o un Durable Object.
- Verifica la firma de cada webhook, porque la URL es pública.
Plataformas de contenedores
Los contenedores son el punto medio más flexible. Entregas un Dockerfile, la plataforma lo ejecuta y eliges entre "escalar a cero" (bien para bots con webhooks) y "siempre encendido" (necesario para bots de gateway). Lee con atención los detalles del plan: varias plataformas suspenden los servicios gratuitos o de hobby tras un tiempo sin tráfico HTTP. Render, por ejemplo, documenta que sus servicios web gratuitos se apagan tras 15 minutos sin tráfico entrante. Un servicio suspendido es aceptable para un bot de webhooks que tolera una primera respuesta lenta, y fatal para un bot de Discord con gateway.
Nuestro generador de configuración de hosting produce un Dockerfile endurecido, un archivo compose, una unidad systemd y una configuración de pm2 como punto de partida.
Un VPS pequeño
Para bots de gateway, un servidor virtual pequeño suele ser la respuesta confiable más sencilla: un proceso supervisado por systemd o por un runtime de contenedores, que se reinicia solo. Un bot que solo reenvía mensajes suele necesitar muy poca memoria, así que los planes más pequeños de la mayoría de los proveedores bastan para empezar. El costo es tu tiempo: actualizaciones del sistema, firewall, certificados TLS si recibes webhooks, respaldos y monitoreo corren por tu cuenta. Opciones comunes son Hetzner Cloud, DigitalOcean y Vultr; compara los precios actuales en sus páginas oficiales. Si recibes webhooks también necesitas un dominio, de cualquier registrador como Namecheap o Cloudflare.
Autohospedaje
Correr un bot en casa es una buena forma de aprender y es razonable para un bot privado. Para algo de lo que dependen tus usuarios, espera caídas por cortes de luz, reinicios del router y cambios del proveedor de internet. Si recibes webhooks en casa, usa un túnel saliente (por ejemplo Cloudflare Tunnel) en lugar de abrir puertos en el router.
Cómo elegir
- Bot con webhooks y tráfico moderado: un worker en el edge o una función serverless. Lo más barato de operar y de mantener.
- Bot de gateway o app con Socket Mode: un contenedor siempre encendido o un VPS pequeño.
- Trabajos pesados (llamadas a IA, procesamiento de medios, scraping permitido): un frontend de webhooks que encola el trabajo y workers en contenedores o en un VPS.
- Requisitos estrictos de residencia de datos: elige un contenedor o VPS fijo en una región y documéntalo en tu aviso de privacidad.
Elijas lo que elijas, agrega un health check, logs estructurados y una alerta del tipo "ninguna actualización correcta en N minutos". La guía de hosting cubre la lista completa.
Fuentes
- Límites de Cloudflare Workers: developers.cloudflare.com/workers/platform/limits
- Cuotas de AWS Lambda: docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html
- Instancias gratuitas de Render: render.com/docs/free
- Slack, responder a eventos: api.slack.com/apis/events-api
- Discord, recibir y responder interacciones: discord.com/developers/docs/interactions/receiving-and-responding
Los límites y planes cambian seguido. Revisa la documentación actual del proveedor antes de decidir.