Telegram Serverless elimina i server: come cambia lo sviluppo dei bot

Telegram prova a eliminare uno degli ostacoli più comuni nello sviluppo dei bot: la necessità di predisporre un server, configurare un webhook, proteggere le credenziali, gestire il database e mantenere il servizio sempre raggiungibile. Con Telegram Serverless, il codice di backend può girare direttamente sull’infrastruttura della piattaforma, accanto alla Bot API e a un archivio dati persistente. L’idea ricorda le funzioni serverless offerte dai grandi cloud provider, ma con un ambiente molto più ristretto e costruito apposta per bot e Mini App.

La novità arriva mentre la piattaforma per sviluppatori continua a crescere. La Bot API, introdotta nel 2015, ha trasformato Telegram in un’interfaccia programmabile per assistenti, servizi di notifica, giochi, pagamenti e automazioni. A luglio 2026, Telegram ha pubblicato la Bot API 10.2, dopo aver introdotto con la versione 10.1 anche messaggi strutturati e funzioni adatte allo streaming di risposte generate da sistemi di intelligenza artificiale. Serverless completa il quadro: non aggiunge soltanto nuovi metodi, ma offre anche un luogo in cui sviluppare e gestire la logica applicativa.

Uno sviluppatore può creare un bot, attivare Serverless da BotFather, scrivere alcuni moduli JavaScript e distribuirli con un comando. Telegram si occupa dell’esecuzione, dell’instradamento degli aggiornamenti, del webhook e della persistenza dei dati. Non serve affittare una VPS, mantenere un container acceso o collegare manualmente una funzione cloud alla Bot API.

Come funziona Telegram Serverless

Il modello ruota attorno a piccoli moduli JavaScript caricati sulla piattaforma. Ogni esecuzione avviene in un V8 isolate, cioè un ambiente separato basato sul motore JavaScript di cui si servono anche da Chromium e Node.js.

Un isolate dispone del proprio heap e del proprio stato di esecuzione: la separazione riduce l’interferenza tra processi diversi e consente alla piattaforma di avviare rapidamente nuove istanze quando arrivano gli aggiornamenti.

Non si tratta però di un normale ambiente Node.js. Il runtime non espone il file system, non consente l’installazione di pacchetti npm e non permette di importare moduli arbitrari. Il codice vede soltanto il pacchetto SDK fornito da Telegram e i file appartenenti al progetto. Questo tipo di assetto rende l’avvio più rapido e semplifica l’isolamento, ma obbliga lo sviluppatore a rinunciare a molte librerie usate abitualmente nei backend JavaScript.

Il webhook non sparisce: lo gestisce Telegram

I bot tradizionali ricevono gli aggiornamenti in due modi: tramite long polling con getUpdates oppure attraverso un webhook HTTPS.

Nel secondo caso Telegram invia una richiesta POST a un URL pubblico controllato dallo sviluppatore. Bisogna quindi configurare un dominio, un certificato TLS, un endpoint raggiungibile e una procedura capace di rispondere correttamente anche sotto carico.

Con Serverless, il webhook resta alla base della consegna, ma la sua gestione passa attraverso la piattaforma. Telegram configura l’indirizzo, sincronizza allowed_updates con i moduli effettivamente distribuiti e mostra eventuali errori. Aggiungendo o rimuovendo un handler, il sistema aggiorna anche l’elenco degli eventi che il bot vuole ricevere.

Creazione e distribuzione di un progetto

Il requisito dichiarato è Node.js 18 o una versione successiva, necessario per eseguire gli strumenti locali.

Come spiegato in questa guida introduttiva, il progetto iniziale si crea con npm create @tgcloud/bot, che prepara la struttura delle directory, installa la CLI (command-line interface) e aggiunge alcuni file di riferimento. Fra questi compaiono anche AGENTS.md e docs/tgcloud-sdk.md, pensati anche per strumenti di programmazione assistita.

Ogni progetto si collega a un solo bot attraverso un token dedicato alla CLI che non è il token della Bot API.

La separazione delle credenziali limita i danni derivanti da un errore banale, ad esempio la pubblicazione accidentale del repository. Va detto però che l’uso di .gitignore non rappresenta una protezione assoluta: copie di backup, log della shell e configurazioni CI possono comunque esporre il segreto.

Un database SQLite integrato per ogni bot

Ogni progetto dispone di un database persistente basato su SQLite. Il codice dichiara tabelle e colonne in schema.js, mentre le query passano attraverso un builder asincrono. Sono disponibili tipi come INTEGER, TEXT, REAL, NUMERIC e BLOB, oltre a conversioni automatiche per valori booleani, JSON, timestamp e array di byte.

Per un bot che salva preferenze, liste, punteggi, sessioni o impostazioni per chat, la soluzione appare più che sufficiente.

Un contatore, ad esempio, può usare un’operazione INSERT con onConflictDoUpdate per creare la riga al primo messaggio e incrementarla nelle richieste successive. La clausola returning consente di recuperare il valore aggiornato nello stesso statement, evitando una seconda query.

Le query sono sempre asincrone e richiedono await. Il builder supporta filtri, ordinamenti, raggruppamenti, limiti, offset, insert multipli, update e delete. Gli inserimenti in blocco rimangono però soggetti al limite delle variabili di SQLite: il numero di righe moltiplicato per il numero di colonne non può superare la soglia ammessa dal motore. Per importazioni consistenti occorre quindi suddividere i dati in gruppi più piccoli.

C’è poi una scelta tecnica che merita attenzione: le chiavi esterne non sono supportate. Le consegueze sono rilevanti. Se una tabella ordini contiene user_id, il database non garantisce che l’utente esista davvero, non esegue cancellazioni a cascata e non impedisce la creazione di record orfani. L’integrità referenziale ricade sul codice: prima si inserisce il record principale, poi quello dipendente; in fase di cancellazione si eliminano i figli prima del padre. Per progetti piccoli e ben controllati può funzionare, ma applicazioni con molte relazioni richiedono disciplina e controlli periodici.

Test del codice senza pubblicarlo

Il comando tgcloud run esegue un handler sulla piattaforma usando i file locali, senza renderli attivi per il traffico reale. Lo sviluppatore passa un payload in formato JSON5: l’esecuzione restituisce il valore prodotto dalla funzione, i messaggi di console e il tempo impiegato.

Non abbiamo a che fare con un emulatore locale: il codice gira davvero nell’ambiente remoto. In pratica, il test riflette con maggiore fedeltà le regole del runtime, ma richiede connettività e può interagire con risorse reali: ad esempio, se l’handler scrivesse nel database o chiamasse un’API esterna, il test potrebbe generare effetti persistenti. Conviene usare identificatori dedicati, dati fittizi e funzioni idempotenti.

Telegram permette di gestire il progetto Serverless anche da BotFather. Dal telefono si possono creare handler, modificare moduli condivisi, intervenire sullo schema del database, avviare test e applicare cambiamenti. Il progetto rimane lo stesso usato dalla CLI: quanto scritto da smartphone può essere recuperato sul computer con il comando tgcloud pull.

La funzione è comoda per correzioni urgenti, prototipi e bot molto semplici. Non sostituisce però un editor con controllo di versione, revisione del codice, test automatici e analisi statica.

Per quali progetti ha senso usare Telegram Serverless

Telegram Serverless appare adatto a bot conversazionali, liste personali, quiz, classifiche, notifiche, semplici integrazioni HTTP e backend per Mini App con una quantità moderata di dati da gestire. È uno strumento che riduce drasticamente il tempo necessario per passare da un’idea a un prototipo funzionante e può evitare i costi fissi di una macchina sempre accesa.

Non è invece una sostituzione universale per un backend completo. L’assenza di pacchetti npm, file system, chiavi esterne e trasferimenti binari limita le applicazioni più articolate. Restano da valutare anche aspetti essenziali come quote di esecuzione, memoria disponibile, durata massima degli handler, politiche di backup, localizzazione dei dati, osservabilità e costi oltre le eventuali soglie gratuite.

Telegram sembra puntare soprattutto a rimuovere il lavoro ripetitivo che accompagna bot piccoli e medi. Per rispondere a /start, salvare una preferenza o interrogare un servizio esterno, configurare un’intera infrastruttura è spesso cosa sproporzionata.

Portare codice e dati direttamente dentro Telegram riduce latenza e complessità: allo stesso tempo, tuttavia, aumenta la dipendenza dal fornitore. I moduli usano import non standard, un SDK proprietario, un modello di database senza foreign key e comandi di distribuzione specifici.

C’è anche una questione di fiducia. Con un server autonomo lo sviluppatore controlla sistema operativo, backup, rete, log e politiche di aggiornamento; con Serverless delega quasi tutto a Telegram. Per un bot pubblico che non gestisce informazioni “delicate” può essere un compromesso eccellente; per servizi che trattano dati riservati, regolamentati o processi aziendali critici, la valutazione deve includere temi come privacy, disponibilità, portabilità e procedure di recupero.