Um VPS para um bot do Telegram

Bem menos do que costuma ser vendido. Um bot é um processo de longa duração que passa quase todo o tempo esperando: um bot de comandos sem estado fica em torno de 60 MB, e um com ORM, agendador e cache se aproxima de 150 MB. Depois que o sistema operacional ocupa seus 300 MB aproximadamente, uma máquina de 1 GB ainda tem espaço para 4 bots pesados ou 12 leves. O número de USUÁRIOS quase não influencia, porque o Telegram entrega as atualizações uma de cada vez ao seu processo, e não uma conexão por usuário. O que muda a resposta é o estado que você mesmo mantém na memória: um cache grande, um banco de dados no processo, um modelo.

Long polling para começar, webhooks quando fizer diferença. Com long polling, seu bot abre uma conexão de saída para o Telegram e espera: não precisa de domínio, certificado nem porta aberta, o que significa que funciona atrás de NAT e é a forma mais rápida de colocar algo para rodar. Com um webhook, o Telegram se conecta a VOCÊ, então é preciso um endereço público, um certificado TLS válido e uma porta aberta para a internet; em troca, o loop de polling desaparece por completo e a escala é melhor quando o bot está realmente ocupado. Ambos rodam bem na menor máquina daqui. O motivo honesto para mudar é carga ou latência, não moda.

Limites do próprio Telegram, não nossos: um bot que usa a Bot API pública pode baixar arquivos de até 20 MB e enviar até 50 MB. Rodar seu próprio servidor da Bot API eleva isso para 2 GB e, mais importante, faz os arquivos chegarem ao disco do seu servidor em vez de passarem pelo do Telegram. Essa é a única mudança que realmente altera a máquina de que você precisa: de repente, disco e transferência importam, e é por isso que a tabela acima coloca BD-8 nessa linha e não nas outras.

Um bot de texto, nunca. Um bot de mídia, talvez, e vale trinta segundos de aritmética: tamanho médio do arquivo × mensagens por dia × 30. Cinquenta mil mensagens de voz por dia a 3 MB dão cerca de 4.3 TB por mês, o que ultrapassa a franquia da maioria dos planos baratos e está longe dos 32 TB do BD-8, ou da linha não medida, onde a questão nem se coloca. As duas direções contam: um arquivo que seu bot recebe e um que ele envia são ambos tráfego.

Uma unidade systemd, não uma sessão screen. Escreva um pequeno arquivo de serviço com Restart=always, habilite-o, e o bot volta após uma falha e após uma reinicialização sem que você precise estar acordado. Esse é o motivo mais comum para um bot "cair" em um VPS, e não é um problema de hospedagem: um processo iniciado manualmente morre com a sessão SSH que o iniciou. Docker com uma política de reinício faz o mesmo trabalho, se você preferir empacotá-lo assim.

Sim, e a maioria das pessoas deveria. Cada um é um processo separado, com sua própria unidade systemd e seu próprio token; eles compartilham a máquina, o banco de dados se você quiser, e nada mais. A aritmética da tabela responde exatamente a essa pergunta: uma máquina de 4 GB comporta 25 bots pesados antes que a memória seja o limite. Mantenha-os em portas e usuários separados se forem para pessoas diferentes.

Em qualquer lugar que seus usuários alcancem e onde sua latência até o Telegram seja razoável: o bot se comunica com a infraestrutura do Telegram, não diretamente com seus usuários, então a regra habitual de "ficar perto do seu público" importa menos aqui do que para um site. Se o bot também oferece um painel web ou uma API a esses mesmos usuários, dimensione a região para isso. Se tiver dúvidas, implante por hora em duas regiões, meça e destrua a que perder: $0.0113 por hora torna esse experimento barato.