Melhor VPS para hospedar um bot do Telegram: polling, webhooks, IPv4 e custo mensal

O bot responde a todas as mensagens até você fechar a tampa do notebook. Depois disso, os usuários ficam sem resposta. Um pequeno VPS resolve isso por poucos dólares por mês. O melhor VPS para um bot do Telegram depende de como ele recebe as atualizações: ou ele as solicita ao Telegram, ou o Telegram as envia ao bot.

Essa escolha determina as portas e o certificado necessários e se é preciso ter conectividade IPv4 pública.

A versão curta

• Para um único bot em um VPS, use long polling. Não exige domínio, certificado nem porta aberta.
• Webhooks exigem HTTPS na porta 443, 80, 88 ou 8443 e um endereço IPv4 público. O Telegram não entrega webhooks por IPv6.
• 512 MB of RAM is a workable start for one bot with no local database.
• Mantenha o bot ativo com systemd ou com a política de reinicialização do Docker, se você já distribui contêineres.
• Escolha o provedor considerando IPv4 e margem de RAM, não apenas o preço anunciado.

Polling ou webhooks: a escolha que define os requisitos do servidor

Um bot do Telegram recebe atualizações de duas formas. Com long polling, ele chama getUpdates e o Telegram mantém a requisição aberta até chegar uma atualização ou expirar o tempo limite. Assim, todas as conexões partem do seu servidor. Com um webhook, você registra uma URL uma vez com setWebhook, e o Telegram envia cada atualização a ela por POST via HTTPS.

A coluna de webhook segue os requisitos do Telegram para webhooks.

Para saber qual método seu bot usa, consulte a Bot API:

curl "https://api.telegram.org/bot<YOUR_TOKEN>/getWebhookInfo"

Se a resposta contiver "url":"", não há webhook configurado, e o bot pode usar long polling. O bot.start() do grammY usa long polling por padrão; o python-telegram-bot usa run_polling() ou run_webhook().

Para um único bot em seu próprio VPS, eu usaria polling, que também é a recomendação padrão do grammY. Webhooks são preferíveis quando a máquina já executa um proxy reverso (servidor web que encaminha requisições HTTPS ao bot), quando vários bots compartilham um endpoint HTTPS ou em uma plataforma serverless. Nesse caso, o Caddy obtém e renova o certificado sem tarefa cron.

Uma interrupção breve atrasa as mensagens sem perdê-las. Conforme as regras de atualização da Bot API, o Telegram armazena atualizações por até 24 horas até o bot recebê-las, com qualquer um dos métodos, e repete requisições de webhook que falham antes de desistir.

Se o webhook usar sua porta diretamente, restrinja essa porta às faixas de origem publicadas pelo Telegram. Se a porta 443 for compartilhada por um proxy reverso que atende outros sites, aplique a restrição apenas ao caminho do webhook ou use o token secreto do Telegram em vez de bloquear todo o restante do tráfego HTTPS. O guia de webhooks lista duas faixas de origem e avisa que elas podem mudar. Com o UFW como firewall do host:

sudo ufw allow 22/tcp    # keep SSH open before you enable the firewall

sudo ufw allow proto tcp from 149.154.160.0/20 to any port 443

sudo ufw allow proto tcp from 91.108.4.0/22 to any port 443

sudo ufw allow 80/tcp    # if your HTTPS setup uses HTTP validation or redirects HTTP to HTTPS

sudo ufw enable

Altere 443 se o webhook escutar em 80, 88 ou 8443. Essas regras protegem um bot executado diretamente no host. A documentação do firewall do Docker informa que uma porta publicada contorna o UFW; portanto, um contêiner de webhook iniciado com -p 443:443 continua aberto a todos. Defina também um secret_token em setWebhook. O Telegram o envia no cabeçalho X-Telegram-Bot-Api-Secret-Token de cada requisição, e seu manipulador rejeita requisições sem ele.

Como manter o bot ativo: systemd ou Docker

Executar um bot do Telegram 24 horas por dia exige reiniciá-lo após falhas e reinicializações do servidor. Em um VPS, o systemd faz isso, ou o Docker, se o bot for distribuído como imagem.

Uma unidade systemd é um pequeno arquivo de configuração que informa ao sistema de inicialização como iniciar e reiniciar um programa. Crie /etc/systemd/system/telegram-bot.service:

[Unit]
Description=Telegram bot
After=network-online.target
Wants=network-online.target

[Service]
User=bot
WorkingDirectory=/opt/bot
EnvironmentFile=/opt/bot/.env
ExecStart=/opt/bot/venv/bin/python bot.py
# Node: ExecStart=/usr/bin/node bot.js
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Coloque o token em um arquivo .env na pasta do projeto como BOT_TOKEN=... e leia-o com os.environ["BOT_TOKEN"] (Node: process.env.BOT_TOKEN), para mantê-lo fora do código. Depois, copie o projeto para o local adequado e inicie-o:

sudo mkdir -p /opt/bot

sudo cp -r ~/your-bot/. /opt/bot/        # your project, after git clone or scp from your machine; include .env and requirements.txt

sudo apt install -y python3-venv         # Debian/Ubuntu

sudo useradd --system --no-create-home bot

sudo chown -R bot:bot /opt/bot

sudo -u bot python3 -m venv /opt/bot/venv

sudo -u bot /opt/bot/venv/bin/pip install -r /opt/bot/requirements.txt

# Node: skip the venv and pip commands above, then run:

cd /opt/bot && sudo -u bot npm ci

sudo chmod 600 /opt/bot/.env

sudo systemctl daemon-reload

sudo systemctl enable --now telegram-bot

systemctl status telegram-bot    # look for: Active: active (running)

sudo journalctl -u telegram-bot -f    # follow the bot's logs

Restart=always reinicia o bot tanto após uma saída normal quanto após uma falha; on-failure ignora saídas normais, conforme o manual de systemd.service. RestartSec=5 espaça as tentativas, e WantedBy=multi-user.target junto com enable inicia o bot na inicialização do sistema. Se ele continuar reiniciando, sudo journalctl -u telegram-bot -n 50 mostra o rastreamento do erro. Primeiro, verifique se falta BOT_TOKEN.

O equivalente no Docker é uma única opção:

docker run -d --name telegram-bot --restart unless-stopped --env-file .env your-bot-image

docker logs -f telegram-bot

No Compose, a linha é restart: unless-stopped. A documentação da política de reinicialização do Docker informa que o contêiner volta quando encerra ou o daemon reinicia, mas não depois de você pará-lo manualmente. Isso cobre reinicializações da máquina quando o próprio Docker inicia com o sistema, o que ocorre por padrão no Debian e Ubuntu. Em outros sistemas, execute sudo systemctl enable docker.service.

Minha regra: um único script em uma máquina pequena usa systemd, sem um daemon extra na memória. Se você já cria imagens ou executa outros contêineres, use Docker e considere que seu daemon consome parte da RAM.

Nenhuma das ferramentas avisa que o bot caiu. Um monitor push do Uptime Kuma em um segundo servidor pode avisar. O bot chama a URL do monitor periodicamente, e o Uptime Kuma envia um alerta pelo Telegram quando as chamadas param.

Onde a hospedagem gratuita e os servidores domésticos falham

O Render suspende um serviço web gratuito após 15 minutos sem tráfego de entrada, e a documentação do plano gratuito do Render informa que a reativação leva cerca de um minuto. Um bot com polling não recebe tráfego de entrada e, por isso, é interrompido. Um bot com webhook é reativado pelo POST do Telegram, com uma inicialização a frio após períodos sem atividade. Portanto, a viabilidade da hospedagem gratuita para um bot do Telegram depende do método usado.

O guia do grammY lista plataformas serverless como uma boa opção para webhooks, enquanto long polling exige uma máquina em execução contínua. O Fly.io cobra por uso e exige um cartão cadastrado.

Um Raspberry Pi ou PC antigo pode executar um bot com polling enquanto a máquina, a energia e a conexão estiverem funcionando. Webhooks em casa também exigem endereço público e encaminhamento de portas. Para um bot de hobby, qualquer uma dessas opções gratuitas pode bastar.

Um VPS atende aos dois métodos por um preço mensal fixo.

Cinco provedores de VPS comparados para um bot do Telegram

A tabela compara cinco planos pagos de entrada para hospedar bots do Telegram pelos preços mensais anunciados, vigentes em outubro de 2026, antes dos impostos. Os preços promocionais são indicados quando aplicáveis.

O plano somente IPv6 da Vultr não tem IPv4, e o preço da Hetzner não inclui o endereço IPv4. Sem ele, nenhum dos dois pode receber webhooks.

Um bot com polling pode funcionar apenas com IPv6, pois api.telegram.org tem endereço IPv6. Todos os outros destinos acessados também precisam ter um, incluindo repositórios de pacotes, seu host Git e cada API chamada. Verifique cada host antes de escolher:

dig +short AAAA api.telegram.org

dig +short AAAA github.com

dig +short AAAA pypi.org    # repeat for every host your bot or its installs reach

Uma resposta vazia significa que o host não tem endereço IPv6.

512 MB bastam para um bot do Telegram?

Eu começaria com 512 MB para um bot sem banco de dados local. A documentação do python-telegram-bot não especifica requisito de memória. O que divide a máquina determina a necessidade: o sistema operacional, o daemon do Docker, se usado, e qualquer banco de dados local. Meça o consumo.

free -m                   # "available" is your headroom; the Swap row shows swap use

ps -o rss,cmd -p "$(systemctl show -p MainPID --value telegram-bot)"   # bot's resident memory, in KB

docker stats --no-stream  # per-container memory, if the bot runs in Docker

journalctl -k | grep -i "out of memory"   # kernel OOM kills

Uma finalização por falta de memória (OOM) ocorre quando o kernel encerra um processo para liberar RAM. O systemd reinicia o bot, então essa linha de log pode ser a única evidência. Passe para 1 GB quando surgirem finalizações OOM, quando houver uso constante de swap ou antes de adicionar um banco de dados local ou um segundo bot.

Qual escolher

Para um bot, eu escolheria um plano de 512 MB com IPv4 público incluído. A escolha do provedor depende então de preço, margem de recursos e localização dos usuários.

• Menor preço mensal atual: Cloudzy por US$ 2,48 durante a promoção de 50%, com IPv4 e IPv6 incluídos.
• Menor preço atual com IPv4: Cloudzy por US$ 2,48 durante a promoção. IPv4 dedicado e IPv6 estão incluídos.
• 1 GB of headroom for Docker or a small database: Linode, from $5 a month.
• Vários bots ou um banco de dados, com usuários na Europa: Hetzner, com mais recursos por euro nesta tabela quando o plano está disponível (ele aparecia como indisponível em outubro de 2026). Some a tarifa de IPv4 para webhooks.
• Mais disco e transferência com 512 MB: Cloudzy. Entre os planos de 512 MB, oferece mais armazenamento (20 GB NVMe contra 10) e transferência (1 TB contra cerca de 500 GB), com IPv4 e IPv6 incluídos. Pelo preço promocional atual, a Cloudzy também custa menos que os outros planos de entrada desta comparação.

Pelo preço promocional atual, a Cloudzy combina o menor preço mensal desta comparação com mais armazenamento e transferência que os outros planos de 512 MB. O plano de 512 MB da Cloudzy tem cobrança por hora e garantia de reembolso de 14 dias, para você testar o bot por alguns dias antes de se comprometer. Escolha a região mais próxima dos usuários, implante um VPS Linux da Cloudzy e adicione a unidade systemd apresentada acima.

Perguntas frequentes