Un VPS para un bot de Telegram

Mucho menos de lo que se suele vender. Un bot es un proceso de larga duración que pasa casi todo el tiempo esperando: un bot de comandos sin estado ronda los 60 MB, y uno con un ORM, un programador de tareas y una caché se acerca a 150 MB. Después de que el sistema operativo ocupe sus 300 MB aproximadamente, una máquina de 1 GB aún tiene espacio para 4 bots pesados o 12 ligeros. El número de USUARIOS apenas influye, porque Telegram entrega las actualizaciones una a una a su proceso, no una conexión por usuario. Lo que sí cambia la respuesta es el estado que usted mantiene en memoria: una caché grande, una base de datos en proceso, un modelo.

Long polling para empezar, webhooks cuando importe. Con long polling, su bot abre una conexión saliente hacia Telegram y espera: no necesita dominio, certificado ni puerto abierto, por lo que funciona detrás de NAT y es la forma más rápida de poner algo en marcha. Con un webhook es Telegram quien se conecta a USTED, así que necesita una dirección pública, un certificado TLS válido y un puerto abierto a internet; a cambio elimina por completo el bucle de sondeo y escala mejor cuando el bot tiene mucha actividad real. Ambos funcionan bien en la máquina más pequeña de aquí. El motivo honesto para cambiar es la carga o la latencia, no la moda.

Son límites de Telegram, no nuestros: un bot que usa la Bot API pública puede descargar archivos de hasta 20 MB y subir hasta 50 MB. Ejecutar su propio servidor de Bot API eleva ese límite a 2 GB y, lo que es más importante, hace que los archivos lleguen al disco de su servidor en lugar de pasar por el de Telegram. Ese es el único cambio que de verdad altera la máquina que necesita: de repente importan el disco y la transferencia, y por eso la tabla de arriba pone BD-8 en esa fila y no en las demás.

Un bot de texto, nunca. Un bot multimedia, posiblemente, y merece treinta segundos de aritmética: tamaño medio de archivo × mensajes al día × 30. Cincuenta mil notas de voz al día de 3 MB son unos 4.3 TB al mes, lo que supera la asignación de la mayoría de planes baratos y queda muy lejos de los 32 TB de BD-8, o de la línea sin medición de tráfico, donde la cuestión no se plantea. Cuentan ambas direcciones: un archivo que el bot recibe y uno que envía son tráfico.

Una unidad de systemd, no una sesión de screen. Escriba un pequeño archivo de servicio con Restart=always, habilítelo y el bot volverá tras un fallo y tras un reinicio sin que usted tenga que estar despierto. Es el motivo más habitual por el que un bot "se cae" en un VPS, y no es un problema de hosting: un proceso iniciado a mano muere con la sesión SSH que lo inició. Docker con una política de reinicio hace lo mismo si prefiere empaquetarlo así.

Sí, y la mayoría debería hacerlo. Cada uno es un proceso independiente con su propia unidad de systemd y su propio token; comparten la máquina, la base de datos si lo desea, y nada más. La aritmética de la tabla responde exactamente a esta pregunta: una máquina de 4 GB aloja 25 bots pesados antes de que la memoria sea el límite. Manténgalos en puertos y usuarios distintos si son para personas diferentes.

En cualquier lugar al que lleguen sus usuarios y con una latencia razonable hacia Telegram: el bot se comunica con la infraestructura de Telegram, no directamente con sus usuarios, así que la regla habitual de "cerca de su público" importa menos aquí que para un sitio web. Si el bot también ofrece un panel web o una API a esos mismos usuarios, elija la región en función de eso. Si no está seguro, implemente por horas en dos regiones, mida y elimine la que pierda: $0.0113 por hora hace que sea un experimento barato.