Telegram Serverless Cuts the Bot Hosting Tax

For years, a Telegram bot that did anything past canned replies still needed a home. You registered a webhook, pointed it at Lambda or Cloud Functions or a Vercel route, stuffed the bot token into env vars, and hoped cold starts and network hops would not make /start feel broken. Telegram Serverless collapses that stack. Your handlers run on Telegram’s own infrastructure, next to the Bot API and a platform database, as plain JavaScript modules. That is not another FaaS tutorial with a Telegram skin. It is a purpose-built execution plane for bots and Mini Apps, and it changes the threat model and the ops model at the same time.

The shift is real for a large class of bots. It is not a free lunch, and it is not for every backend. The interesting part is where the code runs, not the marketing word “serverless.”

The old path still had servers in the middle

Webhook-driven bots on third-party clouds have been a common pattern for years. Google Cloud Functions, AWS Lambda via the Serverless Framework, DigitalOcean Functions, Yandex Cloud Functions, Vercel: same skeleton every time. Create a bot with BotFather, deploy an HTTP function, call setWebhook with the function URL, keep TELEGRAM_TOKEN out of the repo, and answer updates when Telegram posts them.

That works. It also leaves you owning three separate concerns Telegram never had to care about: a publicly reachable endpoint, credential hygiene for the Bot API, and whatever store you bolt on when “echo the message” becomes “remember this user.” Traffic still leaves Telegram, hits your cloud, then calls back into api.telegram.org. Latency and failure modes pile up at those edges. Hobby bots on a VPS or Docker Compose avoid some cold-start pain and pay in patching, idle cost, and migration chores instead.

None of that is hard for a seasoned team. It is pure tax for the bot that mostly reacts to updates and holds a bit of per-chat state.

What Telegram actually put next to the Bot API

Telegram Serverless removes the external host. You enable Serverless on the bot in BotFather, scaffold a project, and deploy modules that Telegram runs on demand in isolated V8 sandboxes close to its own systems. There is no machine to rent or patch, no container to keep warm, and no separate webhook URL to register for the happy path. Scaling follows the bot’s traffic.

The included surface is opinionated:

• Bot API access through an SDK (api), without wiring tokens into your own HTTP client for normal calls
• A SQLite-backed database with a schema DSL and migrations
• Outbound HTTP for third-party integrations
• A local project layout that maps cleanly to what runs in the cloud

Code lives in three places that stay aligned: your folder (handlers, lib/, schema.js), the deployed modules plus the bot’s database, and the tgcloud CLI that diffs and syncs them. You do not SSH anywhere. Edit locally, npx tgcloud push, migrate schema when needed, and traffic hits the deployed handlers.

The runtime model matches how Telegram already thinks about updates. One file per update type under handlers/ (message.js, callback_query.js, and so on). Telegram routes the update to the matching default export and ignores types you never implemented. Shared code goes in lib/. Schema is explicit and versioned, not a silent side effect of the first insert.

A minimal stateful bot is small enough to reason about in one sitting: declare a counters table keyed by chat_id, upsert on each message, reply with the new count. Deploy is two commands after the project exists (push, then migrate). That is a live bot with durable state and no server process of yours.

Telegram positions this as a general backend for bots and Mini Apps, not a single template: conversational agents that need per-user state, Mini App backends, games and leaderboards, automations that call external HTTP APIs and push results into chats.

What changes in day-to-day work

Practically, you stop treating the bot as a tiny web service and start treating it as event handlers plus a schema.

Bootstrap. Node.js 18+, a bot already registered with BotFather, Serverless flipped on for that bot. Then:

npm create @tgcloud/bot example_bot
cd example_bot
npx tgcloud push
npx tgcloud migrate

The scaffold ships a starter handlers/message.js, empty lib/, schema.js, SDK reference under docs/, and AGENTS.md aimed at AI coding tools. Day-to-day commands cluster around push, migrate, run, and status. Deploys are atomic; schema moves forward with reviewed migrations, which is closer to normal app work than to “edit the function in the cloud console.”

Structure you actually maintain.

handlers/     # one entry point per update type
lib/          # shared modules
schema.js     # tables via the SDK DSL

Handlers import api and db from the platform SDK and tables from schema.js. The demo pattern uses insert-on-conflict-update with .returning() so a single statement both bumps state and gives you the row for the reply. That is the whole loop: update in, Bot API and DB calls out, return.

What it replaces. For many bots, this replaces the webhook function on Lambda/GCF/Vercel and the separate small database you would have stood up next to it and the glue that kept tokens and URLs consistent across environments. For Mini Apps that needed a thin authenticated backend, co-location with Telegram’s identity and update model is the draw, not generic compute pricing.

What it does not replace. Heavy workers, multi-region data planes, non-JS stacks, or anything that must live in your VPC next to internal systems still want a real cloud account. Outbound HTTP is available; that does not make this a full integration bus.

Lock-in, limits, and who should adopt

Judgement call: this is production-ready for Telegram-centric products whose core job is reacting to updates and storing bot-shaped state. It is a poor fit if Telegram is only one channel among many, or if you already standardized on a single cloud’s functions and databases across products.

Trade-offs to price explicitly:

• Platform lock-in. Handlers, schema DSL, CLI, and the V8 isolate model are Telegram’s. Porting later means rewriting against webhooks and your own store. That is fine when Telegram is the product surface.
• JavaScript modules only (as documented). Teams standardized on Python or Go keep the older webhook-on-FaaS path, which remains well traveled.
• SQLite-backed storage. Excellent for per-chat counters, sessions, simple game state, and Mini App user records. It is not a substitute for a globally distributed OLTP system. Design for the store you have; do not pretend it is Postgres-in-disguise.
• Operational opacity. You gain “no servers to patch.” You lose the ability to drop into your own process, custom metrics agents, or exotic runtimes. Status and CLI workflow are the control plane; treat that as a dependency in your incident runbooks.
• Security shape. Secrets for the Bot API are less of your problem on the happy path, which is good. Your threat model shifts toward what the sandbox allows (outbound HTTP, data you write to the shared DB, Mini App trust boundaries) and away from “is my webhook TLS and auth correct.” That is a simplification, not zero residual risk.

Who wins: indie builders, internal tools, game and quiz bots, AI chat front-ends that need memory without standing up Redis, Mini App authors who wanted a backend without a second vendor. Who loses little sleep either way: platform teams already deep in AWS/GCP with multi-channel messaging and strict data residency rules. Those teams can ignore this until a Telegram-only surface justifies a second runtime.

Compared with bolting a bot onto generic serverless, Telegram’s version is narrower and sharper. Generic FaaS stays better at “any HTTP trigger, any language, my database.” Telegram Serverless is better at “this update type, this chat state, this reply, no ceremony.”

Bottom line

Telegram did not invent serverless bots. It removed the reason most bot backends existed as separate services: proximity. When the isolate, the Bot API, and the database sit together, the classic three-hop design looks like accidental complexity for a large slice of the ecosystem.

Use it when your backend is the bot (or the Mini App behind it) and JavaScript plus SQLite match the problem. Keep webhooks on your own cloud when Telegram is one client among many or when you need a data plane Telegram will not give you. The hosting tax is optional now. Paying it should be a conscious choice, not the default.