Telegram Serverless против двух VPS: нужен ли теперь хостинг для бота?

В июле 2026 года Telegram начал приглашать некоторых участников своих конкурсов в закрытый тест Telegram Serverless. Сервис позволяет разместить код бота и его базу прямо на серверах Telegram. А 6 октября к нему добавили размещение Mini Apps, веб-приложений, которые открываются внутри мессенджера.

Serverless означает, что для такого приложения не нужно арендовать и обслуживать свой сервер. Вы загружаете код, а Telegram запускает его, когда боту приходит сообщение или человек нажимает кнопку.

Я получил доступ и решил проверить, насколько это удобно. У меня уже есть два виртуальных сервера (VPS): один в Финляндии, другой в Германии. С ними и сравнил новую площадку на одинаковой задаче.

Какие плюсы я заметил

Не настраивал сервер. На VPS для нового проекта нужно подготовить окружение, запустить приложение и настроить его восстановление. Здесь я загрузил код командой npx tgcloud push. Отдельную службу для бота не создавал, за обслуживание ОС отвечает Telegram.

База уже есть. SQLite встроена в платформу, устанавливать и подключать её не пришлось. Я описал таблицы и применил миграцию, после этого бот смог сохранять данные между вызовами.

Страница размещается вместе с ботом. Mini App загрузил на ту же площадку и получил адрес с HTTPS. Отдельный хостинг и домен для интерфейса не понадобились. Данные пользователя Telegram при обращении страницы к серверным функциям проверяет сама платформа.

Серверный код при этом ограничен JavaScript и набором инструментов Telegram (SDK). Обычные npm-пакеты и файловая система Node.js недоступны, ответ внешнего HTTP-запроса ограничен 30 МБ. Для браузерной части Mini App ограничений на npm-пакеты нет. На VPS язык, библиотеки и доступ к файлам выбираю сам.

Что я запустил

Для проверки навайбкодил бота за одну итерацию (6.1 Sol): @commongroundlabbot. Отправьте /start, нажмите «Открыть сад» и полейте дерево.

Mini App внутри Telegram. Сад открывается, полив работает. Скриншот от 17 октября.

Дерево общее для всех. Полив даёт 120 единиц роста за две минуты, поливать можно один раз за фиксированный минутный интервал. Бот, страница и база работают в Serverless.

Бот показывает состояние того же сада. 14 садовников на скриншоте созданы тестами, это не аудитория бота.

Когда человек поливает дерево, обработчик сохраняет время в SQLite. При следующем открытии сада код рассчитывает накопившийся рост и возвращает состояние.

Как всё устроено, коротко: сохраняем время полива, рассчитываем рост при открытии сада. Постоянно работающий таймер не нужен.

Прошли 12 локальных и семь облачных проверок. Повтор события не добавлял лишнюю каплю, одновременные поливы учитывались, обновление кода сохранило все 14 тестовых записей. Полив из чата и внутри Mini App тоже работает.

Ну что, давайте сравнивать

Сначала я измерил только чтение сада, полив и повтор события. Оба VPS победили, но по трём операциям с базой судить обо всей платформе рано. Поэтому добавил вычисления, работу с JSON, пакетную запись, рост базы, параллельные обращения и внешние HTTP-запросы.

У каждого VPS один vCPU и около 2 ГБ RAM. Для базы использовал одинаковый Node.js и SQLite, WAL/FULL. Обнаружил ошибку первого стенда: в Финляндии временная папка была в RAM. Новые замеры обоих VPS сделал на постоянном диске, ext4. В Telegram база доступна через SDK, её параметры синхронизации в этом тесте проверить не удалось.

Каждую серию повторил трижды. Ниже медианы в миллисекундах: 150 измерений для поиска, 30 для вставки 32 строк, 90 для чтения сада и 60 для полива. Прогрев исключён.

Операция

VPS Финляндия

VPS Германия

Telegram Serverless

Найти строку по ключу

0,009

0,013

2

Вставить 32 строки по одной

18,16

95,48

533

Вставить 32 строки одним запросом

0,69

0,53

16

Прочитать сад, 1000 поливов

0,26

0,25

7

Принять полив, 1000 записей

0,87

0,74

22

На SQL оба VPS быстрее, но способ обращения к базе меняет результат в разы. В Telegram одна вставка 32 строк заняла 16 мс вместо 533 мс при отдельных запросах. Примерно 33-кратная разница внутри одной площадки. На VPS объединение записей тоже помогло.

С вычислениями картина другая. Два миллиона целочисленных операций заняли около 2 мс во всех средах. А десять циклов разбора и сборки JSON объёмом 530 КБ в Telegram прошли за 11,1 мс, на VPS за 29,8 и 34,2 мс. Здесь Serverless оказался быстрее. Для этих задач измерял 30 блоков повторов и делил время на число повторений.

Дальше увеличил журнал сада. При 10 000 поливов чтение заняло около 2,1 мс на VPS и 36 мс в Telegram. На 100 000 облачный запрос упёрся в rows_read limit exceeded. Отдельная проверка показала: сумма по 50 000 строк считается, по 50 001 уже нет. Но поиск по ключу в таблице из 100 001 строки работает. Ограничен запрос, а не размер таблицы. Моему саду пора сохранять готовые итоги вместо пересчёта всей истории.

Параллельные прибавления при уровнях 1, 4 и 8 сохранились во всех средах, по 65 из 65. В Telegram это SQL-вызовы внутри одной функции, на VPS отдельные соединения SQLite. Предел нагрузки пользователей такой тест не устанавливает.

Проверил и исходящий HTTP: загрузка одного и того же скрипта Telegram заняла в медиане 16 мс из Serverless, 54 мс из Финляндии и 23 мс из Германии. По 30 успешных запросов, но это один адрес и конкретный сетевой маршрут.

Время SQL и вычислений выше не включает доставку ответа в клиент Telegram и холодный старт. Полный HTTP-бэкенд Mini App на VPS я не разворачивал. Все выборки, p95, неудачные запросы и методика находятся в отчёте.

Что я думаю после всех тестов

После всех исследований я пришёл к выводу: для рабочего проекта с базой данных я выбираю VPS. В моём эксперименте у него четыре весомых преимущества:

• База быстрее. На 1000 записях полив с возвратом состояния занял 0,74–0,87 мс вместо 22 мс, примерно в 25–30 раз меньше времени.

• Свобода разработки. Можно выбирать язык, библиотеки и СУБД. В Serverless серверный код ограничен JavaScript и SDK Telegram, обычные npm-пакеты недоступны.

• Контроль над приложением. Запуск процессов, настройки базы и резервное копирование можно устроить под свою задачу.

• Большой журнал прошёл тест. Запрос к 100 000 поливов на обоих VPS отработал. В Serverless тот же пересчёт упёрся в лимит чтения, модель пришлось бы менять.

Главным козырем Serverless для меня оказался бесплатный старт. Бот, база и Mini App в этом эксперименте не стоили ничего, отдельный сервер обслуживать не пришлось. Это условия нашего раннего доступа, публичных тарифов в проверенной документации пока нет.

Идею я готов проверять на Serverless. Рабочие проекты оставляю на VPS: скорость базы и свобода разработки для меня важнее.

Если хотите попробовать Serverless, дальше гайд по подключению.

Как получить доступ

1. Откройте @BotFather, нажмите Open, выберите или создайте тестового бота.

2. В разделе Serverless отправьте заявку через Get access to Serverless, если доступ ещё не выдан.

3. После приглашения включите Serverless и получите токен в CLI Access, Access token.

ИИ-иллюстрация пути подключения через BotFather. Расположение элементов условное.

С установленным Node.js создайте проект и загрузите стартовый обработчик:

npm create @tgcloud/bot my_serverless_lab cd my_serverless_lab npx tgcloud login npx tgcloud push

При login понадобится токен CLI, он отличается от токена Bot API. После загрузки отправьте боту текст, стартовый обработчик вернёт его обратно.

Если добавляете таблицы в tgcloud/schema.js, отдельно примените схему:

npx tgcloud migrate —dry-run npx tgcloud migrate —safe

При запуске сада код уже загрузился, а таблицы появились только после миграции.

ИИ-иллюстрация этапов запуска через CLI.

Исходники сада, данные замеров и инструкция для своей копии находятся в репозитории на GitHub.

Первые проверки выполнены 10 октября 2026 года, расширенные замеры и проверка документации 17 октября.

Буду рад видеть вас в моём Telegram.

English version on DEV