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.

Actualizado 22.10.2026 · Encuentra un VPS a tu medida →

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_token de setWebhook hace que Telegram añada la cabecera X-Telegram-Bot-Api-Secret-Token a 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 botQué funciona en el servidorPlan
Menú, comandos, formularios de solicitudBot y SQLite1 vCPU, 1 GB RAM, 10–20 GB SSD
Tienda o reserva de citasBot, PostgreSQL, Redis, panel de administración2 vCPU, 2–4 GB RAM, 30–40 GB NVMe
Envíos masivos a una gran audienciaBot, base de datos, cola, workers2 vCPU, 4 GB RAM, NVMe
Archivos y multimediaBot, servidor Bot API propio, conversión4 vCPU, 4–8 GB RAM, 80 GB de disco o más
Varios bots en DockerContenedores, proxy inverso, base de datos compartida2–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 getWebhookInfo muestra 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.

Preguntas frecuentes

¿Basta un VPS con 1 GB de RAM para un bot?

Sí, para un bot con menú y comandos sobre SQLite. Con PostgreSQL, Redis, un panel de administración o Docker, elige 2 GB, y para procesar vídeo o tener tu propio servidor Bot API, empieza en 4 GB.

¿Por qué Telegram no entrega el webhook a mi servidor?

Causas habituales: el servidor no tiene IPv4 (los webhooks solo funcionan por IPv4), el puerto no es 443, 80, 88 u 8443, el certificado no coincide con el dominio o se usa TLS inferior a 1.2. El método getWebhookInfo muestra el último error de entrega.

¿Un servidor más potente acelera un envío masivo?

No. Telegram limita los envíos masivos a unos 30 mensajes por segundo y a un mensaje por segundo por chat. Necesitas una cola con límite de velocidad, no más núcleos.

¿Cómo puede un bot manejar archivos de más de 20 MB?

La Bot API estándar permite a un bot descargar archivos de hasta 20 MB y subir hasta 50 MB. Para archivos más grandes montas tu propio servidor Bot API, que necesita espacio libre en disco y memoria.

¿Qué pasa con los mensajes si se cae el servidor del bot?

Telegram guarda las actualizaciones entrantes hasta 24 horas. Si el bot vuelve antes, las recibe; las más antiguas se pierden. Por eso necesitas monitorización externa.

¿Cómo protejo un webhook de peticiones falsificadas?

Configura secret_token en setWebhook y comprueba la cabecera X-Telegram-Bot-Api-Secret-Token en tu aplicación. Además, abre el puerto del webhook solo a las subredes de Telegram 149.154.160.0/20 y 91.108.4.0/22.

Más en la guía

  • Cuándo pasar del hosting compartido a un VPSUn VPS no hace más rápida una web por sí solo: te da recursos y libertad y, con ellos, la tarea de gestionar un servidor. Así puedes saber si el hosting se te ha quedado pequeño, cuándo el problema se resuelve sin mudarse y cómo migrar una web sin que los visitantes lo noten.
  • VPS con Windows: licencias, RDP e inicio de sesión seguroUn servidor Windows cuesta más que uno Linux no solo por la memoria: el precio incluye una licencia, y cómo esté planteada decide si cumples las condiciones y cuántas personas pueden conectarse. Además, un puerto RDP expuesto es la vía más habitual por la que se hackean estos servidores. Aquí tienes los dos temas.
  • Cómo probar el ping y la velocidad de un VPS antes de pagarLas cifras de un plan no dicen cuál será la latencia hasta tus usuarios ni lo rápido que es de verdad el disco. Casi todo se puede medir antes de pagar, y el resto, en la primera hora tras el arranque. Estas son las herramientas y cómo interpretar los resultados.
  • Red corporativa en un VPS: acceso remoto a la oficinaUn servidor alquilado puede convertirse en el centro de la red privada de una empresa: los empleados en remoto y las sucursales se conectan a través de él al ERP, al servidor de archivos, al CRM y a Git. Estos son los esquemas habituales, los protocolos, los requisitos del servidor y la seguridad básica.
  • Cómo elegir un VPS: los 7 parámetros que decidenDos planes con los mismos «2 núcleos, 4 GB, 50 GB» pueden diferir varias veces en velocidad y el doble en precio un año después. Esto es lo que hay detrás de cada línea de un plan VPS y lo que conviene revisar antes de pagar.
  • VPS o VDS: ¿hay diferencia y qué importa de verdad?En la mayoría de los mercados VPS y VDS significan lo mismo: un servidor virtual. La diferencia que de verdad afecta a tu trabajo no está en el nombre, sino en el tipo de virtualización y en si los recursos están garantizados.