Far girare un bot Telegram 24/7 su un VPS: aiogram, systemd, polling vs webhook

Hai scritto un bot Telegram con aiogram, l'hai testato localmente, e funziona. Ora deve vivere da qualche parte che non dorme quando chiudi il laptop. Un piccolo VPS è la casa naturale — ma c'è un divario tra python bot.py in una sessione SSH e un bot che resta effettivamente attivo attraverso crash, riavvii e la caduta della tua connessione.

Questa è la versione di produzione: un virtualenv, il token tenuto fuori dal tuo codice, un servizio systemd che resuscita il bot da solo, e una risposta lucida alla domanda che tutti alla fine fanno — polling o webhook?

Perché non eseguirlo semplicemente sul laptop

Un bot ha bisogno di una connessione stabile in uscita a Telegram. Il tuo laptop va in sospensione, si riavvia per gli aggiornamenti e salta tra reti — ognuna di queste fa cadere il bot, e gli utenti sbattono contro un muro di silenzio. Un VPS mantiene quella connessione 24 ore su 24. È tutto il motivo per spostarlo dalla tua macchina, ed è lo stesso motivo per cui anche un bot Discord appartiene a un server.

Se vuoi solo il percorso più veloce per "metterlo online" con un bot minimale, la guida per ospitare un bot Telegram copre quello. Questo pezzo va un livello più a fondo: aiogram, gestione sicura del token e sapere quando scalare.

Il bot, in un virtualenv

Fai SSH e tieni il bot isolato nel proprio venv — non installare pacchetti a livello di sistema, rende un pasticcio aggiornamenti e pulizia più tardi:

sudo apt update && sudo apt install -y python3-venv
mkdir ~/tgbot && cd ~/tgbot
python3 -m venv venv && source venv/bin/activate
pip install -U aiogram

Un bot aiogram 3 minimale che legge il suo token dall'ambiente, non da una stringa scritta a mano:

# bot.py
import asyncio, logging, os
from aiogram import Bot, Dispatcher
from aiogram.types import Message
from aiogram.filters import CommandStart

logging.basicConfig(level=logging.INFO)
dp = Dispatcher()

@dp.message(CommandStart())
async def start(m: Message):
    await m.answer("Alive and running on a VPS.")

async def main():
    bot = Bot(os.environ["BOT_TOKEN"])
    await dp.start_polling(bot)

if __name__ == "__main__":
    asyncio.run(main())

Tieni il token fuori dal tuo codice

Non incollare mai il token di BotFather in bot.py — un push su un repo pubblico e è trapelato. Mettilo invece in un file env leggibile da root:

sudo tee /etc/tgbot.env >/dev/null <<'EOF'
BOT_TOKEN=123456:your-token-from-botfather
EOF
sudo chmod 600 /etc/tgbot.env

Un token trapelato è a un /revoke in BotFather dall'essere sistemato — ma qualsiasi altra cosa trapelata su una macchina condivisa è peggio. Un VPS dedicato per il bot è onestamente una casa più sicura per il token del tuo laptop quotidiano: se trapela, ruoti un token, non tutto il tuo setup.

La parte che lo tiene vivo: systemd

È questo che separa un bot che gira da un bot che resta in funzione. Crea il servizio:

# /etc/systemd/system/tgbot.service
[Unit]
Description=Telegram bot (aiogram)
After=network-online.target
Wants=network-online.target

[Service]
User=botuser
WorkingDirectory=/home/botuser/tgbot
EnvironmentFile=/etc/tgbot.env
ExecStart=/home/botuser/tgbot/venv/bin/python bot.py
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

Eseguilo come utente non-root (botuser sopra), non root — se il bot viene mai compromesso, lo vuoi confinato. Poi:

sudo systemctl daemon-reload
sudo systemctl enable --now tgbot

Restart=always con RestartSec=3 significa che un crash — un brutto aggiornamento da Telegram, un'eccezione non gestita, un OOM — riporta il bot in tre secondi invece di lasciarlo morto finché non te ne accorgi. Guardalo in tempo reale:

journalctl -u tgbot -f

Ecco tutta la tua configurazione di logging. Nessun file di log da ruotare, nessuno strumento extra — journald ce l'ha già.

Aggiornare senza drammi di downtime

Quando cambi il codice o aggiorni aiogram:

cd ~/tgbot && source venv/bin/activate
pip install -U aiogram          # se aggiorni la libreria
sudo systemctl restart tgbot
journalctl -u tgbot -n 30 --no-pager   # conferma che è tornato pulito

Il riavvio fa saltare il bot per un secondo o due. Per un bot in polling è invisibile agli utenti — Telegram mette in coda gli aggiornamenti e li consegna una volta che il bot si riconnette.

Polling vs webhook — la versione onesta

È la decisione su cui la gente pensa troppo. Ecco la versione semplice:

Polling (start_polling, ciò che usa il codice sopra) fa chiedere al bot a Telegram "c'è qualcosa di nuovo?" su una connessione a lunga durata. Non ha bisogno di nulla se non internet in uscita — nessun dominio, nessun TLS, nessuna porta in entrata aperta. Gira bene dietro NAT. Per la stragrande maggioranza dei bot, è corretto e dovresti fermarti qui.

Webhook fa spingere gli aggiornamenti da Telegram verso di te, il che significa che devi esporre un endpoint HTTPS pubblico. Questo richiede un dominio e una porta in entrata raggiungibile — quindi o un IP pubblico dedicato o un reverse proxy davanti. Più setup, più cose che si rompono. Il vantaggio è latenza più bassa e meno overhead su grande scala — migliaia di utenti concorrenti, volume di aggiornamenti pesante.

La regola pratica: inizia con il polling su un piano NAT. Passa a un webhook solo quando hai effettivamente superato il polling — e se lo fai, è allora che un IP dedicato si guadagna il posto, perché ti serve quell'endpoint HTTPS in entrata.

Quanto costa farlo girare

Un bot in polling è leggero. Sta inattivo sul long-poll di Telegram e reagisce ai messaggi, quindi la macchina per lo più aspetta:

• Nano da $3 (1 vCPU / 1 GB) — adatto alla maggior parte dei bot, anche quelli abbastanza loquaci.
• Micro da $5 (2 vCPU / 2 GB) — quando il bot tiene un database (SQLite/Postgres), gestisce media o serve molti utenti.
• Più alto solo se il bot stesso fa lavoro vero — elaborazione immagini, un modello locale, logica pesante per messaggio.

La registrazione è solo con email e paghi in USDC o USDT su Base o Ethereum — niente carta, niente ID. Anche una carta funziona, ma l'on-ramp ha un minimo di ~$27, quindi per un piano da $3 è più fluido ricaricare un piccolo saldo una volta e lasciare che i rinnovi attingano da lì. È solo CPU, un datacenter in Germania — un non-problema per un bot, utile sapere se ti serviva una GPU o una regione specifica.

La conclusione onesta

Un bot Telegram è una delle cose più economiche che puoi fare self-hosting: una macchina da $3, una unit systemd, e il polling ti dà un bot che è online attraverso crash e riavvii senza che tu lo sorvegli. Ricorri a un webhook e a un piano più grande solo quando la scala lo impone davvero — non perché un tutorial ti ha detto che i webhook sono "migliori". Prendi la piccola macchina, tieni il token in un file env, lascia che systemd gestisca l'uptime, e — prima di tutto — esegui la checklist di sicurezza per un nuovo VPS così la macchina stessa è blindata.

Pronto a ospitare il tuo? Un bot Telegram usa a malapena risorse — il piano Nano ($3/mese) lo fa girare 24/7 senza problemi.