Telegram Serverless: backend de bots sin servidor que mantener

Lo esencial

Telegram Serverless ejecuta módulos JavaScript en V8 isolates junto a la Bot API, sin servidores que rentar ni mantener.
El CLI se llama tgcloud: npx tgcloud push despliega el código y npx tgcloud migrate aplica cambios de esquema.
Cada proyecto trae tres carpetas fijas: handlers/ para los updates, lib/ para código compartido y schema.js para las tablas.
La base de datos usa SQLite con un DSL de tablas (table(), integer()) accesible desde sdk/db sin configurar credenciales.
Los handlers se activan por tipo de update: message.js, callback_query.js, etc. Sin match, Telegram ignora el update.
Se activa desde @BotFather: abrí tu bot, entrá a Serverless y actívalo para desbloquear el CLI y la base de datos.
El SDK expone api (Bot API), db (SQLite) y HTTP saliente a cualquier módulo, sin instalar dependencias extra.

Telegram lanzó una forma de correr el backend de un bot sin alquilar un solo servidor: se llama Telegram Serverless y ejecuta código JavaScript directo en la infraestructura de Telegram.

Qué es Telegram Serverless

Un bot tradicional necesita un proceso corriendo todo el tiempo: una VPS, una función en la nube o un panel de hosting que responda a cada mensaje. Serverless elimina esa capa entera.

Cada invocación corre en un V8 isolate liviano, cerca de los propios sistemas de Telegram. Eso acerca las llamadas a la Bot API y a la base de datos, sin la latencia de un servidor externo.

La plataforma incluye la Bot API, una base de datos con SQLite y HTTP saliente listos para usar en cualquier módulo. No hay credenciales que configurar ni paquetes que instalar para tener eso funcionando.

El modelo mental: carpeta local, nube y tgcloud

El flujo de trabajo se apoya en tres lugares que se corresponden entre sí. La carpeta del proyecto en la máquina del desarrollador guarda los módulos JavaScript: esquema, código compartido y handlers de updates.

La nube guarda la copia desplegada de esos módulos, además de la base de datos del bot. El puente entre ambos lados es el CLI tgcloud, que muestra las diferencias entre lo local y lo desplegado y sincroniza los cambios.

No hace falta conectarse por SSH a nada. Se edita el archivo local, se corre npx tgcloud push y la plataforma se encarga del resto.

Cómo funciona un handler

Cuando llega un update (un mensaje, un botón presionado, una consulta en línea), Telegram lo enruta al handler que corresponde: handlers/message.js, handlers/callback_query.js y así según el tipo de evento.

Cada handler exporta por defecto una función que recibe el update, habla con la Bot API y con la base de datos a través del SDK, y termina ahí. Si no existe un handler para un tipo de update, Telegram simplemente lo ignora.

Ejemplo práctico: un bot que cuenta mensajes

El esquema define una tabla con SQLite usando el DSL del SDK, sin escribir una sola línea de SQL a mano:

import { table, integer } from 'sdk/db';

export const mensajesPorChat = table('mensajes_por_chat', {
  chatId: integer('chat_id').primaryKey(),
  total: integer('total').notNull().default(0),
});

El handler inserta el contador o lo incrementa si ya existe, y devuelve la fila actualizada en la misma sentencia:

import { api, db } from 'sdk';
import { mensajesPorChat } from 'schema';
import { sql } from 'sdk/db';

export default async function (message) {
  const chatId = message.chat.id;

  const [fila] = await db.insert(mensajesPorChat)
    .values({ chatId, total: 1 })
    .onConflictDoUpdate({
      target: mensajesPorChat.chatId,
      set: { total: sql`${mensajesPorChat.total} + 1` },
    })
    .returning()
    .run();

  await api.sendMessage({
    chat_id: chatId,
    text: `Llevo ${fila.total} mensaje(s) tuyos registrados.`,
  });
}

Con eso desplegado (más abajo se ve cómo) el bot ya responde y recuerda cuántos mensajes recibió de cada chat, sin un servidor propio corriendo en ningún lado.

El SDK: api, db y HTTP saliente

El módulo sdk expone api para llamar a la Bot API y db para leer y escribir en SQLite. Además, cada módulo puede hacer peticiones HTTP salientes con fetch normal, sin agregar dependencias.

Un handler que consulta una API externa antes de responder se ve así:

import { api } from 'sdk';

export default async function (message) {
  const respuesta = await fetch('https://api.exchangerate.host/latest?base=USD&symbols=EUR');
  const datos = await respuesta.json();

  await api.sendMessage({
    chat_id: message.chat.id,
    text: `1 USD = ${datos.rates.EUR} EUR`,
  });
}

Esa combinación (Bot API, base de datos y HTTP saliente en el mismo runtime) es lo que permite construir bots conversacionales con estado, backends de Mini Apps, juegos con tablas de posiciones o integraciones que empujan resultados a un chat.

Instalación y primeros pasos

Antes de nada, hay que activar Serverless desde @BotFather: se abre el bot, se entra a la opción Serverless y se activa. Eso desbloquea el token de acceso del CLI, los handlers, las librerías y la base de datos.

Con Node.js 18 o superior instalado, el comando de creación de proyecto es el mismo en Windows, macOS y Linux, porque corre sobre npm:

# Windows (PowerShell), macOS y Linux (Terminal)
npm create @tgcloud/bot mi_bot_tech
cd mi_bot_tech
npx tgcloud push
npx tgcloud migrate

El argumento del comando de creación es la carpeta destino: se puede pasar . para usar la carpeta actual, o cualquier ruta. Funciona también sobre una carpeta existente y nunca sobrescribe archivos ya creados.

Cuándo no conviene usar Serverless

El código corre dentro de un isolate de V8 con el SDK de Telegram como única puerta de entrada, no en un entorno Node.js completo con acceso libre al sistema de archivos o a paquetes nativos arbitrarios.

Eso significa que sirve para lógica de bots y Mini Apps, no como backend general para una aplicación que necesite correr fuera del ecosistema de Telegram. Si el proyecto ya depende de otra infraestructura (colas, workers, un framework web propio), migrar toda esa lógica al sandbox de Serverless implica reescribirla con el SDK y el DSL de base de datos que ofrece la plataforma.

Conclusión

Telegram Serverless resuelve el problema más repetitivo de armar un bot: tener algo corriendo veinticuatro horas solo para escuchar /start. A cambio, el código queda atado al sandbox y al SDK de Telegram, un compromiso razonable para bots y Mini Apps que antes vivían en una VPS barata sin mucho más propósito que estar encendida.

📖 Versión extendida con más detalle: https://elsolitario.org/2026/07/15/telegram-serverless-bots-sin-servidor/?utm_source=telegraph&utm_medium=instant_view&utm_campaign=programacion