VPS para un bot de Telegram: qué necesita el bot y cómo elegir plan
Un bot con menú y unos cuantos comandos funciona sin problemas en el servidor más barato, mientras que un bot con envíos masivos, archivos y base de datos choca con límites muy distintos. Esto es lo que consume realmente un bot, qué límites de Telegram condicionan la elección del servidor y cómo evitar pagar de más.
Buscar «VPS para un bot» suele acabar en el plan más barato, y la mitad de las veces es la decisión correcta. Los problemas llegan después: un envío masivo devuelve errores 429, el bot no puede descargar un vídeo que ha mandado un usuario, el webhook deja de llegar tras mudarse a otro servidor o se pierden mensajes durante una noche de caída. Casi todo esto se debe a cómo funciona la Bot API, no a la falta de núcleos. A continuación: cómo estimar la carga de tu bot, qué reglas de Telegram fijan los requisitos del servidor y qué revisar en un plan antes de pagar.
Qué consume realmente un bot
El bot en sí es un proceso pequeño que recibe actualizaciones de Telegram y envía respuestas. Los recursos se van en todo lo que lo rodea.
- Red y latencia. Cada acción del bot es una petición HTTPS a api.telegram.org. Para un bot de menú importa más una conexión estable que el ancho de banda: el tráfico se mide en megabytes al día.
- Base de datos. Con unos cientos de usuarios basta SQLite. Cuando hay miles de usuarios, pedidos, estadísticas y peticiones simultáneas, necesitas PostgreSQL o MySQL, lo que supone cientos de megabytes de memoria y un disco rápido.
- Colas y tareas en segundo plano. Envíos masivos, recordatorios programados, procesamiento de pagos mediante servicios externos. Normalmente es Redis más un proceso worker aparte.
- Archivos. La conversión de vídeo, la generación de imágenes y los informes en PDF cargan la CPU y el disco más que todo lo demás junto.
- API externas. Un bot que reenvía peticiones a un modelo de IA mediante una API apenas carga el servidor: solo espera la respuesta. Un bot con un modelo local es trabajo para un servidor potente o con GPU.
No estimes «cuánto pesa el bot», sino cuántos componentes de este tipo tiene y cuáles funcionan todo el tiempo.
Límites de la Bot API que afectan al servidor
Telegram tiene límites que ninguna potencia de servidor va a levantar. Conócelos antes de elegir plan para no pagar por recursos que el bot no puede aprovechar.
- Velocidad de envío. Telegram desaconseja enviar más de un mensaje por segundo a un mismo chat, más de 20 mensajes por minuto a un grupo y envíos masivos a más de unos 30 mensajes por segundo. Por encima de eso, la Bot API devuelve el error 429 con el parámetro
retry_after. Un envío a 10.000 usuarios tarda varios minutos en cualquier servidor, así que necesitas una cola con límite de velocidad, no más núcleos. - Tamaño de archivo. Con la Bot API estándar, un bot descarga archivos de hasta 20 MB y sube hasta 50 MB. Para más, montas tu propio servidor Bot API (el proyecto de código abierto telegram-bot-api): elimina el límite de descarga y permite subir hasta 2000 MB. Ese servidor guarda los archivos en disco, así que necesita espacio libre en disco y memoria.
- Conservación de actualizaciones. Mientras el bot está caído, Telegram guarda las actualizaciones entrantes, pero no más de 24 horas. Un día de caída sin monitorización y parte de los mensajes de los usuarios se pierde para siempre.
Requisitos del webhook para el servidor
Las reglas básicas del webhook, HTTPS y los puertos 443, 80, 88 u 8443, se explican en la página VPS para un bot de Telegram. Hay algunos requisitos más que suelen aparecer solo después de comprar el servidor.
- Solo IPv4. Telegram entrega los webhooks únicamente a direcciones IPv4; IPv6 no está soportado. Los planes más baratos sin IPv4 propia no sirven para webhooks: te quedan el long polling o una IPv4 de pago.
- TLS 1.2 o superior. Las versiones antiguas de SSL y TLS 1.0/1.1 se rechazan. El certificado debe coincidir con el dominio; un certificado autofirmado funciona si lo subes al llamar a
setWebhook. - Direcciones de origen. Las peticiones llegan desde las subredes 149.154.160.0/20 y 91.108.4.0/22. Puedes abrir el puerto del webhook en el firewall solo para ellas.
- Cabecera secreta. El parámetro
secret_tokendesetWebhookhace que Telegram añada la cabeceraX-Telegram-Bot-Api-Secret-Tokena cada petición. Compruébala en tu aplicación para descartar peticiones falsificadas. - Conexiones paralelas. Por defecto, Telegram mantiene hasta 40 conexiones simultáneas con el webhook (configurable de 1 a 100). Si el manejador es lento, las peticiones se acumulan, así que pasa el trabajo pesado a una cola y responde a Telegram de inmediato.
Mientras hay un webhook configurado, no puedes recibir actualizaciones con getUpdates. Al mudarte a otro servidor, arranca primero el bot allí y después apunta el webhook a la nueva dirección; usa el parámetro drop_pending_updates solo si de verdad no necesitas las actualizaciones en cola.
Qué plan para cada bot
Referencias para un servidor Linux con un bot en Python, Node.js o Go. Las cifras incluyen margen para el sistema, los logs y las actualizaciones.
| Perfil del bot | Qué funciona en el servidor | Plan |
|---|---|---|
| Menú, comandos, formularios de solicitud | Bot y SQLite | 1 vCPU, 1 GB RAM, 10–20 GB SSD |
| Tienda o reserva de citas | Bot, PostgreSQL, Redis, panel de administración | 2 vCPU, 2–4 GB RAM, 30–40 GB NVMe |
| Envíos masivos a una gran audiencia | Bot, base de datos, cola, workers | 2 vCPU, 4 GB RAM, NVMe |
| Archivos y multimedia | Bot, servidor Bot API propio, conversión | 4 vCPU, 4–8 GB RAM, 80 GB de disco o más |
| Varios bots en Docker | Contenedores, proxy inverso, base de datos compartida | 2–4 vCPU, 4 GB RAM, KVM |
Para los dos primeros perfiles, consulta VPS con 1 GB y VPS con 2 GB. Si los bots viven en contenedores necesitas virtualización KVM, consulta VPS para Docker. Una base de datos con miles de usuarios gana mucho con NVMe, consulta VPS para bases de datos.
Qué revisar en un plan
- Una IPv4 propia es obligatoria para los webhooks y facilita el trabajo con API externas.
- Tipo de núcleos. Los núcleos compartidos valen para un bot de menú. Para conversión multimedia y envíos programados que coinciden con las horas punta de los vecinos, los núcleos dedicados son más estables.
- Facturación por horas. Práctica para probar el bot con carga real antes de pagar un periodo largo, sin pagar un servidor de pruebas todo el mes; consulta VPS con pago por horas.
- Snapshots y copias de seguridad. La base de datos de usuarios del bot es lo más valioso del servidor. Comprueba si las copias están incluidas o se cobran aparte.
- Ubicación. Para un bot importa más una ruta estable hacia Telegram y las API externas que el ping a los usuarios. Si el bot guarda datos personales, revisa las normas de residencia de datos que se aplican a tus usuarios, como el RGPD en la UE.
Cómo comparar la red y el disco de distintos proveedores antes de pagar se explica en Cómo probar el ping y la velocidad de un VPS antes de pagar.
Fiabilidad: que el bot no pierda mensajes
Reiniciar tras un fallo con systemd o Docker es lo mínimo. No basta si el bot genera ingresos.
- Monitorización externa. Cada pocos minutos, comprueba que el bot responde: el método
getWebhookInfomuestra el número de actualizaciones pendientes y el último error de entrega. Una cola que crece significa que el bot está atascado aunque el proceso siga vivo formalmente. - Copias de la base de datos fuera del servidor. Un volcado diario a un almacenamiento aparte. Un snapshot en el mismo proveedor no ayuda si el problema está en la cuenta o en el centro de datos.
- Actualizaciones del sistema. Actualizaciones de seguridad automáticas y reinicios en una ventana nocturna, cuando el bot tiene menos usuarios.
- Rotación de logs. Un bot con logs detallados puede llenar un disco pequeño en pocos meses, y entonces la base de datos deja de escribir.
El token y el acceso al servidor
El token del bot da control total sobre él: con el token cualquiera puede leer los mensajes entrantes y publicar en nombre del bot. Guárdalo en variables de entorno o en un archivo que solo pueda leer el usuario del bot, nunca en el repositorio. Ejecuta el bot con un usuario aparte sin permisos de root. Entra al servidor con claves SSH y desactiva el inicio de sesión con contraseña. Si el token puede haberse filtrado, revócalo en @BotFather con el comando /revoke y genera uno nuevo.
Si el bot acepta pagos, guarda las claves de pago separadas del token y no registres en los logs los cuerpos completos de las peticiones del proveedor de pagos.
Cuándo no basta con un VPS
Un solo servidor aguanta un bot con decenas de miles de usuarios si las tareas pesadas pasan por una cola. Separa los componentes cuando la base de datos y los workers empiecen a estorbarse: la base de datos pasa a un servidor aparte con NVMe y los workers multimedia, a un servidor con más núcleos. Los principios generales para elegir CPU, memoria y disco están en Cómo elegir un VPS. Para bots de otros mensajeros hay selecciones aparte, como VPS para un bot de Discord.