Telegram запустил Serverless: бэкенд для ботов и Mini Apps без серверов и хостинга — VogueTech

Что нового

Telegram запустил Telegram Serverless — встроенный бэкенд для ботов и Mini Apps прямо на инфраструктуре Telegram.

Ключевые новшества:

Бэкенд без серверов и хостинга
- Не нужно арендовать VPS, настраивать Docker, Nginx или панель хостинга.
- Код бота выполняется по запросу в изолированных V8‑окружениях на серверах Telegram.
Чистый JavaScript вместо сложного стека
- Вы пишете обычные JS‑модули без сборки и без node_modules на продакшене.
- Нет server.js, нет Express, нет отдельной точки входа.
SDK и инфраструктура «из коробки»
- В каждом модуле доступны:
  - Telegram Bot API через sdk/api;
  - база данных на SQLite через sdk/db;
  - исходящие HTTP‑запросы через sdk/fetch.
- Никаких ручных токенов для БД, никаких сторонних ORM, никаких доп. сервисов.
Изолированное и быстрое выполнение
- Каждый запрос к боту запускается в лёгком V8‑изоляте.
- Изолят находится рядом с Bot API и встроенной базой данных, поэтому обращения к API и БД минимально задерживаются.
Полноценный рабочий процесс разработчика
- Проект — это обычная папка под git:
  - handlers/ — обработчики Telegram‑обновлений;
  - lib/ — общие модули;
  - schema.js — описание таблиц БД;
  - .tgcloud/ — локальное состояние CLI.
- Деплой одной командой: npx tgcloud push.
- Миграции БД отдельной командой: npx tgcloud migrate.
Встроенная база данных на основе SQLite
- У каждого бота — своя БД.
- Схема описывается в одном schema.js через DSL в стиле Drizzle ORM.
- Все операции с БД — через типизированный query builder из sdk/db.
Локальное тестирование без деплоя
- Команда npx tgcloud run выполняет конкретный обработчик на сервере Telegram, но с вашими локальными файлами.
- Входные данные — JSON5‑объект, результат и console.log возвращаются в терминал.
Управление проектом через @BotFather с телефона
- В разделе Serverless для бота можно:
  - редактировать и запускать обработчики;
  - править schema.js и применять миграции;
  - смотреть вывод console;
  - получать токен CLI.
Поддержка разработки с помощью ИИ‑ассистентов
- В каждом новом проекте есть AGENTS.md и docs/tgcloud-sdk.md.
- Эти файлы дают ИИ‑редакторам (Opencode, Claude Code, Cursor и т.п.) контекст: как устроен проект, как работает SDK, какие есть ограничения.

Цены, лимиты по размеру кода, количеству запросов и строгие бенчмарки Telegram в этом анонсе не раскрывает.

Как это работает

Ментальная модель

У Telegram Serverless три уровня, которые напрямую друг другу соответствуют:

Папка проекта на вашем компьютере
- Здесь живёт весь код:
  - handlers/ — обработчики обновлений;
  - lib/ — общие модули;
  - schema.js — схема БД.
Облако Telegram
- Хранит задеплоенную копию модулей.
- Держит базу данных бота.
CLI tgcloud
- Связывает локальную папку и облако:
  - показывает отличия (status, diff);
  - синхронизирует код и схему (push, pull, migrate, fetch, reset).

SSH, ручные деплои и конфиги серверов не нужны. Вы меняете файлы локально и запускаете:

npx tgcloud push

Платформа получает обновлённые модули и начинает обслуживать трафик бота новым кодом. База данных живёт отдельно и не трогается при деплое.

Структура проекта

Стандартный проект выглядит так:

example_bot/
├─ docs/
│  └─ tgcloud-sdk.md        # справочник по SDK
├─ handlers/
│  └─ message.js            # стартовый обработчик сообщений (эхо)
├─ lib/                     # общие модули (по умолчанию пусто)
├─ AGENTS.md                # подсказки для ИИ-ассистентов
├─ package.json
└─ schema.js                # схема базы данных

Более развёрнутый пример:

example_bot/
├─ handlers/                # входные точки бота, без поддиректорий
│  ├─ message.js
│  └─ callback_query.js
├─ lib/                     # общие модули, поддиректории допустимы
│  ├─ reply.js
│  └─ internal/util.js
├─ schema.js                # схема БД — один файл в корне
└─ .tgcloud/                # состояние CLI (git-ignore)

Деплоятся только:

schema.js;
все .js в handlers/;
все .js в lib/.

Остальные файлы остаются локально. Лишние .js в корне Telegram помечает как подозрительные, чтобы вы не забыли перенести их в lib/ или handlers/.

Модульная система

В рантайме модуль может импортировать только две категории:

SDK платформы
- sdk и подмодули:
  - sdk/api — Bot API;
  - sdk/db — работа с БД;
  - sdk/fetch — HTTP‑запросы наружу.
Собственные модули проекта
- schema — схема БД;
- lib/... — общие модули;
- handlers/... — обработчики.

Импорты всегда по «голому» имени модуля, без относительных путей и без .js:

import { users } from 'schema';
import { addItem } from 'lib/cart';
import { format } from 'lib/internal/fmt';
import { db, api, fetch } from 'sdk';

Так не работает:

import { users } from './schema';    // ошибка
import { users } from '../schema';   // ошибка
import x from 'lib/cart.js';         // ошибка, нужно без .js

Если модуль импортирует что‑то вне этого списка, код не соберётся и не задеплоится.

Обработчики (handlers)

Каждый файл в handlers/ — это точка входа для одного типа Telegram‑обновления.

Пример простого обработчика сообщений:

// handlers/message.js
import { api } from 'sdk';

export default async function (message) {
  await api.sendMessage({
    chat_id: message.chat.id,
    text: `You said: ${message.text ?? '(no text)'}`,
  });
}

Как это работает:

в Telegram приходит Update;
платформа находит подходящий обработчик по имени файла:
- handlers/message.js → update.message;
- handlers/callback_query.js → update.callback_query;
- handlers/inline_query.js → update.inline_query и т.д.;
в обработчик передаётся распакованный payload (например, Message), а не целый Update;
вторым аргументом обработчик может получить контекст ctx с сырым Update в ctx.update.

Если файла handlers/<тип>.js нет или он пустой, обновления этого типа просто игнорируются, код не запускается.

Встроенная база данных

У каждого бота есть собственная SQLite‑БД.

Схема описывается в schema.js через DSL из sdk/db.
Каждая таблица — это table() и экспорт по имени.
Сам schema.js при деплое БД не меняет, он только описывает желаемое состояние.
Физические изменения в БД происходят через npx tgcloud migrate.

Пример объявления таблицы:

// schema.js
import { table, integer, text, sql } from 'sdk/db';

export const messages = table('messages', {
  id: integer('id').primaryKey({ autoIncrement: true }),
  chatId: integer('chat_id').notNull(),
  text: text('text'),
  created: integer('created_at', { mode: 'timestamp' })
    .default(sql`(unixepoch())`),
});

Работа с БД идёт через query builder в стиле Drizzle ORM:

db.insert(...).values(...).run();
db.$count(table, condition);
onConflictDoUpdate;
.returning();
операторы сравнения вроде eq;
сырой SQL через тег sql.

Модель выполнения

Каждый апдейт запускает отдельный V8‑изолят.
Обработчик получает payload, работает с api, db, fetch и завершает выполнение.
Состояние между вызовами хранится только в БД, а не в памяти.
Telegram держит изолят рядом с Bot API и БД, поэтому обращения к ним быстрые и стабильные.

Что это значит для вас

Когда Telegram Serverless реально помогает

Боты с состоянием и логикой, но без DevOps
- Если вы устали держать ради бота отдельный VPS только ради реакции на /start, Serverless снимает этот слой полностью.
- Вы пишете только бизнес‑логику: обработчики, работу с БД, интеграции по HTTP.
Conversational AI‑боты
- Подходит для ассистентов, которые хранят состояние на пользователя:
  - персональные настройки;
  - историю диалогов;
  - прогресс в задачах или обучении.
- БД позволяет хранить контекст, а не полагаться только на внешнюю LLM.
Mini Apps с динамическим бэкендом
- Serverless можно использовать как бэкенд Mini App:
  - хранить данные пользователей;
  - собирать формы;
  - выдавать динамический контент по запросу из Mini App.
Игры и утилиты
- Подходит для:
  - квизов;
  - игр с рейтингами и таблицами лидеров;
  - трекеров привычек;
  - небольших внутренних инструментов.
Интеграции и автоматизации
- Удобно собирать ботов‑интеграторов, которые:
  - ходят в сторонние HTTP‑API;
  - обрабатывают ответы;
  - отправляют результат в чаты.
Команды, где код пишут ИИ‑ассистенты
- Если в команде нет сильного бэкенд‑разработчика, но есть люди, умеющие формулировать задачи ИИ, Serverless снижает порог входа.
- Проект сразу подготовлен для работы с агентами: AGENTS.md и docs/tgcloud-sdk.md дают им чёткие правила.

Когда лучше не использовать

Тяжёлые вычисления и долгие фоновые задачи
- Платформа рассчитана на быстрые реакции на апдейты.
- Если вам нужны длительные фоновые джобы, очереди, видеообработка или ML‑инференс на сервере — придётся выносить их в отдельные сервисы и звать через HTTP.
Сложная микросервисная архитектура
- Здесь нет доступа к файловой системе и нет npm‑зависимостей на рантайме.
- Если ваш проект — набор сервисов с Kafka, Redis, отдельными API и специфическими библиотеками, Serverless удобнее использовать только как лёгкий фасад к этим сервисам.
Проекты, где критичен полный контроль над инфраструктурой
- Вы не управляете версиями Node.js, железом и сетевой топологией.
- Если нужен строгий контроль на уровне ОС или специфический стек (например, собственные C‑расширения), лучше остаться на своём хостинге.

Доступность и ограничения

Telegram не вводит отдельного домена или сайта — всё завязано на ботах. Serverless включается для каждого бота через @BotFather в интерфейсе Telegram.

Telegram официально не блокирует доступ к Serverless по регионам. Однако сам Telegram в России часто требует VPN. Если у вас Telegram открывается только через VPN, то и управление Serverless (в том числе через @BotFather) тоже потребует VPN.

Место на рынке

Telegram Serverless конкурирует не с LLM, а с инфраструктурой для ботов и serverless‑платформами:

классические VPS (DigitalOcean, Hetzner и т.п.);
облачные функции (AWS Lambda, Google Cloud Functions, Cloudflare Workers);
PaaS‑решения для ботов.

Отличительные особенности по фактам из анонса:

Глубокая интеграция с Telegram
- Код выполняется рядом с Bot API и встроенной БД.
- Не нужно настраивать вебхуки, SSL, прокси и т.п. — Telegram сам маршрутизирует обновления в обработчики.
Преднастроенный стек для Telegram‑ботов
- SDK знает всё про Bot API и SQLite‑БД.
- В отличие от Lambda или Cloud Functions, не нужно тянуть клиент к Bot API, писать обёртки и поднимать отдельную БД.
Ограниченный, но предсказуемый рантайм
- Только JavaScript‑модули без внешних пакетов.
- Нет доступа к файловой системе и произвольным бинарям.
- Это проще и безопаснее, но менее универсально, чем полноценный Node.js на VPS.
Фокус на DX (developer experience)
- Чёткая структура проекта, понятный CLI, миграции, интеграция с ИИ‑ассистентами.
- По ощущениям ближе всего к Cloudflare Workers + D1, но заточен именно под Telegram.

Telegram не публикует сравнения по скорости, цене или лимитам с AWS Lambda, Cloudflare Workers и другими. Поэтому оценивать производительность можно только по архитектурным признакам: V8‑изолят рядом с Bot API и БД теоретически даёт низкие задержки для типичных ботов.

Установка

0. Включить Serverless в @BotFather

Откройте чат с @BotFather.
Выберите своего бота.
Перейдите в раздел Serverless.
Включите Serverless для этого бота.

После этого у бота появляется:

CLI‑токен доступа;
разделы для обработчиков, библиотеки и БД прямо в @BotFather.

1. Создать проект

Самый быстрый способ — генератор проекта:

npm create @tgcloud/bot example_bot
cd example_bot

Аргументом служит папка назначения:

. — текущая директория;
любое имя или путь — новая папка.

Генератор не перезаписывает существующие файлы.

Вы получите структуру:

example_bot/
├─ docs/
│  └─ tgcloud-sdk.md       # справочник SDK (для вас и ИИ-инструментов)
├─ handlers/
│  └─ message.js           # стартовый обработчик (эхо)
├─ lib/                    # общие модули (пока пусто)
├─ AGENTS.md               # ориентир для ИИ-помощников
├─ package.json
└─ schema.js               # таблицы базы данных

CLI ставится как dev‑dependency проекта. Запуск команд:

npx tgcloud <command>

или через скрипты в package.json:

npm run deploy
npm run status

При желании можно установить CLI глобально:

npm install -g @tgcloud/cli

Тогда команды будут доступны как tgcloud ... без npx.

2. Привязать проект к боту

Каждый проект связан с одним ботом. Для привязки:

npx tgcloud login

CLI запросит CLI‑токен (не путать с Bot API токеном):

Получить его можно в @BotFather → ваш бот → Serverless → CLI Access → Access token.
Формат токена: app<id>:<secret>.
CLI сохраняет его в .tgcloud/ (эта папка игнорируется git) и не показывает секретную часть.

3. Проверить состояние проекта

Две базовые команды для статуса и отличий:

npx tgcloud status  # что изменилось локально относительно облака
npx tgcloud diff    # построчные изменения

Сразу после инициализации все файлы считаются новыми и ещё не задеплоенными.

4. Первый деплой

Отправить модули в облако:

npx tgcloud push

Команда:

загружает все изменённые модули одним атомарным батчем;
обновляет локальный снимок состояния облака.

После этого бот уже работает: отправьте ему сообщение — стартовый handlers/message.js просто вернёт текст обратно.

Важно: push никогда не меняет базу данных. Код и схема БД — разные шаги.

5. Добавить таблицу в БД

Откройте schema.js и добавьте таблицу:

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

export const messages = table('messages', {
  id: integer('id').primaryKey({ autoIncrement: true }),
  chatId: integer('chat_id').notNull(),
  text: text('text'),
  created: integer('created_at', { mode: 'timestamp' })
    .default(sql`(unixepoch())`),
});

Теперь задеплойте схему и примените миграцию:

npx tgcloud push    # загружает обновлённый schema.js
npx tgcloud migrate # создаёт таблицу messages

push покажет, что схема в коде и в БД не совпадают, но сам ничего не применит. migrate выведет список изменений и по вашему подтверждению создаст таблицу.

6. Сохранение и чтение данных

Измените обработчик handlers/message.js, чтобы он писал сообщения в БД и считал их количество:

import { api, db } from 'sdk';
import { messages } from 'schema';
import { eq } from 'sdk/db';

export default async function (message) {
  // Сохранить сообщение
  await db.insert(messages)
    .values({ chatId: message.chat.id, text: message.text })
    .run();

  // Посчитать, сколько сообщений в этом чате уже сохранено
  const count = await db.$count(
    messages,
    eq(messages.chatId, message.chat.id),
  );

  await api.sendMessage({
    chat_id: message.chat.id,
    text: `Saved. That's ${count} message(s) from this chat so far.`,
  });
}

Дальше:

npx tgcloud push

Отправьте боту несколько сообщений — счётчик в ответе будет расти. БД сохраняется между вызовами и служит «памятью» бота.

7. Локальное тестирование без деплоя

Чтобы не деплоить каждый эксперимент, используйте run:

npx tgcloud run handlers/message '{ chat: { id: 1 }, text: "hello" }'

Первый аргумент — модуль обработчика.
Второй — payload в формате JSON5 (можно без кавычек у ключей).
CLI выводит:
- всё, что попало в console.*;
- возвращаемое значение функции;
- время выполнения.

Чтобы передать ctx (второй аргумент обработчика), добавьте флаг --ctx:

npx tgcloud run handlers/message \
  '{ chat: { id: 1 }, text: "hi" }' \
  --ctx '{ update: { update_id: 1 } }'

Код берётся из локальных файлов, так что можно быстро крутить логику без деплоя.

8. Синхронизация проекта и облака

Набор команд для поддержания консистентности:

npx tgcloud status — показывает, что изменилось относительно облака.
npx tgcloud push — деплой кода.
npx tgcloud pull — подтягивает изменения из облака в локальный проект.
npx tgcloud fetch — обновляет локальный референс облака, не трогая файлы.
npx tgcloud reset — откатывает локальные изменения.

Если два разработчика или две CI‑машины деплоят в один бот, платформа обнаружит конфликт, и push остановится, пока вы не сделаете pull. Это защищает от незаметного перезаписывания чужого кода.

Как запустить: демо‑бот

Telegram показывает рабочий пример бота, который:

отвечает на каждое сообщение;
считает, сколько сообщений получил из каждого чата.

Схема БД

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

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

Обработчик сообщений

// handlers/message.js
import { api, db } from 'sdk';
import { counters } from 'schema';
import { sql } from 'sdk/db';

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

  // Вставить счётчик или увеличить, если запись уже есть
  // и вернуть обновлённую строку через .returning().
  const [row] = await db.insert(counters)
    .values({ chatId, seen: 1 })
    .onConflictDoUpdate({
      target: counters.chatId,
      set: { seen: sql`${counters.seen} + 1` },
    })
    .returning()
    .run();

  await api.sendMessage({
    chat_id: chatId,
    text: `Hello! I've seen ${row.seen} message(s) from you.`,
  });
}

Деплой демо‑бота

npx tgcloud push    # загрузить модули
npx tgcloud migrate # создать таблицу counters

После этого бот готов: он хранит состояние в БД и не требует ни одного собственного сервера.

Разработка с ИИ‑ассистентами

Telegram специально подготовил Serverless‑проекты для работы с ИИ‑кодогенерацией:

В каждом новом проекте есть:
- AGENTS.md — инструкция для ассистента, как устроен проект;
- docs/tgcloud-sdk.md — справочник по SDK.
Рантайм компактный:
- один SDK;
- никаких сторонних npm‑пакетов;
- понятные правила: импорт по голым именам, без foreign key, все вызовы к БД асинхронные, один обработчик на тип апдейта, два шага push / migrate.

Пример рабочего процесса:

npm create @tgcloud/bot my-bot
cd my-bot
opencode   # или Claude Code, Cursor и др.

Дальше можно формулировать задачу на естественном языке, например:

Напиши бота, который помнит список дел каждого пользователя: добавляет пункт при любом текстовом сообщении и показывает список по команде /list.

ИИ‑ассистент:

обновит schema.js;
создаст или изменит нужные обработчики в handlers/;
вы проверите код, быстро протестируете через npx tgcloud run;
задеплоите через npx tgcloud push и npx tgcloud migrate.

AGENTS.md — часть проекта, вы можете дополнять его по мере роста бота, чтобы ассистент лучше понимал ваши договорённости и архитектуру.

Управление через @BotFather на телефоне

Если вы остались без ноутбука, Telegram позволяет управлять Serverless‑проектом прямо из @BotFather:

В разделе Serverless для бота доступны:

Handlers
- Создание, редактирование и тестовый запуск обработчиков.
- @BotFather сам держит webhook в синхронизации с текущими обработчиками.
- Статус «In sync / Out of sync» совпадает с тем, что показывает CLI.
Library
- Редактирование модулей из lib/.
Database
- Редактирование schema.js в Drizzle‑подобном синтаксисе.
- Просмотр ожидающих изменений.
- Применение миграций (кнопка Save одновременно сохраняет и деплоит).
CLI Access
- Получение CLI‑токена, когда вы вернётесь за клавиатуру.

Это тот же самый облачный проект, который видит CLI. Можно создать обработчик на телефоне, а потом сделать npx tgcloud pull на ноутбуке и продолжить работу локально. При запуске обработчика @BotFather покажет вывод console прямо в чате — как npx tgcloud run в терминале.