Telegram Serverless bắt đầu lưu trữ Mini App trên tên miền tgcloud.ai

Ngày 6 tháng 10, Telegram đã cập nhật Serverless, nền tảng dành cho mã bot của mình. Giờ đây, nền tảng này cũng lưu trữ giao diện người dùng (frontend) của Mini App: bản dựng được triển khai cùng với bot chỉ bằng một lệnh duy nhất và có thể truy cập tại địa chỉ dạng app<id>.tgcloud.ai. Mini App đã có các chức năng phía máy chủ mà nó gọi từ telegram-web-app.js. Bản cập nhật này ảnh hưởng đến tất cả những ai đang duy trì backend của bot hoặc Mini App trên máy chủ riêng của mình, cũng như những người đã chuyển bot sang Serverless vào tháng 7: dự án cũ cần được chuyển đổi sang bố cục thư mục mới một lần.

Serverless là một backend dành cho bot, được Telegram chạy trên hệ thống của mình. Mã được viết bằng các module JavaScript thông thường và được thực thi trong các V8 isolate, tức là trong các môi trường sandbox nhẹ bên trong một tiến trình duy nhất, cạnh Bot API. Kèm theo mã là một cơ sở dữ liệu SQLite và HTTP đi ra. Không cần máy chủ, container hay webhook riêng. Phiên bản đầu tiên của công cụ dòng lệnh @tgcloud/cli đã được phát hành trên npm vào ngày 12 tháng 7, trang tài liệu xuất hiện trong kho lưu trữ web vào ngày 13 tháng 7. Khi đó, nền tảng chỉ có thể phản hồi các cập nhật của bot: trong phiên bản tài liệu tháng 7 không có phần nào về frontend, cũng không có từ "endpoint".

Có gì thay đổi vào ngày 6 tháng 10

Mini App không còn yêu cầu hosting, chứng chỉ và máy chủ API riêng biệt. Frontend được xây dựng bởi bất kỳ bundler nào, công cụ so sánh các tệp bằng hàm băm và chỉ tải lên những tệp đã thay đổi. Địa chỉ mà push in ra được nhập vào @BotFather làm địa chỉ của Mini App.

Phải làm gì với dự án ở phiên bản 0.1

Công cụ 0.2.0 sẽ từ chối làm việc với bố cục cũ cho đến khi dự án được chuyển sang bố cục mới. Chuyển đổi bằng một lệnh duy nhất:

• npx tgcloud upgrade di chuyển schema.js, lib/ và handlers/ vào thư mục tgcloud/. Tên module (lib/cart, handlers/message) không thay đổi.
• Các import theo tên module vẫn hoạt động, nhưng tài liệu khuyên nên chuyển sang đường dẫn tương đối với .js.

Đối với những người kết nối Mini App:

• push tải lên thư mục bản dựng nguyên trạng và không tự xây dựng gì cả. Nếu thực hiện lệnh này sau khi sửa frontend mà không xây dựng, phiên bản trước đó sẽ được triển khai. Script npm run deploy, được thêm vào bởi mẫu dự án, trước tiên sẽ xây dựng, sau đó tải lên.
• Telegram Web mở Mini App trong một iframe, vì vậy không được đặt tiêu đề X-Frame-Options và frame-ancestors nghiêm ngặt.
• Đường dẫn /api/ trên cùng địa chỉ đã bị chiếm bởi các endpoint, không nên đặt các tệp của riêng bạn vào đó.
• immutable trong cấu hình — chỉ dành cho các tệp có hàm băm trong tên. Các tệp khác trình duyệt sẽ giữ trong bộ nhớ đệm một năm, và không có cách nào để thu hồi chúng.
• Next.js, Nuxt, SvelteKit và Angular không được công cụ tự động nhận diện: trước tiên cần cấu hình xuất tĩnh và nhập thư mục của nó vào "source" thủ công.

Cách Mini App gọi backend của nó

Cùng ngày, lúc 09:27 UTC, Telegram đã cập nhật telegram-web-app.js, script kết nối bất kỳ Mini App nào. Trong đó xuất hiện đối tượng Telegram.WebApp.Serverless với một phương thức duy nhất là call. Phương thức này thực hiện POST đến địa chỉ tương đối /api/<name>, tức là đến cùng máy chủ mà ứng dụng được mở. Do đó, lệnh gọi chỉ hoạt động với Mini App được lưu trữ trên tgcloud.ai: từ tên miền riêng, yêu cầu sẽ được gửi đến máy chủ riêng.

Trong tiêu đề Authorization, script đặt chuỗi TMA và initData ở dạng base64. initData là một tập hợp các trường đã được Telegram ký về người dùng và cuộc trò chuyện mà client mở Mini App. Nền tảng kiểm tra chữ ký trước khi chạy mã, và nếu không có nó, yêu cầu sẽ nhận được 401. Endpoint nhận được người dùng đã được xác minh trong ctx.initData.user. Không cần phải kiểm tra chữ ký initData thủ công như khi trên máy chủ riêng, và backend như vậy không có API mở cần được bảo vệ.

Lỗi được chia thành hai loại. EndpointError, được mã cố ý ném ra, đến client với văn bản và các tham số mà frontend có thể phân nhánh. Bất kỳ ngoại lệ nào khác client sẽ thấy là lỗi nội bộ, còn văn bản thực sự vẫn nằm trong nhật ký để cấu trúc backend không bị lộ ra ngoài.

Máy chủ báo cáo gì về bản thân mà không cần token

Công cụ truy cập API tại cloud.telegram.org. Một trong các phương thức của nó, /capabilities, trả lời mà không cần ủy quyền: nó mô tả bố cục dự án, các mẫu AGENTS.md và docs/tgcloud-sdk.md và danh sách các loại cập nhật có thể gắn trình xử lý. Có 27 loại như vậy. Công cụ so sánh số schema của dự án với phản hồi này và cảnh báo nếu máy chủ đã biết các thư mục mà nó chưa biết. Trong mã của công cụ cũng có một công tắc TGCLOUD_BETA=1, hướng các yêu cầu đến /beta. Tính đến ngày 6 tháng 10, phản hồi beta trùng khớp với phản hồi chính.

Tại sao tên miền lại là .ai

Tên miền tgcloud.ai được đăng ký vào ngày 11 tháng 9 năm 2026 thông qua GoDaddy. Cùng ngày, một chứng chỉ *.tgcloud.ai đã được cấp cho nó, một chứng chỉ cho tất cả các tên miền phụ dạng app<id>. Địa chỉ tên miền, 149.154.166.100, nằm trong mạng Telegram_Messenger_Network (AS62041). Gốc tên miền trả về một 404 trống: nền tảng không có giao diện người dùng, chỉ có các tên miền phụ của ứng dụng.

Bản thân phần mở rộng chưa chứng minh điều gì: .ai là tên miền quốc gia của Anguilla, đã được các dự án công nghệ sử dụng từ lâu. Và tgcloud.com đã bị chiếm từ năm 2011 bởi một chủ sở hữu khác, vì vậy việc lựa chọn có thể chỉ đơn giản là vấn đề tên miền còn trống.

Nhưng nền tảng ngay từ đầu đã được xây dựng xung quanh các tác nhân AI viết mã và xung quanh các bot tạo ra phản hồi.

• Mã được viết bởi tác nhân. Phần «Building with AI» đã có trong tài liệu từ tháng 7. Mỗi dự án mới nhận được AGENTS.md, mà theo chính mẫu đó, được Claude Code, Cursor và các công cụ tương tự tự động đọc, cùng với tài liệu tham khảo SDK trong docs/. Tài liệu đề xuất mở dự án trong tác nhân và mô tả bot bằng lời nói, và gọi bước này là bước đầu tiên.
• Môi trường được thiết kế cho mã được tạo. Không có gói npm, một SDK duy nhất, các quy tắc nghiêm ngặt như một tệp cho mỗi loại cập nhật. Càng ít biến thể, tác nhân càng ít mắc lỗi, và tài liệu trực tiếp liệt kê các thỏa thuận mà "tạo mã thông thường" bỏ qua.
• Bot tạo ra phản hồi. Trong số 27 loại cập nhật mà Serverless chấp nhận, có stopped_message_generation và guest_message. Cả hai đều xuất hiện trong Bot API vào mùa xuân và mùa hè cùng với các chức năng khác dành cho bot dựa trên các mô hình ngôn ngữ.

Điều mà Serverless chưa có là chính mô hình. SDK bao gồm ba phần: cơ sở dữ liệu (sdk/db), Bot API (sdk/api) và fetch. Để bot trên Serverless trả lời bằng văn bản từ mô hình ngôn ngữ, nó đi qua fetch đến API bên ngoài với khóa riêng của mình. Tài liệu fetch đặc biệt đề cập đến việc đọc phản hồi theo luồng như một cách để nhận đầu ra của API AI theo từng token.

Telegram có sẵn năng lực cho các mạng thần kinh. Cocoon, một mạng lưới tính toán bảo mật trên GPU với thanh toán bằng TON, đã được Durov giới thiệu tại Blockchain Life 2025, và trang web của nó được phục vụ từ cùng một địa chỉ trong mạng Telegram như telegram.org. Từ đó có giả thuyết: phần tiếp theo của SDK có thể là một lời gọi mô hình tích hợp, không cần khóa bên ngoài và thanh toán qua Telegram. Giả thuyết thứ hai liên quan đến @BotFather: trình chỉnh sửa các trình xử lý, cơ sở dữ liệu và tệp của Telegram Mini App đã có sẵn trong đó trên điện thoại, và việc mô tả bot bằng lời thay vì mã code có vẻ là bước tiếp theo cho trình chỉnh sửa như vậy. Hiện tại, không có giả thuyết nào được xác nhận ngoài tên miền và hướng của các bản cập nhật gần đây: trong tài liệu, công cụ dòng lệnh và phản hồi /capabilities từ ngày 6 tháng 10, không có mô-đun nào dành cho mạng thần kinh.