Telegram Serverless: код, БД и Mini App без своего сервера — что это даёт в 2026

Что произошло, почему это важно и что взять в работу.

Telegram закрывает инфраструктуру ботов и Mini App из коробки — SMB-разработчикам больше не нужен VPS, вебхуки и внешняя СУБД для запуска продукта.

Связанные услуги: каталог, AI Boost Team, стать клиентом.

Сервер больше не нужен

Эхо-бот пишется за вечер. Продукт с базой, сохранением состояния и Mini App — уже проект: VPS, вебхуки, SSL, внешняя СУБД, деплой статики и ночные падения в самый неподходящий момент. Telegram забрал эту часть себе.

В настройках бота в @BotFather появился раздел Serverless (beta). Логика на JavaScript, выполняется в изолированных окружениях V8 isolates — без своего сервера и без контейнеров. Внутри есть реляционная база на SQLite, причём схема описывается прямо в коде типизированным конструктором из модуля sdk/db. Фронтенд Mini App раздаётся с домена *.tgcloud.ai. Вебхук, сертификаты и маршрутизация апдейтов — не ваша зона ответственности.

Панель управления состоит из шести блоков: CLI Access, Handlers, Endpoints, Library, Database, Mini App Files. Проект поднимается командой npm create @tgcloud/bot, дальше работа идёт из терминала через @tgcloud/cli: обработчики событий, серверные ручки для Mini App, общая библиотека модулей, миграции, деплой статики, удалённый запуск и логи.

Формально это тот же класс задач, что раньше решали связкой «хостинг плюс Postgres плюс отдельный фронт». Разница в том, что раньше вы собирали контур из четырёх подрядчиков, а теперь включаете переключатель.

Что было до и почему порог упал именно сейчас

Последние годы типовой стек телеграм-бота выглядел так: библиотека вроде grammy или telegraf, VPS, вебхук с валидным SSL, база отдельным сервисом, плюс для Mini App — ещё один хостинг статики, домен и возня с CORS. Каждый слой давал свою точку отказа и свою строку в счёте. Самое неприятное — стыки: код задеплоен, схема БД не мигрирована, вебхук смотрит не туда.

Telegram собрал слои в один контур с общим деплоем и общим состоянием.

Фактически Telegram бесплатно отдаёт разработчику полноценный Fullstack-контур: вычислительный рантайм для бота и бэкенда, встроенную базу данных (SQLite под капотом) и CDN/хостинг статики на домене *.tgcloud.ai.

Для SMB это меняет экономику запуска. Раньше вопрос «сделать бота с личным кабинетом» упирался не в разработку, а в то, кто будет держать инфраструктуру и что делать, когда она ляжет в субботу. Теперь этот вопрос снимается на старте. Появляется другая проблема — что вы будете делать, когда бот начнёт приносить деньги, а платформа всё ещё beta.

Где подвох: три вещи, которые видно сразу

Первая. Деплой кода и миграция схемы специально разделены: npx tgcloud push заливает файлы, npx tgcloud migrate применяет изменения БД. Панель показывает предупреждение Out of sync с числом ожидающих изменений — в примере из разбора это 8 changes pending. Задумка здравая: случайный пуш не должен сносить продакшен-данные. Но это значит, что дисциплина миграций остаётся на вас, автоматической страховки нет.

Вторая. Access token проекта — не то же самое, что токен Bot API. Хранить их в одном месте не стоит, перевыпуск делается кнопкой Revoke в панели. Мелочь, на которой легко поймать утечку.

Третья. Вы уезжаете в чужой рантайм целиком: вычисления, данные, статика. SQLite под капотом — не ваша забота, пока не понадобится тяжёлая аналитика или экспорт истории. Про лимиты, тарифы и гарантии доступности в описании платформы ничего нет, поэтому обещать себе безоблачное будущее на этом стеке нельзя. Это бета, и относиться к ней надо как к бете.

Что реально собрать на этом контуре

Автор разбора не остановился на демо и поднял мультиплеерный Wordle — @wordslebot. В проекте 14 эндпоинтов, два языка (ru и en) со своими словарями и раскладками, друзья, инвайты, лобби, комнаты и чат внутри комнаты. Всё — без единого внешнего бэкенда.

Ключевая деталь не в масштабе, а в архитектуре: обработчики чата и эндпоинты Mini App ходят в одну и ту же базу через sdk/db. Игрок начинает раунд в диалоге с ботом, продолжает в веб-аппе, и поля вроде попыток, загаданного слова и серии побед синхронизируются сразу. Раньше это был отдельный проект с синхронизацией двух хранилищ.

Под этот шаблон ложится почти любой SMB-сценарий с продолжением в интерфейсе: заказ в чате и корзина в Mini App, запись на услугу с личным кабинетом, клубная механика с баллами и уровнями. Плюс бонус для тех, кто пишет код с ИИ: в шаблоне создаются AGENTS.md и docs/tgcloud-sdk.md, а документация отдаётся в Markdown. Модель не путает нативный SDK со сторонними библиотеками, потому что спецификация уже лежит в проекте.

Отдельно про сроки: заявленные 6 минут чтения разбора — это про чтение. Реальный переезд занимает больше, и основное время уйдёт не на код, а на перенос схемы данных.

Что сделать на этой неделе

1. Включить Serverless (beta) на тестовом боте в @BotFather. Боевого не трогать.
2. Поднять каркас через npm create @tgcloud/bot и прочитать AGENTS.md и docs/tgcloud-sdk.md до первой строки кода.
3. Описать схему данных конструктором sdk/db и прогнать миграцию отдельно от пуша. Проверить, что предупреждение Out of sync гаснет.
4. Завести отдельный Access token, не смешивать с токеном Bot API, проверить работу Revoke.
5. Собрать один сквозной сценарий «начало в чате — продолжение в Mini App» на общей таблице. Если состояние расходится, архитектура выбрана неверно.
6. Выписать, что вы теряете при переезде: лимиты, тарифы, выгрузка данных. Получить ответы до того, как на платформу уедет платящий клиент.