Telegram Serverless: bot senza server, come funziona

Creare un bot Telegram non richiede più un server. Con Telegram Serverless il codice del bot gira direttamente sull’infrastruttura di Telegram, dentro una sandbox V8 isolata affiancata alle Bot API e a un database SQLite integrato. Niente VPS da noleggiare, niente container da tenere accesi, nessuna scalabilità da gestire: scrivi moduli JavaScript e li pubblichi con un singolo comando. La nuova funzione punta dritta a chi sviluppa con assistenti AI e ridefinisce il flusso di lavoro dei bot. Vediamo che cos’è, come funziona davvero e quali compromessi comporta.

Che cos’è Telegram Serverless

Telegram Serverless è un runtime che esegue il codice di back-end di bot e Mini App direttamente sull’infrastruttura di Telegram, senza bisogno di provisioning di server. Il codice viene eseguito on demand in un isolato V8 leggero, vicino ai sistemi di Telegram, così le chiamate alle Bot API e al database sono rapide.

La filosofia è «batterie incluse»: ogni modulo ha accesso immediato a tre cose — le Bot API di Telegram, un database SQLite persistente e le richieste HTTP in uscita — senza installare pacchetti né configurare credenziali. Un bot, in fondo, è un programma che reagisce agli aggiornamenti: Serverless elimina l’unico strato che prima dovevi tenere sempre acceso, raggiungibile e sicuro.

Come funziona: moduli, handler e database

Un progetto vive in una cartella sotto controllo di versione e contiene solo tre tipi di codice. La cartella handlers/ ospita un file per ogni tipo di update Telegram (message.js, callback_query.js e così via); lib/ raccoglie il codice condiviso; schema.js descrive le tabelle del database.

Quando arriva un aggiornamento, Telegram lo instrada all’handler corrispondente e ne invoca l’export di default. Se non esiste un handler per quel tipo di update, viene semplicemente ignorato: aggiungi solo ciò che ti serve. Il database è SQLite e si interroga con un query builder in stile Drizzle ORM, con una precisazione importante: le foreign key sono disattivate, quindi l’integrità dei dati va gestita nel codice.

Un dettaglio di sicurezza progettuale: pubblicare il codice e modificare il database sono passi deliberatamente separati. Il comando push carica i moduli in modo atomico ma non tocca mai i dati; le modifiche allo schema si applicano solo con migrate, che classifica ogni cambiamento come sicuro, a rischio o manuale e ti chiede conferma prima di agire.

Come cambia lo sviluppo dei bot

Il cambiamento più concreto è la sparizione del DevOps. Prima, un bot di produzione andava cucito a mano: qualcuno doveva ospitare il codice sempre attivo, intercettare gli update via webhook, custodire le credenziali e far sopravvivere lo storage a un riavvio. Molti risolvevano su cloud serverless generici come AWS Lambda, Cloudflare Workers o Deno Deploy.

Con questo modello quel livello scompare: ricevi un evento, esegui la logica, interroghi i dati e rispondi, tutto dentro Telegram. C’è poi un’apertura netta verso l’AI. Ogni progetto è generato con un file AGENTS.md e una guida docs/tgcloud-sdk.md che i coding agent leggono in automatico: puoi aprire il progetto con assistenti di coding come Claude Code, descrivere il bot a parole e lasciare che scriva schema e handler.

Questa impostazione avvicina Serverless al mondo degli agenti AI open source: un runtime piccolo e autoconsistente, con un solo SDK e nessun pacchetto npm da gestire, è proprio ciò che rende prevedibile il lavoro di un assistente automatico.

Lock-in e limiti attuali

Il rovescio della medaglia è il controllo. Secondo diversi osservatori del settore, concentrare esecuzione, dati e API sotto un unico operatore accorcia la strada verso la produzione ma introduce un rischio di lock-in: portabilità, modello di sicurezza e condizioni a lungo termine restano in gran parte da verificare.

Ci sono anche limiti tecnici dichiarati. Dalla documentazione: le risposte HTTP sono solo testuali e con un tetto di 32 MB; inoltre non è ancora possibile scaricare i byte di un file o caricarne uno nuovo da un handler — si lavora riusando i file_id già presenti sui server di Telegram. Sono vincoli aggirabili, ma vanno messi in conto in fase di progettazione.

Come iniziare in pratica

Servono Node.js 18 o superiore e un bot registrato con @BotFather, dove va attivata la voce «Serverless». La documentazione ufficiale di Telegram descrive ogni passaggio; il flusso essenziale è lineare:

1. Crei il progetto con npm create @tgcloud/bot nome_bot.
2. Colleghi il bot con npx tgcloud login usando il token di accesso CLI.
3. Pubblichi i moduli con npx tgcloud push e applichi lo schema con npx tgcloud migrate.
4. Provi la logica senza deploy con npx tgcloud run, passando un payload di test.

Chi è a corto di computer può gestire l’intero progetto — handler, libreria e database — direttamente da BotFather sul telefono: è lo stesso progetto cloud, sincronizzabile poi sul laptop.

Domande frequenti

Cos’è Telegram Serverless?

È un runtime che esegue il codice di back-end di bot e Mini App Telegram direttamente sull’infrastruttura di Telegram, senza server da noleggiare o gestire. Include Bot API, un database SQLite e le richieste HTTP in uscita, e si pubblica con un singolo comando della CLI tgcloud.

Serve saper programmare per usarlo?

Aiuta conoscere JavaScript, ma non è indispensabile. Ogni progetto è predisposto per gli assistenti AI tramite un file AGENTS.md: puoi descrivere il bot a parole a un coding agent, che scrive schema e handler al posto tuo. Tu revisioni, testi e pubblichi.

Che database usa Telegram Serverless?

Usa un database SQLite persistente, uno per ogni bot, interrogabile con un query builder in stile Drizzle ORM. Le foreign key sono però disattivate: le relazioni tra tabelle vanno modellate con colonne semplici e l’integrità gestita nel codice dell’applicazione.

Quali sono i limiti di Telegram Serverless?

Oltre al rischio di lock-in, ci sono vincoli tecnici: le risposte HTTP sono solo testuali e limitate a 32 MB, e per ora non si possono scaricare o caricare i byte di un file da un handler. Si aggira riusando i file_id già presenti sui server Telegram.

Conclusione

Telegram Serverless abbassa drasticamente la barriera d’ingresso: un bot con stato persistente e zero server diventa questione di minuti. È un’ottima scelta per progetti piccoli, Mini App e prototipi rapidi, a patto di accettare consapevolmente il legame con un unico operatore. Per un bot critico o destinato a crescere, vale la pena valutare prima portabilità e limiti.

Tu su cosa lo useresti: un bot personale, un’automazione o una Mini App? Dimmelo nei commenti.

#tuttelevitediunmaker