One command deploys a bot backend onto Telegram's own infrastructure, and the documentation suggests pointing Claude Code or Cursor at the project.
Telegram has launched Serverless, which lets the backend code behind bots and Mini Apps run on Telegram's own infrastructure rather than on a server the developer supplies. Telegram's documentation and a write-up by Remio describe the same shape: backend logic written as plain JavaScript modules, shipped with one command, npx tgcloud push.
The pitch is aimed squarely at AI coding assistants. Every new project is scaffolded with an AGENTS.md file, which the docs call "orientation for AI coding assistants", plus an SDK reference guide. Telegram's documentation says: "Prefer to build with an AI assistant — or is the only coder on your team an AI? You can still ship a bot." Its quickstart scaffolds a project with npm create @tgcloud/bot, then opens a coding agent inside it: "opencode # or Claude Code, Cursor, … — any agent that reads AGENTS.md."
Before this, a serious production bot had to be stitched together by hand. Someone had to host the running code, catch the incoming updates, keep credentials safe and make storage survive a restart. Plenty of developers did that on general-purpose serverless clouds: AWS Lambda, Cloudflare Workers, Deno Deploy. Remio reads the launch as competitive pressure on those platforms, arguing their flexibility starts to feel unnecessary for smaller bots and Mini Apps.
The agent angle sharpens that reading. Remio's case is that once an assistant writes most of the first version and a single command puts it live, a developer no longer has to understand hosting to start building, which lets Telegram pick up projects early, before anyone has settled on a rival cloud. A bot whose code and data already sit inside Telegram, it argues, is harder to move out later than one that began somewhere neutral.
The runtime is narrow by design. No npm installs, no external module imports, no file system: code sees only the SDK package Telegram supplies and the project's own files. The built-in database, based on SQLite, has no foreign keys, so it cannot guarantee a referenced record exists, will not cascade deletes and does not prevent orphaned rows. Responses from handlers are capped at 32 megabytes, and uploading or downloading files inside a handler is not yet available.
Servers have not vanished either. Responsibility has moved: Telegram owns provisioning, availability, scaling and isolation, while application behavior, data handling and recovery logic stay with the developer.