Miglior VPS per bot Telegram: polling, webhook, IPv4 e costo mensile

Il bot risponde a ogni messaggio finché non chiudi il portatile, poi tace. Un piccolo VPS risolve il problema per pochi dollari al mese. La scelta dipende da come il bot riceve gli aggiornamenti: li chiede a Telegram oppure Telegram li invia al bot.

Questo determina porte, certificato e necessità di una connessione IPv4 pubblica.

La versione breve

• Per un bot su VPS usa il long polling: non richiede dominio, certificato o porta aperta.
• I webhook richiedono HTTPS sulla porta 443, 80, 88 o 8443 e un IPv4 pubblico. Telegram non consegna webhook via IPv6.
• 512 MB of RAM is a workable start for one bot with no local database.
• Mantieni attivo il bot con systemd o con la politica di riavvio Docker se usi già container.
• Scegli considerando IPv4 e RAM disponibile, non solo il prezzo di listino.

Polling o webhook: la scelta che determina i requisiti del server

Un bot riceve aggiornamenti in due modi. Con long polling chiama getUpdates; Telegram tiene aperta la richiesta fino a un aggiornamento o al timeout, quindi ogni connessione parte dal server. Con un webhook registri una volta un URL con setWebhook e Telegram invia ogni aggiornamento tramite POST HTTPS.

La colonna webhook segue i requisiti webhook di Telegram.

Per conoscere il metodo del bot, interroga la Bot API:

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

Se la risposta contiene "url":"", non è configurato un webhook e puoi usare long polling. bot.start() di grammY usa long polling per impostazione predefinita; python-telegram-bot usa run_polling() o run_webhook().

Per un bot sul proprio VPS sceglierei polling, come consiglia normalmente grammY. I webhook convengono quando è già attivo un reverse proxy (un server web che inoltra le richieste HTTPS al bot), più bot condividono lo stesso endpoint HTTPS o si usa una piattaforma serverless. In questo caso Caddy ottiene e rinnova il certificato senza un’attività cron.

Un’interruzione breve ritarda i messaggi senza perderli. Secondo le regole degli aggiornamenti della Bot API, Telegram conserva gli aggiornamenti fino a 24 ore, finché il bot non li riceve, con entrambi i metodi, e ritenta le richieste webhook fallite prima di rinunciare.

Se il webhook occupa direttamente la porta, limita l’accesso agli intervalli sorgente pubblicati da Telegram. Se un reverse proxy condivide la 443 con altri siti, limita solo il percorso webhook o usa il token segreto senza bloccare tutto l’altro traffico HTTPS. La guida webhook elenca due intervalli sorgente e avverte che possono cambiare. Con UFW come firewall dell’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

Cambia 443 se il webhook ascolta su 80, 88 o 8443. Queste regole proteggono un bot eseguito direttamente sull’host. La documentazione firewall Docker spiega che una porta pubblicata aggira UFW, quindi il container webhook avviato con -p 443:443 resta accessibile a tutti. Imposta anche secret_token in setWebhook. Telegram lo restituisce nell’header X-Telegram-Bot-Api-Secret-Token di ogni richiesta; il gestore rifiuta quelle prive del token.

Mantenere attivo il bot: systemd o Docker

Eseguire un bot 24/7 significa riavviarlo dopo crash e riavvii. Sul VPS se ne occupa systemd, oppure Docker se distribuisci un’immagine.

Un’unità systemd è un breve file di configurazione che indica al sistema di inizializzazione come avviare e riavviare un programma. Crea /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

Metti il token nel file .env del progetto come BOT_TOKEN=... e leggilo con os.environ["BOT_TOKEN"] (Node: process.env.BOT_TOKEN), tenendolo fuori dal codice. Copia quindi il progetto nella posizione prevista e avvialo:

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 riavvia dopo uscite normali o crash; on-failure esclude le uscite normali, secondo il manuale systemd.service. RestartSec=5 distanzia i tentativi; WantedBy=multi-user.target con enable avvia al boot. In caso di riavvii continui, sudo journalctl -u telegram-bot -n 50 mostra la traccia dell’errore. Controlla prima se manca BOT_TOKEN.

L’equivalente Docker è un’opzione:

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

docker logs -f telegram-bot

In Compose usa restart: unless-stopped. La documentazione delle politiche di riavvio Docker dice che il container riparte quando termina o il daemon si riavvia, non dopo uno stop manuale. Copre i riavvii se Docker parte al boot, come avviene per impostazione predefinita su Debian e Ubuntu. Altrove esegui sudo systemctl enable docker.service.

La mia regola: uno script su una macchina piccola usa systemd, senza altri daemon in RAM. Se crei già immagini o usi altri container, scegli Docker considerando la RAM del daemon.

Nessuno dei due segnala che il bot è fermo. Può farlo un monitor push Uptime Kuma su un secondo server. Il bot chiama periodicamente il suo URL; Uptime Kuma avvisa su Telegram quando le chiamate cessano.

I limiti dell’hosting gratuito e dei server domestici

Render sospende un servizio web gratuito dopo 15 minuti senza traffico entrante e la documentazione del piano gratuito indica circa un minuto per riattivarlo. Un bot polling non riceve traffico entrante e viene fermato. Un bot webhook si risveglia con il POST di Telegram, con avvio a freddo dopo le pause. L’utilità dell’hosting gratuito dipende quindi dal metodo.

La guida grammY indica le piattaforme serverless come adatte ai webhook; il long polling richiede una macchina sempre accesa. Fly.io fattura a consumo e richiede una carta registrata.

Un Raspberry Pi o un vecchio PC può eseguire polling finché macchina, corrente e connessione funzionano. Per webhook domestici servono anche indirizzo pubblico e port forwarding. Per un bot amatoriale entrambe le soluzioni gratuite possono bastare.

Un VPS supporta entrambi i metodi a prezzo mensile fisso.

Cinque provider VPS a confronto per un bot Telegram

La tabella confronta cinque piani base a pagamento per bot Telegram ai prezzi mensili pubblicizzati, aggiornati a ottobre 2026, prima delle imposte. Le promozioni sono indicate dove applicabili.

Il piano solo IPv6 di Vultr non ha IPv4; il prezzo Hetzner esclude l’indirizzo IPv4. Senza, nessuno dei due riceve webhook.

Un bot in polling può funzionare anche con il solo IPv6 perché api.telegram.org ha un indirizzo IPv6. Devono averlo anche tutti gli altri servizi a cui accede: registri di pacchetti, il tuo host Git e ogni API che chiama. Controlla ogni host prima della scelta:

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

Una risposta vuota significa che l’host non ha un indirizzo IPv6.

512 MB bastano per un bot Telegram?

Partirei da 512 MB per un bot senza database locale. python-telegram-bot non indica requisiti di memoria. Conta chi condivide la macchina: sistema operativo, eventuale daemon Docker e database locale. Misura l’uso.

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

Un arresto per esaurimento della memoria (OOM) avviene quando il kernel termina un processo per liberare RAM. systemd riavvia il bot: quella riga di log può essere l’unica prova. Passa a 1 GB se compaiono arresti OOM, se lo swap è usato costantemente o prima di aggiungere un database locale o un secondo bot.

Quale scegliere

Per un bot sceglierei 512 MB con IPv4 pubblico incluso. Poi contano prezzo, margine e posizione degli utenti.

• Prezzo mensile attuale più basso: Cloudzy a 2,48 $ durante la promozione del 50%, IPv4 e IPv6 inclusi.
• Prezzo attuale più basso con IPv4: Cloudzy a 2,48 $ in promozione, IPv4 dedicato e IPv6 inclusi.
• 1 GB of headroom for Docker or a small database: Linode, from $5 a month.
• Più bot o un database, utenti in Europa: Hetzner offre il maggior numero di risorse per euro in questa tabella quando il piano è disponibile (a ottobre 2026 risultava non disponibile). Aggiungi il costo dell’IPv4 per i webhook.
• Più disco e trasferimento con 512 MB: Cloudzy. Tra questi piani offre più spazio (20 GB NVMe contro 10) e trasferimento (1 TB contro circa 500 GB), IPv4 e IPv6 inclusi. Il prezzo promozionale attuale è anche inferiore agli altri piani base confrontati.

Al prezzo promozionale attuale Cloudzy combina il costo mensile più basso di questo confronto con più spazio e trasferimento degli altri piani da 512 MB. Il piano da 512 MB di Cloudzy è fatturato a ore con una garanzia di rimborso di 14 giorni, così puoi eseguire il bot per qualche giorno prima di impegnarti. Scegli la zona più vicina agli utenti, distribuisci un VPS Linux Cloudzy e aggiungi l’unità systemd precedente.

Domande frequenti