VPS para bot do Telegram: do que o bot precisa e como escolher o plano

Uma busca por «VPS para bot» costuma terminar no plano mais barato, e em metade dos casos essa é a escolha certa. Os problemas aparecem depois: um disparo retorna erros 429, o bot não consegue baixar um vídeo enviado pelo usuário, o webhook para de chegar depois da mudança para um novo servidor ou mensagens se perdem durante uma noite fora do ar. Quase tudo isso vem do funcionamento da Bot API, não da falta de núcleos. A seguir: como estimar a carga do seu bot, quais regras do Telegram definem as exigências do servidor e o que conferir no plano antes de pagar.

O que um bot consome de fato

O bot em si é um processo pequeno que recebe atualizações do Telegram e envia respostas. Os recursos vão para tudo o que está em volta dele.

• Rede e latência. Cada ação do bot é uma requisição HTTPS para api.telegram.org. Para um bot de menu, uma conexão estável importa mais que a largura de banda: o tráfego é medido em megabytes por dia.
• Banco de dados. Com algumas centenas de usuários, o SQLite basta. Quando surgem milhares de usuários, pedidos, estatísticas e requisições simultâneas, você precisa de PostgreSQL ou MySQL, o que significa centenas de megabytes de memória e um disco rápido.
• Filas e tarefas em segundo plano. Disparos, lembretes agendados, processamento de pagamentos por serviços externos. Normalmente isso é Redis mais um processo worker separado.
• Arquivos. Conversão de vídeo, geração de imagens e relatórios em PDF pesam mais na CPU e no disco do que todo o resto junto.
• APIs externas. Um bot que repassa requisições para um modelo de IA via API quase não carrega o servidor: ele só espera a resposta. Um bot com modelo local é trabalho para um servidor potente ou uma GPU.

Não avalie «o quanto o bot é pesado», e sim quantos desses componentes ele tem e quais deles rodam o tempo todo.

Limites da Bot API que afetam o servidor

O Telegram tem limites que nenhuma potência de servidor consegue superar. Conheça-os antes de escolher o plano para não pagar por recursos que o bot não vai conseguir usar.

• Velocidade de envio. O Telegram recomenda não enviar mais de uma mensagem por segundo para um mesmo chat, mais de 20 mensagens por minuto para um grupo, nem fazer disparos em massa acima de cerca de 30 mensagens por segundo. Acima disso, a Bot API retorna o erro 429 com o parâmetro retry_after. Um disparo para 10.000 usuários leva vários minutos em qualquer servidor, então você precisa de uma fila com controle de taxa, não de mais núcleos.
• Tamanho de arquivo. Pela Bot API padrão, o bot baixa arquivos de até 20 MB e envia até 50 MB. Para mais que isso, você roda seu próprio servidor Bot API (o projeto open source telegram-bot-api): ele remove o limite de download e permite envios de até 2000 MB. Esse servidor guarda os arquivos em disco, então precisa de espaço em disco e memória de sobra.
• Retenção de atualizações. Enquanto o bot está fora do ar, o Telegram guarda as atualizações recebidas, mas por no máximo 24 horas. Um dia fora do ar sem monitoramento e parte das mensagens dos usuários se perde para sempre.

Exigências do webhook para o servidor

As regras básicas do webhook, HTTPS e as portas 443, 80, 88 ou 8443, estão na página VPS para bot do Telegram. Algumas exigências a mais costumam aparecer só depois que o servidor já foi contratado.

• Somente IPv4. O Telegram entrega webhooks apenas para endereços IPv4; IPv6 não é suportado. Os planos mais baratos sem IPv4 dedicado não servem para webhooks: sobra o long polling ou um IPv4 pago.
• TLS 1.2 ou mais recente. Versões antigas de SSL e TLS 1.0/1.1 são recusadas. O certificado precisa corresponder ao domínio; um certificado autoassinado funciona se você o enviar ao chamar setWebhook.
• Endereços de origem. As requisições vêm das sub-redes 149.154.160.0/20 e 91.108.4.0/22. Você pode abrir a porta do webhook no firewall apenas para elas.
• Cabeçalho secreto. O parâmetro secret_token do setWebhook faz o Telegram adicionar o cabeçalho X-Telegram-Bot-Api-Secret-Token a cada requisição. Verifique-o na sua aplicação para descartar requisições falsificadas.
• Conexões paralelas. Por padrão, o Telegram mantém até 40 conexões simultâneas com o webhook (configurável de 1 a 100). Se o handler for lento, as requisições se acumulam; por isso, passe o trabalho pesado para uma fila e responda ao Telegram na hora.

Enquanto houver um webhook configurado, não é possível receber atualizações com getUpdates. Ao migrar para um novo servidor, suba o bot lá primeiro e só depois aponte o webhook para o novo endereço; use o parâmetro drop_pending_updates apenas se você realmente não precisar das atualizações acumuladas.

Qual plano para qual bot

Referências para um servidor Linux com um bot em Python, Node.js ou Go. Os números já incluem folga para o sistema, os logs e as atualizações.

Para os dois primeiros perfis, veja VPS com 1 GB e VPS com 2 GB. Se os bots rodam em contêineres, você precisa de virtualização KVM, veja VPS para Docker. Um banco de dados com milhares de usuários ganha bastante com NVMe, veja VPS para bancos de dados.

O que conferir no plano

• Um IPv4 dedicado é obrigatório para webhooks e facilita o trabalho com APIs externas.
• Tipo de núcleo. Núcleos compartilhados bastam para um bot de menu. Para conversão de mídia e disparos agendados que coincidem com o horário de pico dos vizinhos, núcleos dedicados são mais estáveis.
• Cobrança por hora. Prática para testar o bot sob carga real antes de pagar um período longo, sem pagar um servidor de teste pelo mês inteiro, veja VPS com cobrança por hora.
• Snapshots e backups. O banco de dados de usuários do bot é o que há de mais valioso no servidor. Confira se os backups estão incluídos ou são cobrados à parte.
• Localização. Para um bot, uma rota estável até o Telegram e as APIs externas importa mais que o ping até os usuários. Se o bot guarda dados pessoais, confira as regras de localização de dados que se aplicam aos seus usuários, como o GDPR na UE.

Como comparar a rede e o disco de diferentes provedores antes de pagar está explicado em Como testar o ping e a velocidade de uma VPS antes de pagar.

Confiabilidade: para o bot não perder mensagens

Reiniciar após uma falha via systemd ou Docker é o mínimo. Não basta se o bot gera receita.

• Monitoramento externo. A cada poucos minutos, verifique se o bot responde: o método getWebhookInfo mostra a quantidade de atualizações pendentes e o último erro de entrega. Uma fila crescendo significa que o bot travou, mesmo que o processo esteja formalmente ativo.
• Backups do banco fora do servidor. Um dump diário para um armazenamento separado. Um snapshot no mesmo provedor não ajuda se o problema for com a conta ou com o data center.
• Atualizações do sistema. Atualizações de segurança automáticas e reinicializações em uma janela noturna, quando o bot tem menos usuários.
• Rotação de logs. Um bot com logs detalhados pode encher um disco pequeno em poucos meses, e aí o banco de dados para de gravar.

O token e o acesso ao servidor

O token do bot dá controle total sobre ele: com o token, qualquer pessoa pode ler as mensagens recebidas e publicar em nome do bot. Guarde-o em variáveis de ambiente ou em um arquivo legível apenas pelo usuário do bot, nunca no repositório. Rode o bot com um usuário separado, sem direitos de root. Entre no servidor com chaves SSH e desative o login por senha. Se o token pode ter vazado, revogue-o no @BotFather com o comando /revoke e gere um novo.

Se o bot recebe pagamentos, mantenha as chaves de pagamento separadas do token e não registre nos logs o corpo completo das requisições do provedor de pagamento.

Quando uma VPS não basta

Um único servidor dá conta de um bot com dezenas de milhares de usuários se as tarefas pesadas passarem por uma fila. Divida quando o banco de dados e os workers começarem a atrapalhar um ao outro: o banco vai para um servidor separado com NVMe, e os workers de mídia para um servidor com mais núcleos. Os princípios gerais para escolher CPU, memória e disco estão em Como escolher uma VPS. Para bots em outros mensageiros há seleções próprias, como VPS para bot do Discord.