Rode um bot de Telegram 24/7 num VPS: aiogram, systemd, polling vs webhook

Você escreveu um bot de Telegram com aiogram, testou localmente, e ele funciona. Agora ele tem que morar em algum lugar que não dorme quando você fecha o notebook. Uma máquina pequena é a casa natural — mas há uma lacuna entre python bot.py numa sessão SSH e um bot que de fato fica de pé através de quedas, reboots e sua conexão caindo.

Esta é a versão de produção: um virtualenv, o token mantido fora do seu código, um serviço systemd que ressuscita o bot sozinho e uma resposta clara à pergunta que todo mundo eventualmente faz — polling ou webhook?

Por que não só rodá-lo no seu notebook

Um bot precisa de uma conexão de saída estável com o Telegram. Seu notebook dorme, reinicia para atualizações e pula entre redes — cada uma dessas derruba o bot, e os usuários batem numa parede de silêncio. Um VPS mantém essa conexão o tempo todo. Essa é a razão inteira de movê-lo da sua máquina, e é a mesma razão pela qual um bot de Discord também pertence a um servidor.

Se você só quer o caminho mais rápido de "colocar no ar" com um bot mínimo, o passo a passo de hospedar um bot de Telegram cobre isso. Este texto vai um nível mais fundo: aiogram, manuseio seguro do token e saber quando escalar.

O bot, num virtualenv

Faça SSH e mantenha o bot isolado no próprio venv — não instale pacotes no sistema todo, isso torna atualizações e limpeza uma bagunça depois:

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

Um bot aiogram 3 mínimo que lê o token do ambiente, não de uma string hardcoded:

# 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("Vivo e rodando num VPS.")

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

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

Mantenha o token fora do seu código

Nunca cole o token do BotFather em bot.py — um push para um repo público e ele vazou. Coloque-o num arquivo de ambiente legível pelo root em vez disso:

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

Um token vazado está a um /revoke no BotFather de ser consertado — mas qualquer outra coisa vazada numa máquina compartilhada é pior. Um VPS dedicado para o bot é honestamente uma casa mais segura para o token que o seu notebook do dia a dia: se ele vazar, você rotaciona um token, não todo o seu setup.

A parte que o mantém vivo: systemd

É isso que separa um bot que roda de um bot que permanece rodando. Crie o serviço:

# /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

Rode-o como um usuário não-root (botuser acima), não root — se o bot for algum dia comprometido, você quer que ele fique confinado. Depois:

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

Restart=always com RestartSec=3 significa que uma queda — uma atualização ruim do Telegram, uma exceção não tratada, um OOM — traz o bot de volta em três segundos em vez de deixá-lo morto até você notar. Acompanhe ao vivo:

journalctl -u tgbot -f

Esse é todo o seu setup de logging. Sem arquivos de log para rotacionar, sem ferramentas extras — o journald já tem.

Atualizando sem drama de downtime

Quando você muda o código ou atualiza o aiogram:

cd ~/tgbot && source venv/bin/activate
pip install -U aiogram          # se for atualizar a biblioteca
sudo systemctl restart tgbot
journalctl -u tgbot -n 30 --no-pager   # confirme que voltou limpo

O restart pisca o bot por um ou dois segundos. Para um bot de polling isso é invisível aos usuários — o Telegram enfileira as atualizações e as entrega assim que o bot reconecta.

Polling vs webhook — a versão honesta

Esta é a decisão que as pessoas pensam demais. Eis a versão simples:

Polling (start_polling, o que o código acima usa) faz o bot perguntar ao Telegram "algo novo?" numa conexão de longa duração. Ele não precisa de nada além de internet de saída — sem domínio, sem TLS, sem portas de entrada abertas. Roda bem atrás de NAT. Para a esmagadora maioria dos bots, isto é correto e você deveria parar aqui.

Webhook faz o Telegram empurrar atualizações para você, o que significa que você precisa expor um endpoint HTTPS público. Isso exige um domínio e uma porta de entrada alcançável — então ou um IP público dedicado ou um reverse proxy na frente. Mais setup, mais coisas que quebram. O ganho é latência menor e menos sobrecarga em grande escala — milhares de usuários concorrentes, alto volume de atualizações.

A regra prática: comece com polling num plano NAT. Mova para um webhook só quando você de fato tiver ultrapassado o polling — e se você o fizer, é aí que um IP dedicado ganha seu lugar, porque você precisa daquele endpoint HTTPS de entrada.

Quanto custa rodar

Um bot de polling é leve. Ele fica ocioso no long-poll do Telegram e reage a mensagens, então a máquina na maior parte espera:

• Nano de US$3 (1 vCPU / 1 GB) — bom para a maioria dos bots, até os bem tagarelas.
• Micro de US$5 (2 vCPU / 2 GB) — quando o bot mantém um banco de dados (SQLite/Postgres), lida com mídia ou serve muitos usuários.
• Mais alto só se o próprio bot faz trabalho de verdade — processamento de imagem, um modelo local, lógica pesada por mensagem.

O cadastro é só por e-mail e você paga em USDC ou USDT na Base ou Ethereum — sem cartão, sem documento. Um cartão também funciona, mas o on-ramp tem um mínimo de ~US$27, então para um plano de US$3 é mais suave recarregar um saldo pequeno uma vez e deixar as renovações puxarem dele. É só CPU, um datacenter na Alemanha — irrelevante para um bot, vale saber se você precisasse de uma GPU ou de uma região específica.

A conclusão honesta

Um bot de Telegram é uma das coisas mais baratas que você pode auto-hospedar: uma máquina de US$3, uma unit systemd e polling te dão um bot que fica online através de quedas e reboots sem você cuidar dele. Recorra a um webhook e a um plano maior só quando a escala de fato forçar — não porque um tutorial te disse que webhooks são "melhores". Pegue a máquina pequena, mantenha o token num arquivo de ambiente, deixe o systemd cuidar do uptime e — antes de qualquer coisa — rode o checklist de segurança de VPS novo para que a própria máquina fique trancada.

Pronto para hospedar o seu? Um bot de Telegram mal usa recursos — o plano Nano (US$3/mês) o roda 24/7 sem estardalhaço.