Telegram Serverless punta a togliere di mezzo uno dei fastidi più grandi per chi sviluppa bot, ovvero dover mettere in piedi un server, configurare un webhook, custodire le credenziali, gestire un database e tenere tutto raggiungibile ventiquattro ore su ventiquattro. Con questa soluzione il codice di backend gira direttamente sull’infrastruttura della piattaforma, fianco a fianco con la Bot API e con un archivio dati che resta salvato nel tempo. L’idea somiglia alle funzioni serverless dei grandi cloud, ma qui l’ambiente è molto più ristretto e pensato apposta per bot e Mini App.
La novità arriva mentre la piattaforma per sviluppatori continua a espandersi. La Bot API, arrivata nel 2015, ha trasformato Telegram in un’interfaccia programmabile per assistenti, notifiche, giochi, pagamenti e automazioni varie. A luglio 2026 è uscita la Bot API 10.2, dopo che con la versione 10.1 erano già arrivati messaggi strutturati e funzioni pensate per lo streaming delle risposte generate dai sistemi di intelligenza artificiale. Serverless chiude il cerchio, perché non aggiunge solo nuovi metodi ma offre anche un posto dove scrivere e far girare la logica dell’applicazione. Uno sviluppatore può creare un bot, attivare la funzione da BotFather, buttare giù qualche modulo JavaScript e distribuirlo con un solo comando. Telegram pensa all’esecuzione, all’instradamento degli aggiornamenti, al webhook e alla persistenza dei dati. Niente VPS da affittare, nessun container da tenere acceso.
Come funziona Telegram Serverless sotto il cofano
Il modello ruota attorno a piccoli moduli JavaScript caricati sulla piattaforma. Ogni esecuzione avviene dentro un V8 isolate, cioè un ambiente separato basato sullo stesso motore JavaScript usato da Chromium e Node.js. Ogni isolate ha il proprio heap e il proprio stato, e questa separazione riduce le interferenze tra processi diversi, permettendo di avviare in fretta nuove istanze quando arrivano gli aggiornamenti.
Non è però il classico ambiente Node.js. Il runtime non mostra il file system, non consente di installare pacchetti npm e non permette di importare moduli a piacere. Il codice vede solo l’SDK fornito da Telegram e i file del progetto. Questo rende l’avvio più veloce e semplifica l’isolamento, ma costringe a rinunciare a molte librerie che di solito si danno per scontate. Il webhook non sparisce, semplicemente lo gestisce Telegram. Nei bot tradizionali gli aggiornamenti arrivano tramite long polling con getUpdates oppure via webhook HTTPS, con dominio, certificato TLS ed endpoint da configurare a mano. Qui invece la piattaforma imposta l’indirizzo, sincronizza gli update permessi con i moduli distribuiti e segnala eventuali errori. Aggiungendo o togliendo un handler, il sistema aggiorna da solo l’elenco degli eventi che il bot vuole ricevere.
Database SQLite, test e gestione da BotFather
Serve Node.js 18 o una versione più recente per far girare gli strumenti locali. Il progetto iniziale si crea con npm create @tgcloud/bot, che prepara le cartelle, installa la CLI e aggiunge alcuni file di riferimento. Ogni progetto si lega a un solo bot tramite un token dedicato alla CLI, diverso da quello della Bot API. Separare le credenziali limita i danni in caso di errore banale, come la pubblicazione accidentale del repository, anche se il file .gitignore da solo non basta a mettere al sicuro il segreto.
Ogni progetto ha un database SQLite persistente. Le tabelle si dichiarano in schema.js e le query passano da un builder asincrono. Ci sono tipi come INTEGER, TEXT, REAL, NUMERIC e BLOB, oltre a conversioni automatiche per booleani, JSON, timestamp e array di byte. Per un bot che salva preferenze, liste, punteggi o sessioni è più che sufficiente. C’è però un dettaglio che pesa, ovvero le chiavi esterne non sono supportate. Vuol dire niente cancellazioni a cascata, niente garanzie sull’esistenza di un utente collegato, con il rischio di record orfani. L’integrità referenziale ricade tutta sul codice.
Il comando tgcloud run esegue un handler sulla piattaforma usando i file locali, senza renderli attivi per il traffico vero. Non è un emulatore, il codice gira davvero nell’ambiente remoto, quindi il test rispecchia bene le regole del runtime ma può avere effetti persistenti sul database o su API esterne. Meglio usare dati fittizi e funzioni idempotenti. Il progetto si può gestire anche da BotFather, direttamente dal telefono, creando handler, modificando moduli e schema, avviando test. Quanto scritto da smartphone si recupera sul computer con tgcloud pull. Comodo per correzioni al volo e prototipi, ma non sostituisce un editor con controllo di versione e test automatici.
Per quali bot conviene davvero
Telegram Serverless calza a pennello per bot conversazionali, liste personali, quiz, classifiche, notifiche, semplici integrazioni HTTP e backend per Mini App con una quantità moderata di dati. Riduce parecchio il tempo per passare da un’idea a un prototipo funzionante ed evita i costi fissi di una macchina sempre accesa. Non è però un rimpiazzo universale per un backend completo, perché l’assenza di pacchetti npm, file system, chiavi esterne e trasferimenti binari limita le applicazioni più complesse. Restano da valutare quote di esecuzione, memoria, durata massima degli handler, backup, localizzazione dei dati e costi oltre le soglie gratuite.
Portare codice e dati dentro Telegram abbassa latenza e complessità, ma aumenta la dipendenza dal fornitore, tra import non standard, SDK proprietario e comandi di distribuzione specifici. Con un server autonomo lo sviluppatore controlla sistema operativo, backup, rete e log, mentre qui delega quasi tutto. Per un bot pubblico che non tratta informazioni delicate può essere un compromesso ottimo, mentre per servizi che gestiscono dati riservati, regolamentati o processi aziendali critici la valutazione deve mettere in conto privacy, disponibilità, portabilità e procedure di recupero.
