Un VPS per un bot Telegram

Molto meno di quanto si venda di solito. Un bot è un processo di lunga durata che passa quasi tutto il tempo ad aspettare: un bot di comandi stateless occupa circa 60 MB, e uno con ORM, scheduler e cache si avvicina a 150 MB. Dopo i circa 300 MB del sistema operativo, una macchina da 1 GB ha ancora spazio per 4 bot pesanti o 12 leggeri. Il numero di UTENTI incide appena, perché Telegram consegna gli aggiornamenti al vostro processo uno alla volta, non una connessione per utente. Ciò che cambia la risposta è lo stato che tenete voi in memoria: una cache grande, un database in-process, un modello.

Long polling per iniziare, webhook quando serve. Con il long polling il bot apre una connessione in uscita verso Telegram e attende: non servono dominio, certificato né porta aperta, quindi funziona dietro NAT ed è il modo più rapido per partire. Con un webhook è Telegram a connettersi a VOI, quindi servono un indirizzo pubblico, un certificato TLS valido e una porta aperta su internet; in cambio si elimina del tutto il ciclo di polling e si scala meglio quando il bot è davvero molto attivo. Entrambi funzionano bene sulla macchina più piccola qui. Il motivo onesto per passare è il carico o la latenza, non la moda.

Sono limiti di Telegram, non nostri: un bot che usa la Bot API pubblica può scaricare file fino a 20 MB e caricarne fino a 50 MB. Gestire un proprio server Bot API porta il limite a 2 GB e, soprattutto, fa sì che i file arrivino sul disco del vostro server invece di passare per quello di Telegram. È l'unico cambiamento che modifica davvero la macchina di cui avete bisogno: di colpo disco e traffico contano, ed è per questo che la tabella qui sopra abbina BD-8 a quella riga e non alle altre.

Un bot testuale, mai. Un bot multimediale, forse, e vale trenta secondi di calcolo: dimensione media dei file × messaggi al giorno × 30. Cinquantamila note vocali al giorno da 3 MB fanno circa 4.3 TB al mese, oltre la soglia della maggior parte dei piani economici e lontano dai 32 TB di BD-8, o dalla linea Unmetered, dove la questione non si pone. Contano entrambe le direzioni: un file che il bot riceve e uno che invia sono entrambi traffico.

Un'unità systemd, non una sessione screen. Scrivete un piccolo file di servizio con Restart=always, abilitatelo, e il bot si riavvia dopo un crash e dopo un reboot senza che dobbiate essere svegli. È il motivo più comune per cui un bot "va giù" su un VPS, e non è un problema di hosting: un processo avviato a mano muore con la sessione SSH che lo ha avviato. Docker con una restart policy fa lo stesso lavoro, se preferite pacchettizzarlo così.

Sì, e la maggior parte dovrebbe farlo. Ognuno è un processo separato con la propria unit systemd e il proprio token; condividono la macchina, il database se volete, e nient'altro. Il calcolo nella tabella risponde esattamente a questa domanda: una macchina da 4 GB ospita 25 bot pesanti prima che la memoria diventi il limite. Teneteli su porte e utenti separati se sono per persone diverse.

Ovunque i vostri utenti possano arrivare e la latenza verso Telegram sia ragionevole: il bot comunica con l'infrastruttura di Telegram, non direttamente con gli utenti, quindi la solita regola del "vicino al pubblico" conta meno che per un sito web. Se il bot serve anche una dashboard web o un'API agli stessi utenti, scegliete la regione in base a quello. Se non siete sicuri, attivate a ore in due regioni, misurate ed eliminate quella che perde: $0.0113 l'ora rende l'esperimento economico.