Ejecuta un bot de Telegram 24/7 en un VPS: aiogram, systemd, polling vs webhook

Escribiste un bot de Telegram con aiogram, lo probaste localmente, y funciona. Ahora tiene que vivir en algún sitio que no duerma cuando cierras el portátil. Un VPS pequeño es el hogar natural — pero hay una brecha entre python bot.py en una sesión SSH y un bot que de verdad sigue arriba a través de fallos, reinicios y la caída de tu conexión.

Esta es la versión de producción: un virtualenv, el token mantenido fuera de tu código, un servicio systemd que resucita el bot por su cuenta, y una respuesta clara a la pregunta que todos acaban haciendo — ¿polling o webhook?

Por qué no simplemente ejecutarlo en tu portátil

Un bot necesita una conexión de salida estable a Telegram. Tu portátil duerme, se reinicia para actualizaciones, y salta entre redes — cada una de esas deja caer el bot, y los usuarios chocan con un muro de silencio. Un VPS mantiene esa conexión las 24 horas. Esa es toda la razón para moverlo fuera de tu máquina, y es la misma razón por la que un bot de Discord también pertenece a un servidor.

Si solo quieres el camino más rápido posible de «ponerlo en línea» con un bot mínimo, la guía de alojar-un-bot-de-Telegram cubre eso. Este artículo va un nivel más profundo: aiogram, manejo seguro del token, y saber cuándo escalar.

El bot, en un virtualenv

Conéctate por SSH y mantén el bot aislado en su propio venv — no instales paquetes a nivel de sistema, hace un desastre las actualizaciones y la limpieza después:

sudo apt update && sudo apt install -y python3-venv
mkdir ~/tgbot && cd ~/tgbot
python3 -m venv venv && source venv/bin/activate
pip install -U aiogram

Un bot mínimo de aiogram 3 que lee su token del entorno, no de una cadena codificada a fuego:

# bot.py
import asyncio, logging, os
from aiogram import Bot, Dispatcher
from aiogram.types import Message
from aiogram.filters import CommandStart

logging.basicConfig(level=logging.INFO)
dp = Dispatcher()

@dp.message(CommandStart())
async def start(m: Message):
    await m.answer("Alive and running on a VPS.")

async def main():
    bot = Bot(os.environ["BOT_TOKEN"])
    await dp.start_polling(bot)

if __name__ == "__main__":
    asyncio.run(main())

Mantén el token fuera de tu código

Nunca pegues el token de BotFather en bot.py — un push a un repo público y está filtrado. Ponlo en un archivo env legible por root en su lugar:

sudo tee /etc/tgbot.env >/dev/null <<'EOF'
BOT_TOKEN=123456:your-token-from-botfather
EOF
sudo chmod 600 /etc/tgbot.env

Un token filtrado está a un /revoke en BotFather de arreglarse — pero un cualquier otra cosa filtrada en una máquina compartida es peor. Un VPS dedicado para el bot es honestamente un hogar más seguro para el token que tu portátil diario: si se filtra, rotas un token, no todo tu setup.

La parte que lo mantiene vivo: systemd

Esto es lo que separa un bot que corre de un bot que sigue corriendo. Crea el servicio:

# /etc/systemd/system/tgbot.service
[Unit]
Description=Telegram bot (aiogram)
After=network-online.target
Wants=network-online.target

[Service]
User=botuser
WorkingDirectory=/home/botuser/tgbot
EnvironmentFile=/etc/tgbot.env
ExecStart=/home/botuser/tgbot/venv/bin/python bot.py
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

Ejecútalo como un usuario no-root (botuser arriba), no root — si el bot es comprometido alguna vez, lo quieres encerrado. Luego:

sudo systemctl daemon-reload
sudo systemctl enable --now tgbot

Restart=always con RestartSec=3 significa que un fallo — una mala actualización de Telegram, una excepción no manejada, un OOM — trae el bot de vuelta en tres segundos en lugar de dejarlo muerto hasta que lo notes. Míralo en vivo:

journalctl -u tgbot -f

Esa es toda tu configuración de logging. Sin archivos de log que rotar, sin tooling extra — journald ya lo tiene.

Actualizar sin drama de inactividad

Cuando cambias el código o subes aiogram:

cd ~/tgbot && source venv/bin/activate
pip install -U aiogram          # si actualizas la librería
sudo systemctl restart tgbot
journalctl -u tgbot -n 30 --no-pager   # confirma que volvió limpio

El reinicio hace parpadear el bot por un segundo o dos. Para un bot de polling eso es invisible para los usuarios — Telegram pone las actualizaciones en cola y las entrega una vez que el bot se reconecta.

Polling vs webhook — la versión honesta

Esta es la decisión que la gente sobrepiensa. Aquí está la versión llana:

Polling (start_polling, lo que usa el código de arriba) hace que el bot pregunte a Telegram «¿algo nuevo?» en una conexión de larga duración. No necesita nada más que internet de salida — sin dominio, sin TLS, sin puertos entrantes abiertos. Corre bien detrás de NAT. Para la abrumadora mayoría de los bots, esto es correcto y deberías parar aquí.

Webhook hace que Telegram empuje las actualizaciones a ti, lo que significa que debes exponer un endpoint HTTPS público. Eso requiere un dominio y un puerto entrante accesible — así que o una IP pública dedicada o un reverse-proxy delante. Más configuración, más cosas que se rompen. El beneficio es menor latencia y menos overhead a gran escala — miles de usuarios concurrentes, volumen pesado de actualizaciones.

La regla práctica: empieza con polling en un plan NAT. Pasa a un webhook solo cuando de verdad hayas superado el polling — y si lo haces, ahí es cuando una IP dedicada se gana su lugar, porque necesitas ese endpoint HTTPS entrante.

Cuánto cuesta ejecutarlo

Un bot de polling es ligero. Reposa en el long-poll de Telegram y reacciona a mensajes, así que la máquina sobre todo espera:

• Nano de 3 $ (1 vCPU / 1 GB) — bien para la mayoría de los bots, incluso los bastante parlanchines.
• Micro de 5 $ (2 vCPU / 2 GB) — cuando el bot mantiene una base de datos (SQLite/Postgres), maneja medios, o sirve a muchos usuarios.
• Más alto solo si el bot en sí hace trabajo real — procesamiento de imágenes, un modelo local, lógica pesada por mensaje.

El registro es solo por correo y pagas en USDC o USDT en Base o Ethereum — sin tarjeta, sin documento. Una tarjeta también funciona, pero el on-ramp tiene un mínimo de ~27 $, así que para un plan de 3 $ es más cómodo recargar un pequeño saldo una vez y dejar que las renovaciones tomen de él. Es solo CPU, un centro de datos en Alemania — un no-problema para un bot, bueno saberlo si necesitaras una GPU o una región específica.

El fondo honesto

Un bot de Telegram es una de las cosas más baratas que puedes autoalojar: una máquina de 3 $, una unidad systemd, y el polling te da un bot que está en línea a través de fallos y reinicios sin que lo cuides. Recurre a un webhook y a un plan más grande solo cuando la escala de verdad lo fuerce — no porque un tutorial te dijera que los webhooks son «mejores». Consigue la máquina pequeña, mantén el token en un archivo env, deja que systemd maneje la disponibilidad, y — antes que nada — ejecuta la checklist de seguridad para un VPS nuevo para que la máquina en sí esté cerrada.

¿Listo para alojar el tuyo? Un bot de Telegram apenas usa recursos — el plan Nano (3 $/mes) lo ejecuta 24/7 sin aspavientos.