Moonshot AI's Kimi Code and Kimi Work are now part of the CloudBase ecosystem. Two products, two interaction models, one plugin.

Why Kimi​

Kimi is one of the fastest-growing players in China's AI coding space. From conversational AI to code generation, Moonshot AI has expanded into two distinct product lines: Kimi Code (a terminal-first CLI client) and Kimi Work (a desktop agent for knowledge workers).

For CloudBase users, this means two more entry points for operating cloud resources with natural language.

Two Products, Two Use Cases​

Kimi Code: For Terminal Users​

Kimi Code is a command-line-first AI programming client, similar to Claude Code or Codex CLI, but deeply integrated with Kimi's model capabilities.

Installation is straightforward:

1. Type /plugins in Kimi Code to open the plugin panel
2. Switch to the Curated tab
3. Find Tencent CloudBase, press Enter, select install

After restarting Kimi Code, CloudBase's 29 skills + 1 MCP service load automatically. You can directly say:

• "Create a PostgreSQL table for user data"
• "Deploy a cloud function for file upload"
• "Check today's environment usage"

Everything happens in your terminal — no browser switching needed.

Kimi Work: The Desktop Productivity Tool​

Kimi Work is a macOS / Windows desktop app designed for a broader audience of knowledge workers — not just coders, but anyone doing document organization, data analysis, scheduled tasks, and more.

Equally simple setup:

1. Open Kimi Work → Settings (gear icon) → Plugins
2. Find Tencent CloudBase, toggle the switch
3. Panel shows v0.2.0 · 29 skills · 1 MCP service

Technical Details: One Plugin, Both Ends​

The CloudBase Kimi plugin (cloudbase-kimi-plugin.zip) is packaged via Open Plugin Spec and includes:

The plugin identifies its source via INTEGRATION_IDE=Kimi (Code) or INTEGRATION_IDE=Kimi Work, and the CloudBase MCP Server optimizes prompts and default config paths accordingly.

Next Steps​

• Kimi Setup Guide — Kimi Code marketplace install and manual MCP config, plus Kimi Work plugin panel and ZIP install
• CloudBase Overview — All supported IDEs and capabilities

In this post: building a genuinely usable workbench on CloudBase from 0 to 1, then growing it to handle images and video, permissions and collaboration, shareable links, scheduled jobs, and payments. No code writing — everything runs inside WorkBuddy.

First, some context. Two waves of "homework submissions" recently made AI-built workbenches go viral: one started when a creator posted videos on Xiaohongshu teaching people to build personal workbenches with AI and showing off submissions, igniting a platform-wide trend. The other was WorkBuddy's AI workbench template contest, with a lively comment section.

Among the comments, alongside the "it finally runs!" wins, deeper questions started to surface: the page opens empty on another device, images won't sync, links sent to others can't be filled in, family members want to share it but each see only their own stuff.

These are all signals that the workbench wants to grow up.

Workbenches grow. The base that felt smooth at the start often can't keep up.

So this post covers two things: first, walking you from 0 to 1 building the workbench on CloudBase, then how to bolt on capabilities that keep it growing (media, permissions, sharing, payments, scheduled jobs, AI...).

1. When do you know it's time to switch bases?​

Watch for these four signals. Hit any one of them, and your base needs an upgrade.

Signal 1 — You want images, video, PDFs — not just text

"Can it sync images? I'm making a notebook workbench, adding photo-and-text notes daily… but new notes never sync."

Browser localStorage can't hold images; a few base64-encoded ones blow the quota.

Signal 2 — You want to share it with family or a team, but everyone sees only their own

"Can one account be shared with my daughter? Could we collaborate on one interface from different computers, create family projects, help her with homework, track daily plans…"

Multi-device login on one account is the bare minimum. Real collaboration means "everyone logs in as themselves, shares selected data, keeps their private space." That requires a full identity + permission system.

Signal 3 — You want to send a link to outsiders who can read and write

"The published link can't interact with the data table (internal links can)…"

This is the natural boundary of spreadsheet-style sync solutions: the built-in editor maintains associations for you, but once published as an external link outside the editor, the read/write channel breaks. A cloud database doesn't have this problem — no matter where you open it from, it's the same set of APIs.

Signal 4 — You want to go further: websites, mini programs, online payments, a backend that runs itself

"Hoping for lightweight website / app / mini program features, with online payment support… so a true beginner can build a compliant website and app."

That's full-stack application territory. The workbench is the entry point; to hook up more capabilities later, the base has to carry them.

Hit any one of these, and it's time to upgrade the base.

2. From 0 to 1: build a genuinely usable workbench on CloudBase​

No code. Everything runs in WorkBuddy. Follow these 7 steps and you'll end up with a workbench that syncs between desktop and phone, stores images, and keeps data no matter who visits.

What you'll have​

• A content-creation workbench (or swap in your own scenario) — with "Today's focus / Topic ideas / Content progress / Publishing calendar / Weekly review"
• Data lives in Tencent CloudBase, auto-synced between local and cloud
• Open the same URL on desktop and phone, see the same thing
• Images and files sync too

What you need​

• The WorkBuddy client: chats, connectors, and Skills all live in it
• A Tencent Cloud account: for a free-tier CloudBase environment
• Desktop + phone: that's how we verify cross-device
• Once the environment is created you'll have an environment ID — connectors, deployment checks, and domain binding all use it

Step 1: Generate the workbench​

Open WorkBuddy and pick one of three ways to start:

• Use a template: below the chat box, "Not sure what to build? Try a best-practice case" — pick the closest one and apply it with the official or open-source prompt

  

• Write it yourself: one sentence (goal + modules + constraints)

Build a content-creation workbench with five modules: today's focus, topic ideas, content progress, publishing calendar, weekly review. Start with a locally runnable version; adapt it for mobile.

It won't start writing immediately — it clarifies requirements with you first: scenario / modules / devices / navigation / what shows on the home page / visual style. The clearer this step, the less rework later.

Once requirements line up, hit "Start building" and let it run in the background. A preview appears on the right when done; "Open in external browser" at the top right is easier to look at.

Don't rush to the cloud — click through the local version by hand first:

• Try add / edit / delete / check on every module

• Home page numbers should update with the modules

• Press F12 to switch to the mobile view; screenshot any layout breakage and send it back to WorkBuddy to fix

While you're at it, have WorkBuddy remove the "Reset sample data" button so you never wipe everything by accident. Next: move the data layer from local to cloud.

Step 2: Create a CloudBase environment​

CloudBase has a free trial tier. Go to the Tencent CloudBase console:

1. Click "Free trial" — new users get free quota; learning and small-scale use cost essentially nothing

2. Complete "service authorization" on first entry

3. Give the environment a meaningful name (like growth/rich — logs, deployments, and domain binding all use it to identify you)

4. Region defaults to Shanghai

5. Pick the free-trial edition and choose "Document database (NoSQL)". PostgreSQL / MySQL are also supported — choose per your workload.

6. Enter the redemption code and click "Buy now"

Once created, the console shows cloud database, cloud functions, cloud storage, and authentication. Your workbench data lives in this environment.

Step 3: Connect WorkBuddy to CloudBase​

Back in WorkBuddy, open connectors, search "Tencent CloudBase" in the connector manager, and click + to install. Select it and it takes effect in your session.

When authorization succeeds, the connector turns green. At this point WorkBuddy can actually read the environment you just created — it has upgraded from "only edits local code" to "can operate cloud resources".

From now on you can ask WorkBuddy in chat to query the database, deploy sites, or manage cloud functions — no need to open the console yourself.

Step 4: Move the data layer to the cloud and publish a preview​

Go back to the chat that generated the workbench and just say:

Store the workbench data in CloudBase; I need multi-device sync.

Copy that sentence or use your own words. The core: data to the cloud, multi-device sync.

It will first ask for authorization, then confirm where the data currently lives, which modules and fields exist, which files change, how old data gets backed up, and how to roll back on failure.

Once the plan is agreed, let it execute: back up local data → create collections in CloudBase → switch reads/writes from local to cloud → deploy an access URL.

Sync mode: the most robust is "local + cloud auto-sync" — keep a local copy for instant loads, cloud collections as the multi-device source of truth. The document database is schemaless, so adding new fields later needs no migration; writes just sync.

Deployment mode: static hosting, URL like https://<env-id>.webapps.tcloudbase.com; you can bind a custom domain in the console for something memorable.

• Open the URL on desktop, add a task, confirm it sticks; open the same URL on your phone — the data is there

• Add an item on desktop, refresh on phone and it appears; check it off on phone, refresh on desktop and the state syncs

• Upload an image, refresh on the other end, the image is there

• 

At this point you have a workbench that syncs across devices, stores images, and has working shareable links — the starting point of "actually usable". You can also check the deployed app in the cloud console.

You can also just tell the AI: check whether the backend database is working normally — it will query all your cloud resource usage.

3. Leveling up: four "watershed" capabilities that turn "usable" into "great"​

After the deployment above, the workbench is already in the cloud. These next four moves each push it one step closer to "practical".

3.1 Images, video, and big files all sync​

Text goes into the database; images and video go to cloud storage; a single record links the two. That's CloudBase's basic setup — you already got image sync along the way in step six. Video follows the same logic; files are just bigger, which makes them even more worth putting in the cloud. Local video stuffed into a project folder uploads slowly and doesn't belong in a code repository.

How video-to-cloud + in-app playback lands, in two parts:

A. Create cloud storage (one time)

1. In your environment, under "Cloud storage", create a bucket. A separate bucket for video is recommended — don't mix it with images, so you can control permissions and clean old files independently.

B. Upload video and wire it into the workbench (each new video)

1. With the connector set up, just tell WorkBuddy in chat "upload this video to cloud storage" — no manual console uploading

2. A cloud access URL comes back on success

3. Tell WorkBuddy: "generate a page in the workbench that plays the video from that cloud URL" — it produces a page with a <video> tag pointing at the cloud URL

The benefit is direct: the project folder stays light, yet video plays on demand. No worrying about browser storage limits.

Images, video, PDFs — any static asset works the same way.

3.2 Tiered permissions: everyone sees only their own while collaborating​

This is the core of family and team collaboration. CloudBase natively supports two layers:

Layer 1: role tiers (decides "who gets in, what they can touch")

Have the AI design the full role-and-permission scheme for your system; subdivide by project or team as needed.

Layer 2: row-level permissions (this is what makes "each person sees only their own" work)

Each role can have separate read/write scopes on the same data:

• me = read/write only rows they created

• all = read/write everyone's rows

A concrete example: the admin gets rw:all + rw:me — can edit everyone's data; a family member gets rw:me — reads and writes only their own, sees nobody else's; an outside guest gets r:all + rw:me — sees the shared info and can edit their own entry.

One workbench, multiple roles collaborating, each seeing their own, admin seeing all. The homework-tutoring scenario in a family lands exactly this way. For web/mini-program code you write yourself: use database security rules and judge "is this row mine" with doc._openid == auth.openid.

Either way, you never build an account system yourself.

3.3 Shareable links: anyone who opens them can read and write​

On a CloudBase-deployed site, data and pages are parts of the same application — no matter where it's opened from, reads and writes hit the same APIs.

Layer identity on top and you can do more:

• Anonymous mode: anyone who opens the link can submit an entry (customer feedback forms, event sign-ups)

• Write after login: when you need accountability, require phone or WeChat login

• Login + permissions: after login, roles decide how much is visible

Three levels, switched on demand — no rewriting code.

3.4 From workbench to full-stack app​

The workbench is the entry point; on the same CloudBase environment you can also grow:

From workbench to full-stack app there's no cliff — capabilities keep stacking on the same layer of data.

That's the real value of choosing the base wisely: what starts as a workbench grows into a complete product.

Official call for submissions​

The workbench keeps growing. Need media, family sharing without interference, links for outsiders to fill in, payments, or turning it into a mini program or app that compounds over time — upgrade with CloudBase in one click.

📮 We're collecting your workbenches on Xiaohongshu

If you've built a workbench on CloudBase — whether it just started running (your 0-to-1) or it's already wired up with cloud functions, storage, permissions, scheduled jobs, AI assistants, payments… we'd love your submission.

We want to see more real user cases:

• What problem your workbench solves

• Which CloudBase skills you used (functions / storage / permissions / scheduled jobs / AI / payments…)

• Pitfalls you hit and how you got around them

• What it looks like now

How to participate:

1. Search and follow "CloudBase 和它的朋友们" on Xiaohongshu

2. Post a note about your workbench with #CloudBase and @ the official account, or drop a screenshot under the official tutorial — you'll receive resource credits

3. We'll also pick cases to feature on official channels

Feel free to send over pitfalls and questions too — future case studies may start from your sharing. Forward this to friends who are also figuring out how to land a "workbench" 🐧

For building mini programs on your own, or vibe apps with your team, CloudBase is the place.

What's better than GLM 5.2?​

• Coding +50%: a 50% improvement over 5.2 on Z.ai Code Bench, and open-source leader on public benchmarks like Terminal Bench 3.0 and Agents' Last Exam
• Security upgrades: white-box code review and vulnerability discovery on par with Mythos 5
• CloudBase: ship right after writing, no separate AI account needed, switching models is just one parameter. Cloud database (with PostgreSQL support), cloud functions, domain filing and tokens all in the same plan — AI writes the code and you ship it.

Two ways to use AI​

1. Plug it into the AI dev tool you already use​

CloudBase console → AI → enable the text-generation model. Copy the Base URL and API Key, and plug the model into WorkBuddy, CodeBuddy or Codex as an ordinary OpenAI-compatible model.

2. Call it directly in a full-stack app​

When building a mini program, web app, official account or support bot, a few lines of SDK code give you streaming output — no separate backend needed.

Token usage is charged automatically from your resource points, visible in real time on the plan usage page.

Come try GLM 5.3 on CloudBase now.

Today, Tencent Cloud CloudBase officially supports PostgreSQL (commonly shortened to PG). As one of the most widely used open-source databases, PG is mature, standard in its usage, and a natural fit for agent operations. Once integrated with CloudBase, everything an AI needs when generating an app — creating tables, configuring permissions, generating APIs — can be done in one place.

CloudBase PG has been specially adapted on top of Tencent Cloud's database capabilities to match the new demands of agent-driven development, so the database can keep pace with the rapid, iterative rhythm of agent development. At the same time, CloudBase PG is highly compatible with Supabase, so developers already on Supabase can migrate at low cost.

Agents can read it: tables, permissions and APIs in one step​

PostgreSQL has a quality that suits agents perfectly: standard enough, and explicit enough.

Table structure, field constraints, database functions and permission policies can all be defined in standard SQL. An agent reads the schema and understands how data is stored, who can access it, and what it can do.

Take a collaborative document app as an example — with a few lines of SQL you complete data modeling, identity binding and permission control all at once.

In CloudBase, creating a table also lets you define the data structure, user identity and access permissions at the same time. Once the table is created, a RESTful API is generated automatically — CRUD works immediately, no separate server-side endpoints to develop.

More complex needs like full-text search, scheduled jobs and RAG semantic search can be done through database functions, transactions and capabilities like pgvector. The MCP Server, Agent Skills and plugin system CloudBase released earlier are also adapted for PG mode — from creating tables and configuring permissions to calling APIs, agents can not only read it, but do it themselves.

Agents can experiment freely: second-level cloning of TB-scale databases​

While developing an app, agents frequently need to modify table structure, adjust permission policies and try different query logic. Code can be changed freely — now the database can be "branched" freely too.

CloudBase PostgreSQL supports Database Branch. When an agent needs to try a new approach, it can clone an independent database environment, modify schema, functions and permission policies inside it, publish after validation succeeds, and drop the branch on failure without affecting production data.

Backing this is Tencent Cloud Database. On Tencent Cloud's self-developed underlying architecture, cloning a 1TB database shrinks from hours to seconds, so every agent experiment can quickly get a database environment with the same structure as production, yet isolated.

Agents on demand: second-level creation, no idle resource waste​

The number of apps an agent generates and the frequency of calls aren't fixed, so the database also needs to start, stop and scale flexibly with the app.

CloudBase PostgreSQL cuts database environment creation from minutes to seconds. When an agent generates a new app, the database keeps up, with no need to wait for a traditional database instance to finish creation and initialization.

When the app goes idle, the system automatically suspends compute resources while keeping data, permission policies and APIs intact, and recovers quickly when requests return. When load surges, compute resources scale up quickly — available the moment you need them, not occupying resources when you don't.

This capability is already running stably on Tencent's own agents:

• CloudBase connects to the WorkBuddy connector — once connected, users can use CloudBase directly as their app's database and backend.

• Tusi, built on CloudBase, lets users complete app development and deployment from a prompt, with generated apps automatically getting an independent database, data isolation and an account system.

Already on Supabase? Migration is almost code-free​

CloudBase PG is highly compatible with Supabase. The two are largely aligned in database, user authentication, permissions and interfaces, so most projects can migrate with only minor changes — a seamless move.

Your AI app's front end is already polished. Come pair it with a solid backend on Tencent Cloud CloudBase.

Tusi is an "app generation and idea co-creation platform" from the Tencent App Store team. Users type any prompt, AI handles development, deployment and launch, and produces an app they can download and install directly.

Once you serve thousands of users and generate thousands of apps, the backend becomes the real bottleneck. A downloadable, installable app is backed by a full backend stack — database, login, storage, hosting. If every generated app required the agent to rewrite the DDL, reconfigure Nginx and re-stand-up a login system, generation would slow down and break, and the platform would have to keep patching things at the application layer. With CloudBase, the platform gets:

• Every user-generated app automatically receives an independent cloud database instance, with data isolated at the tenant level by nature
• Built-in WeChat, phone number, email and anonymous login — apps carry an account system from the very first line of code
• Database, cloud functions, cloud storage, static hosting and container hosting all wrapped as MCP, invoked declaratively by the agent
• Generation and runtime share the same data path

Multi-tenant data isolation​

Every user-generated app that involves a backend automatically creates an independent cloud database instance, with data isolated at the tenant level by nature — the platform doesn't need to write multi-tenant logic again at the application layer.

During generation, the agent can declare data models and write test data directly through MCP; after launch, real users' business data lands in the same database — generation and runtime share one data path, with no "one database at generation, migrate again after launch" seam.

Authentication​

Identity is another easily overlooked cost. If the agent is asked to write OAuth and session management on the fly in the prompt, it's neither stable nor reusable.

CloudBase has WeChat, phone number, email and anonymous login built in. Apps generated by Tusi can "log in, identify users and distinguish data ownership" by default. Users don't need to explicitly ask for "a login system" in the prompt, and the agent doesn't need to write OAuth/session management from scratch — identity is a platform default, so apps carry an account system from line one and can support account-heavy features like favorites, personal space and social sharing right away.

MCP/Skills: a shorter agent loop​

What really determines generation quality is how many low-level details the agent has to handle.

CloudBase wraps backend resources — database, cloud functions, cloud storage, static hosting, container hosting — into standard MCP tools, and has distilled a batch of reusable Skills for common scenarios (user system, content storage, AI calls, payments, etc.). When generating an app, Tusi's agent doesn't write DDL, configure Nginx or manage HTTPS certificates — it calls MCP declaratively, and CloudBase handles resource creation, config publishing and runtime maintenance. This shortens the agent loop noticeably, shrinks the error surface, and gives generated apps production-grade engineering quality from launch.

With these three layers combined, a platform can use the agent to declaratively obtain a full set of production-grade capabilities by default. Click "Read more" for the complete solution.

About Tusi​

Tusi is an app generation and idea co-creation platform from the Tencent App Store team. Users type prompts, AI handles development, deployment and launch, and produces a downloadable, installable app. The backend runs primarily on CloudBase.

Try it: https://tusi.qq.com

• Session history and compression
• Disconnection and reconnection
• Sandbox integration
• MCP/Skills integration
• Human in the Loop
• Multi-turn model loops
• ……

Only a small fraction of the code is actually related to the developer's own business; 70% of the work goes into these low-level details.

This is much like web development's "slash-and-burn" era: every team repeated the wheel from routing, ORM and session management, until full-stack frameworks like Django and Rails standardized the infrastructure and developers' energy finally returned to business logic.

Agent development now stands at that same dividing line. Although code is still the main way to build agents, developers clearly no longer need to hand-write session persistence and tool orchestration.

To solve these agent-developer pain points, we're pleased to release OpenAgentKernel:

• GitHub: https://github.com/TencentCloudBase/OpenAgentKernel
• CNB: https://cnb.cool/tencent/cloud/cloudbase/OpenAgentKernel

This is an agent framework natively built for CloudBase, with session persistence, tool orchestration and human-in-the-loop (HITL) built in, letting developers focus on business logic instead of infrastructure details.

Try it now​

npm install @cloudbase/open-agent-kernel@beta

Prerequisites: Node.js 22+, a CloudBase environment's envId, and the environment's server-side API Key.

Minimal example: understand the core API in thirty seconds​

import { createAgent } from "@cloudbase/open-agent-kernel";

process.env.TCB_API_KEY = "your-cloudbase-api-key";

// Create an agent
const agent = createAgent({
  envId: "your-env-id",
  model: "deepseek-v4-pro",
  systemPrompt: "你是一个智能助手，请帮我回答用户的问题",
});

// Create a session
const session = await agent.startSession({ userId: "user-1" });

// Send a message and receive the response
for await (const event of session.send("一句话解释：什么是 Serverless？")) {
  if (event.type === "message_delta") process.stdout.write(event.text);
  if (event.type === "session_idle") break; // this turn ends
}

You can easily deploy the code above to a CloudBase HTTP cloud function and test it with curl or Postman.

Features​

1. Session persistence and cross-process recovery​

Session records persist to the cloud development database by default, not process memory.

const agent = createAgent({
  envId: "your-env-id",
  model: "deepseek-v4-pro",
  systemPrompt: "你是一个智能助手，请帮我回答用户的问题",
});

const session = await agent.startSession({ userId: "user-1" });
const conversationId = session.id;

In another process later (say, a second function invocation), use conversationId to restore the conversation context directly:

const resumed = await agent.resumeSession(conversationId);

2. MCP integration​

MCP integration is nearly a must in agent development, so we built in several ways: in-process, local stdio, remote HTTP.

import { createSdkMcpServer, tool } from "@anthropic-ai/claude-agent-sdk";
import { z } from "zod";

// In-process MCP
const localMCPServer = createSdkMcpServer({
  name: "calc",
  version: "1.0.0",
  tools: [
    tool(
      "add",
      "Add two numbers",
      { a: z.number(), b: z.number() },
      async (args) => ({
        content: [{ type: "text", text: String(args.a + args.b) }],
      }),
    ),
  ],
});

// Local stdio MCP
const stdioMCPServer = {
  type: "stdio",
  command: "npx",
  args: ["-y", "@modelcontextprotocol/server-everything"],
};

// Remote HTTP MCP
const remoteMCPServer = {
  type: "http",
  url: "https://example.com/mcp/v1",
  headers: { Authorization: "Bearer xxx" },
};

const agent = createAgent({
  envId,
  model: "glm-5.2",
  systemPrompt: "你是一个智能助手，请帮我回答用户的问题",
  mcpServers: {
    local: localMCPServer,
    stdio: stdioMCPServer,
    remote: remoteMCPServer,
  },
});

3. Human in the Loop (HITL)​

For sensitive agent operations (deleting a database, setting a password, etc.), we usually need the user's confirmation before the agent continues.

const agent = createAgent({
  envId,
  model: "glm-5.2",
  systemPrompt: "你是一个智能助手，请帮我回答用户的问题",

  // Configure which tools need human approval
  permissions: {
    requireApproval: ["database_delete", "reset_password"],
  },
});

Once configured, if the agent hits a tool requiring approval during a task, the response event stream triggers a tool_approval_required event. Developers can build the human-confirmation UI on top of it:

const session = await agent.startSession({ userId: "user-1" });

for await (const event of session.send("帮我删除 todo_list 这个数据表")) {
  if (event.type === "tool_approval_required") {
    // implement the confirmation UI; get event.toolUseId and call session.respondApproval()
  }
}

4. Agent memory​

Memory is now a built-in capability for most agents. In OpenAgentKernel, we built it in:

const agent = createAgent({
  envId,
  model: "glm-5.2",
  systemPrompt: "你是一个智能助手，请帮我回答用户的问题",
  // enable memory
  userMemory: true,
});

The user's private .claude/ memory files sync automatically to CloudBase cloud storage and take effect across sessions.

Developers can also proactively call APIs to preset or delete memory:

import { writeUserMemoryFiles } from "@cloudbase/open-agent-kernel";

await writeUserMemoryFiles({
  envId,
  userId: "alice",
  files: [{ path: "CLAUDE.md", content: "请始终用中文回答。" }],
});

5. Sandbox: run code and touch files safely​

Agents running code, changing files and executing shells need an isolated execution environment. So we built sandbox support into OpenAgentKernel:

const agent = createAgent({
  envId,
  model: "glm-5.2",
  systemPrompt: "你是一个全能编程助手，帮助用户编写代码",
  // enable Sandbox
  sandbox: {
    enabled: true,
    cloudbaseTools: true, // when the image supports it, CloudBase MCP tools can be called inside the sandbox
    scope: "shared", // shared: shared instance across sessions; session: independent instance per session
    ttl: 3600,
  },
});

With the sandbox on, the agent executes code and reads/writes files inside it. For example, generating a web page and previewing it:

const session = await agent.startSession({ userId: "user-1" });
session.send(
  "帮我写一个个人博客的首页，用 React + Tailwind CSS，然后部署到 CloudBase 上"
);

The agent then creates files, installs dependencies and uses the CloudBase credentials built into the sandbox to deploy the artifact to the cloud — the developer doesn't manage or schedule the sandbox.

CloudBase's Sandbox capability is in internal beta; contact us if you need it.

How we use OpenAgentKernel ourselves​

Most of CloudBase's AI features are now built on OpenAgentKernel, including:

CloudBase Agent​

The Agent section of the CloudBase console was rebuilt on OpenAgentKernel: when creating a new agent, choosing the official cloudbase-agent template gives you an OpenAgentKernel project — session persistence, MCP tools and human approval out of the box. Once created, you can chat directly on the "Connect & debug" page.

For deep customization, the "Local development" page gives full guidance: tcb fn code download pulls the code locally for your AI coding tool to modify, then tcb fn deploy deploys it back with one command. The console handles hosting, logs and debug entry; OpenAgentKernel handles the runtime.

Issue Agent​

The CloudBase community's (CNB) Issue Bot is an OpenAgentKernel agent running in a pipeline. When a new issue arrives, it researches materials in the role of a "cloud development engineer" and gives grounded answers.

It uses three OpenAgentKernel capabilities: an in-process MCP server provides controlled tools, final answers must be published through the reply tool, mechanically guaranteeing "either evidence-based or explicitly marked as inference"; skills load answering experience (issue-agent-guide); multimodal attachments let it read error screenshots users paste — screenshots are first recognized one by one in a vision session, then enter the main flow.

Use OpenAgentKernel now​

npm install @cloudbase/open-agent-kernel@beta

Or view the code at:

• GitHub: https://github.com/TencentCloudBase/OpenAgentKernel
• CNB: https://cnb.cool/tencent/cloud/cloudbase/OpenAgentKernel

Or open the Agent section of the CloudBase console (https://tcb.cloud.tencent.com/dev) directly to start your agent development journey:

• npm: https://www.npmjs.com/package/@cloudbase/open-agent-kernel
• Source and README: https://github.com/TencentCloudBase/OpenAgentKernel
• Agent development docs: https://docs.cloudbase.net/ai/agent-development/

Follow Tencent Cloud Development for product updates and best practices.

Install one plugin in ZCode and you can operate your entire CloudBase backend in natural language — create databases, write functions, deploy sites, manage storage and authentication — without ever switching back to the cloud console.

Works out of the box​

Download and open ZCode, go to "Settings" → "Plugins" in the left menu, switch to the "Developer tools" category, find cloudbase-skills (Tencent Cloud CloudBase development skills and MCP integration), and click "Install" on the right.

After installing, go back to the AI chat and start. A few ready-to-use prompts:

• "Build a WeChat mini program food-ordering system with cloud development" — set up pages, create the cloud database, write cloud functions and guide the preview.
• "Build a booking management system with user ordering and backend status changes" — model with CloudBase PostgreSQL, configure permissions, and wire up front end and back end.
• "Add phone-number login to a web app" — enable the auth method and integrate the CloudBase SDK.

Get started now​

The CloudBase plugin is available for ZCode 3.4.1 and above, covering all CloudBase environments. Click "Read more" for the full integration guide.

ZCode download: https://zcode.z.ai

That's a normal day with the CloudBase plugin installed. Codex, Claude Code, and WorkBuddy all support CloudBase Plugin natively: database, cloud functions, static hosting, and AI capabilities, all one sentence away in chat.

Getting in: it's a prompt​

The recommended path is prompt-based. Copy this into your AI IDE and hit enter:

Set up CloudBase for me:
1. Open https://docs.cloudbase.net/skill.md and follow the instructions to connect.
2. When done, tell me and suggest the most relevant next step.

The AI handles installation and configuration itself — and tells you what to do next when it's done. Stuck? Ask it to teach you. Misconfigured? Ask it to fix it.

Prefer the terminal? One command​

npx plugins add TencentCloudBase/cloudbase-plugin -y --scope user

The plugins CLI (Open Plugin Specification compatible) auto-detects every AI tool on your machine and sets them all up. Prefer this path — don't hand-write MCP JSON. Check detection anytime:

npx plugins targets

What your AI can do after that​

The plugin bundles three things:

• MCP Server — "how many docs are in the users collection?" or "make this function run every minute" — executed right in chat
• Agent Skills — CloudBase best practices injected into the agent's skill library, so it knows instead of guessing
• Hooks — more reliable Skill activation, no flakiness

Compared to installing Skills alone, the plugin adds Hooks and activates more reliably — every integration should go through the plugin.

Supported AI IDEs​

There's also an optional Sites plugin (npx plugins add TencentCloudBase/cloudbase-sites-plugin -y --scope user).

Full docs: CloudBase AI Plugins.

Next time you deploy, try leaving the console closed.

Renewal path: complete the task, renew 6 months for free​

STEP 1: Publish CloudBase / cloud development content on any platform: Xiaohongshu, Juejin, Zhihu, CSDN, Bilibili, X (Twitter), V2EX, Jike.

Click "Complete" → pick a platform in the popup → download the asset pack → copy the recommended copy (multiple templates). Official reference assets are provided.

STEP 2: Paste your share link and upload a screenshot.

Click "Submit for verification" → Hunyuan AI verifies automatically → click "Renew now" after passing.

Enter the ¥0 purchase page and click "Buy now" to complete the renewal.

Upgrade path: upgrade directly with a 4.9-yuan Personal plan first-purchase offer​

Select "Upgrade now", enter the purchase page, click "Buy now" to complete the upgrade.

Note: this first-purchase upgrade offer is a price-only promotion. All environments upgraded to the Personal plan cannot be downgraded back to the Free Trial.

There's also a prize survey running at the same time — it only takes 2 minutes, and participants can enter a lucky draw with random resource-point bonuses.

Share your thoughts and expectations about CloudBase in the comments.

Details: https://cloud.tencent.com/developer/article/2715255

If your product is serving (or about to serve) Southeast Asian users, you've probably run into these:

• Servers deployed domestically, with obvious latency for users in Singapore, Malaysia and Indonesia — a degraded experience;
• Data-export compliance requirements getting more detailed, and "can the data stay local" becoming an unavoidable question;
• Wanting to validate an overseas business quickly, but not wanting to set up a whole new account system or learn a new cloud product just for a new region.

Now there's no need to start from scratch: CloudBase has officially opened the Singapore region on the domestic site, and developers keep using the domestic account and console while deploying backend services nearby in the Singapore data center.

Singapore region fully open, PostgreSQL exclusively​

Domestic-site users can now select the "Singapore" region when creating a CloudBase environment. The Singapore region exclusively provisions PostgreSQL (PG) database environments.

1. Singapore region fully open​

This release removes the whitelist restriction for the Singapore region and opens it to all users. Just select "Singapore" in the region selector on the purchase page — operation is exactly the same as the Shanghai region, no extra application, no switching to the international site.

2. Singapore ships PostgreSQL exclusively​

The Singapore region only provides PostgreSQL database environments, and doesn't support document databases / MySQL for now.

CloudBase for Supabase is the serverless backend cloud service CloudBase built on top of PostgreSQL, aligned with the industry-mainstream PG-first backend approach (fully Supabase-compatible), unifying database, permissions, authentication and storage into one SQL language system:

5 concrete benefits of the Singapore region​

1. Deploy nearby, faster access in Southeast Asia​

The data center physically sits in Singapore. Serving users in Singapore, Malaysia, Thailand and Indonesia, network paths are shorter and API responses faster — a clear upgrade for latency-sensitive scenarios (social, e-commerce, utility apps).

2. Data stays put, compliance easier​

Domestic nodes only load domestic-site data; the Singapore region handles site-data loading per compliance policy, isolated at the architecture level to satisfy "data localization" and "regional compliance" requirements.

3. Same account, no international-site signup​

Still the domestic account, domestic payment methods, domestic console — no international-site registration, no language switching. Pick a region and you get an overseas node. Dev habits, CLI tools and SDK usage stay basically unchanged.

4. One SQL for data, permissions, accounts and storage​

Traditional backends split database, auth service and file storage into three systems with three permission languages, raising integration and maintenance costs. CloudBase for Supabase converges them into one PostgreSQL system:

• How business data is stored → create a table;
• Who can read, who can write → GRANT + RLS Policy;
• Who the user is → a table in the auth schema;
• How file permissions work → still RLS Policy.

For developers, mastering SQL covers most of data modeling, permission design and cross-module collaboration.

5. Zero ops​

Database instance creation, high availability and backup are all platform-managed. Developers don't touch machine specs, scaling or patching; after creating the environment, you create tables and write code right away.

Choosing the "Singapore" region​

The whole flow is identical to the CloudBase purchase flow you know, plus one "pick a region" step:

Step 1: Enter the purchase page and select the Singapore region

Open the CloudBase purchase page and select "Singapore" in the region selector — once selected, the database type locks to PostgreSQL automatically (the Singapore region offers no other database type).

Step 2: Pick a plan, place the order and pay

Choose a plan (Personal / Standard / Enterprise) and go through the standard order and payment, same as the Shanghai region.

Step 3: Automatic environment initialization

After the order, the system automatically:

1. Creates the CloudBase environment;
2. Creates the PostgreSQL database instance;
3. Initializes system roles and default permissions;
4. Configures the API service gateway.

Usually done in minutes, no manual intervention.

Step 4: Enter the console

Once the environment is created, go straight into the PG console to use table management, RLS policy config, connection-info viewing, cloud functions, cloud storage, static hosting and authentication.

Step 5: Connect from code, a few lines

For a web front end, connect to the database directly via SDK, with permissions auto-checked by RLS:

import cloudbase from '@cloudbase/js-sdk';

const app = cloudbase.init({
  env: '<environment ID>',
  accessKey: '<Publishable Key>',
});

const db = app.rdb();

const { data } = await db
  .from('todos')
  .select('id, title, is_completed')
  .eq('is_completed', false);

await db.from('todos').insert({ title: '写一篇出海文档' });

If you don't use the front-end SDK, you can use the standard REST API (PostgREST spec) from any language or backend framework:

curl "https://<envId>.api.tcloudbasegateway.com/v1/rdb/rest/todos?is_completed=eq.false" \
  -H "Authorization: Bearer <Publishable Key>"

For complete table creation, permission config (GRANT + RLS) and advanced usage, see the official docs: PostgreSQL database initialization guide.

A few questions you might ask​

Q: Can the Singapore and Shanghai regions coexist?

Yes. Region is an environment-level choice; one account can hold both Shanghai and Singapore environments, created, managed and billed independently per business need.

Q: Will Singapore support cloud database (MySQL / document database) later?

The Singapore region is PG-exclusive for now, focused on doing PostgreSQL deeply. Any plans for other database types will be announced separately.

Q: Already on a Shanghai-region PG environment — can I migrate code to Singapore directly?

Yes. Singapore and Shanghai share the same PostgreSQL stack, SDK and API specs; business code needs almost no changes, just point to the new environment's env at initialization.

Q: How are data security and isolation guaranteed?

The Singapore region is fully isolated at the network layer from domestic regions, following the platform's data-flow isolation and compliance policies — no domestic node accesses overseas data, or vice versa.

Q: Singapore doesn't support Cloud Run — what about existing backends on Cloud Run?

The Singapore region doesn't provide Cloud Run for now, but standard cloud functions (including HTTP triggers) are fully available. We recommend moving lightweight backend logic to web cloud functions — expose them as standard REST APIs through the HTTP gateway. Compared with Cloud Run, web cloud functions have clear advantages in the Singapore scenario:

• Zero ops, no container management: no image builds, no instance specs — upload code and it runs;
• Pay-as-you-go, zero idle cost: billed by call count + resource usage time, no charge when there are no requests, no reserved instances needed to avoid cold starts;
• Easier autoscaling: the platform scales by concurrency automatically, and pre-provisioned concurrency further reduces cold-start impact;
• Seamless PG integration: cloud functions read/write the same environment's PostgreSQL directly and reuse the RLS permission system — no extra network wiring for data validation, third-party integration or scheduled jobs.

Note: if your business depends on long connections (WebSocket/SSE), persistent processes or full web-framework routing middleware, cloud functions aren't a complete Cloud Run replacement — watch for Cloud Run's future Singapore opening for those cases.

Closing​

Going overseas no longer requires building a whole overseas infrastructure before you start. Pick a region, go through the familiar purchase flow, and a few minutes later you have a ready-to-use serverless PostgreSQL backend deployed in Singapore.

If your business is reaching (or already reaching) Southeast Asian users, now is a good time — check the Singapore region in the console, click "Read more" for the purchase page, and create your first table.

Learn more:

• PostgreSQL database initialization docs: https://docs.cloudbase.net/database/configuration/db/postgresql/initialization

This tutorial walks you step by step through custom domains and ICP filing — how to wire it up from filing to verification.

Entry points everywhere: static hosting, cloud functions and Cloud Run all support binding​

CloudBase now gives static hosting, cloud functions and Cloud Run each their own domain-binding entry, so you don't jump around after binding. The HTTP gateway also supports a unified view of all bindings.

Pick the mode you need: static hosting offers "app mode" (one domain per site) and "path mode" (multiple resources under one domain); for cloud functions and Cloud Run, fill in a "trigger path" when binding.

Choose one of three access types (static hosting recommends CloudBase CDN; API services generally don't select it).

More stable production, more unified brand, and filing without a server​

Default domains are for testing; your own domain is for production​

The default domain (like xxx.tcloudbaseapp.com) is officially recommended for testing only. Once you bind your own domain for external business, your brand is more unified, search engine indexing is more stable, and shared links get higher click-through.

Two more practical scenarios: one CloudBase environment running multiple sites (official site, blog, campaign page) distinguished by different custom domains; and exposing cloud functions / Cloud Run APIs under a brand domain + custom path, which is far cleaner than throwing out the default domain.

Filing isn't just a formality: your CloudBase environment can handle it​

A custom domain serving mainland-China traffic must have completed ICP filing — otherwise it can't be bound in CloudBase, and won't resolve. For developers, filing's value isn't just "compliance":

• CloudBase environments support filing: no need to buy a separate server just to file. Save an expense, and one less machine to maintain.
• Filing is the precondition for binding and serving: once you have the filing number, the domain can be bound in CloudBase and serve traffic.
• Up to 2 websites can be filed per environment: a qualifying environment can apply for filing service codes for multiple sites, enough for multi-site scenarios.
• Domains already filed elsewhere need "transfer-in": if the domain was filed with another provider, it can't be bound directly to CloudBase — the system will block it or flag it as unfiled. You need "new access filing (filing transfer-in)" first, attaching the filing info to Tencent Cloud before binding.

From filing to launch: three steps to wire up a custom domain​

Precondition one: ICP filing​

Filing within CloudBase requires three conditions at once:

• Plan version: Personal or higher (free trial environments don't support filing)
• Remaining validity: the environment has > 6 months remaining
• Fixed IP: the environment has "Cloud Run fixed IP" enabled

Once conditions are met, go to the "Filing management" page of the environment in the console, click "File now", and the system guides you to the Tencent Cloud filing console to pull the environment and submit the application.

The regulator's review usually takes 1–20 working days; you get the filing number on approval.

Precondition two: SSL certificate​

Prepare an SSL certificate, upload it in the SSL certificate console, and select it when binding the domain to enable HTTPS.

The overall flow in three phases​

The whole process is three steps: add the domain in the console → add a resolution record at your DNS provider → come back and verify it's effective.

Below, using the most common "static hosting + app mode + CloudBase CDN" as an example, we bind an official-site domain www.your-brand.com.

Phase one: add the domain in the console​

Step 1 · Confirm prerequisites: before starting, prepare three things — the domain has completed ICP filing (if not, file within CloudBase per the section above); the SSL certificate is uploaded; static hosting is set up in the environment with site files uploaded.

Step 2 · Open the static hosting detail page: CloudBase console → select the target environment → left menu "Static website hosting" → click into the app deployment list → click the app name to open its detail page.

Step 3 · Open the custom domain entry: find "Custom domain" (a tab or button) on the detail page and click "Add custom domain".

Step 4 · Fill in the four config items: fill them in and submit. This only demonstrates the CloudBase CDN path; for the custom CDN config flow, click "Read more".

Step 5 · Wait for association, copy the CNAME value: after submission, the platform needs 3–5 minutes to complete domain association. Once done, the console gives you a CNAME record value (like xxx.tcloudbaseapp.com); click "Copy" — this step is the key to the whole flow, and the next phase depends on it.

Phase two: add a resolution record at your DNS provider​

Step 6 · Add a CNAME record: sign in to the DNS provider where your domain lives (DNSPod, etc.), open the domain's resolution page, and click "Add record".

The most common pitfall: under the same host record, CNAME conflicts with other record types (A, TXT, etc.). If saving prompts "record conflict", delete the existing other records under that host record first, then add the CNAME.

Phase three: verify it's effective​

Step 7 · Confirm resolution is effective: DNS usually takes 5–30 minutes. You can check with:

nslookup your-custom-domain

If the result shows the CNAME domain CloudBase provided, resolution is live.

Step 8 · Check status in the console and verify in the browser: back in the CloudBase console, wait for the domain status to become "normal / effective" (refresh the page if not updated). Then open https://www.your-brand.com in a browser — if you see the site, over HTTPS, the binding succeeded.

How to bind cloud functions / Cloud Run​

The flow is identical (add domain in console → add CNAME in DNS → verify), with two differences:

• Fill in an extra trigger path: besides the domain, you fill in a trigger path when binding. Cloud functions often use /api or /; Cloud Run fills it per the service route. One function/service can bind multiple domains, each with a different path.
• CDN is usually "not used": API services generally don't need CDN acceleration — select "don't use CDN" (choose CloudBase CDN only if you need static-resource acceleration).

Entries:

• Cloud functions → function management → cloud function list → function detail page → custom domain
• Cloud Run → service management → service list → service detail page → custom domain

Multi-domain management and unbinding​

When one resource binds multiple domains, the list shows them more clearly, with one-click CNAME copy, jump-to-resolution and unbind.

To see all binding relationships in one place, go to HTTP gateway → domain-associated resources. HTTP gateway supports two forms (app/file) for static hosting resources.

Each environment supports up to 50 custom domains (Enterprise max) — watch the quota.

Closing​

CloudBase has compressed the custom-domain chain to three steps: file the environment, add the domain in the console, and verify.

If you haven't yet put your site on your own domain, come try it. Whatever step trips you up, or whatever domain capability you'd like CloudBase to add, share it in the comments.

Why it's worth using​

• Fast: one command pulls real-time metrics for cloud functions / database / Cloud Run and 12 resource types in total — no more clicking through console layers.
• Scriptable: commands drop straight into scripts, scheduled inspections and CI pipelines, with anomalies broadcast automatically.
• Safety net: out-of-bound metrics trigger automatic alerts, so quality risks reach you proactively instead of waiting for user complaints.

1. Monitoring queries (tcb monitor) — resource health at a glance​

A unified entry point covering cloud functions / database / MySQL / Cloud Run / static hosting / authentication / LLM / knowledge base / gateway / login / DB Connector / environment QPS — 12 resource types.

Typical scenarios

• Troubleshooting: function errors, sudden latency spikes? Pull the error count and latency curves in one go.
• Inspection / weekly reports: --json output feeds straight into scripts to generate resource-level reports automatically.
• Free time window: --last 7d / --last 24h to look back, with precise metric names.

# error count for a function over the last 7 days
tcb monitor function --name helloWorld --metric-name FunctionError --last 7d

# latency over the last 24 hours, structured output for scripts
tcb monitor function --name helloWorld --metric-name FunctionDuration --last 24h --json

Common parameters:

• Relative time window: --last 7d / --last 24h
• Precise metric: --metric-name FunctionError
• Structured output: --json (for script consumption)
• Metric list: tcb monitor schema <resource-type>

2. Alert policies (tcb api monitor) — let risks find you​

Scenario: alert on function errors. When any cloud function version reports errors, push a notification to WeCom / email / SMS immediately — a safety net for production quality.

tcb api monitor CreateAlarmPolicy --api-version 2018-07-24 --body '{
  "Module": "monitor",
  "PolicyName": "云函数版本错误数告警",
  "MonitorType": "MT_QCE",
  "Namespace": "SCF",
  "ProjectId": 0,
  "Enable": 1,
  "Condition": {
    "IsUnionRule": 1,
    "Rules": [
      { "MetricName": "Error", "Period": 60, "Operator": "gt",
        "Value": "0", "ContinuePeriod": 1, "NoticeFrequency": 3600, "IsPowerNotice": 0 }
    ]
  },
  "NoticeIds": ["notice-xxxxxxxx"]
}'

Key points:

• Creating it covers all function versions under that namespace — no per-instance binding.
• It returns a PolicyId you can use later to delete or bind to specific instances precisely.
• NoticeIds is the notification template ID; remove the line if you don't need it.

3. Upgrade to a supported version​

npm i -g @cloudbase/cli@latest
tcb -v   # confirm ≥ 3.5.8

Reference docs​

• Monitoring: https://docs.cloudbase.net/cli-v1/monitor/management
• Alerting: https://docs.cloudbase.net/cli-v1/monitor/alert
• Observability platform API: https://cloud.tencent.com/document/api/248/87588

At WAIC 2026, Wang Weijia, product lead of Tencent Cloud CloudBase, shared a judgment: in the agent era, the cloud's value isn't just providing resources — it must become a software production line suited to how agents work.

In the past, the cloud mainly served professional developers. Writing code, configuring environments, connecting databases, deploying, troubleshooting — every step depended on manual effort.

Today, more and more "super individuals" are emerging: they don't have to complete every engineering task themselves. Instead, they define goals, orchestrate agents, and use a set of cloud infrastructure to turn ideas into real, runnable, deliverable applications.

That means the cloud needs to be redesigned.

The software producer has changed, so the infrastructure must change too​

From Lovable and Vercel v0 to Replit Agent, vibe coding has moved from a tech demo to a scaled product.

But the crux of this competition is no longer "who generates prettier pages" or "whose code generation is faster". The real challenge is whether agents can string together code, data, identity, storage, deployment and operations to deliver a genuinely usable application.

Code generation is getting faster, but integrating real systems is still complex.

How do you create a database? Wire up authentication? Store files? Configure permissions? Locate and roll back after a failed release? These capabilities were mostly designed for humans — operate through a console, understand through docs, debug through vague error messages.

For an agent, these steps generate a large amount of "infrastructure noise".

So the second half of AI programming isn't just about making agents smarter — it's about making their working environment clearer, more readable, more executable and more verifiable.

From prompt to loop: getting agents into real production​

Getting an agent to generate code once isn't hard. Getting it to complete tasks reliably in a real production environment is the bigger engineering challenge.

This requires understanding agent engineering across four layers:

• Prompt Engineering: solving "how to ask";
• Context Engineering: solving "what the agent should know";
• Harness Engineering: solving "how to constrain the agent";
• Loop Engineering: solving "how to keep the agent running autonomously".

Of these, Loop Engineering closes the full loop on a task: trigger, goal, action, verification, memory. An agent no longer just answers questions — it advances continuously around a goal and corrects itself based on environment feedback.

Harness Engineering adds production-grade guardrails to this loop: architecture boundaries, least privilege, tests, type checks, CI, log auditing, and necessary human approval.

Both point to one principle: every agent action should get feedback in a real runtime environment, and iterate on that feedback.

The agent era needs an AI-native cloud​

A traditional cloud platform's core interaction subject is human: the console is for humans to operate, the docs are for humans to read, the errors are for humans to debug.

An AI-native cloud's core interaction subject is the agent. It must provide standardized tool calls, structured context, machine-readable errors, secure sandboxes, serverless resources and observable feedback.

In other words, the cloud is shifting from a "human-machine interface" into an agent's working environment.

For an agent, a suitable cloud should have four traits:

• Readable: let the agent understand resources, configuration, permissions and state;
• Executable: let the agent operate cloud resources through standard tools;
• Verifiable: let the agent check results, locate problems and keep correcting;
• Controllable: keep automation within bounds through sandboxes, permissions and auditing.

CloudBase: making cloud capability the agent's language​

Around the AI-native cloud, CloudBase is reorganizing serverless, BaaS, hosting, multi-tenancy, permissions and billing into infrastructure better suited for agent invocation.

For developers, CloudBase lowers the barrier to operating cloud resources through MCP, Skills and Plugins.

CloudBase MCP wraps database, authentication, storage, cloud functions, logs, domain, security, deployment and rollback into tools callable through standard protocols. Agents can understand and operate cloud capabilities directly, without jumping around complex console flows.

CloudBase Skills distills mini program development, authentication, WeChat Pay, database calls, cloud function authoring, LLM orchestration and permission control into domain knowledge agents can call.

Through Plugins in coding environments like Claude Code and Codex, developers can use these capabilities directly in their daily workflow.

The goal is clear: shorten the agent's execution loop, cut wasted tool calls and token consumption, and let the agent shift its attention from operational details back to business goals.

In a controlled test generating and deploying a Todo app, compared with the traditional VM approach, CloudBase cut completion time from 990 seconds to 260 seconds, tool calls from 79 to 36, and token consumption by 52%. At the same time, the security exposure surface narrowed from SSH to HTTPS API.

Infrastructure adapted to agents brings not just faster delivery, but a shorter, more stable, more secure production loop.

From developer efficiency to vibe-coding platform capability​

The agent era's challenges aren't limited to individual developers.

When a vibe-coding platform offers "generate an app" to a large number of users, multi-tenant isolation, permission management, resource quotas, lifecycle, cost accounting and runtime safety all become foundational questions for whether the platform can scale.

If these capabilities are patched together ad hoc at the application layer, the platform quickly spirals into complexity and cost.

CloudBase's approach is to push these capabilities down to the infrastructure layer:

• Give each user or project an independent environment;
• Isolate the control plane from the runtime with sandboxes;
• Support elastic scaling and pay-as-you-go with serverless;
• Complete resource quotas, cost accounting, runtime monitoring, backup and teardown at the tenant level.

This makes "user-generated apps" more than a one-off code output — they become isolated, operable, billable, continuously evolving cloud resources.

On CloudBase, a batch of such products has already grown: Tencent Tusi lets users generate installable apps with a single sentence; WorkBuddy helps product managers, founders and independent developers produce deliverable full-stack projects. They look like different products on the surface, but fundamentally they're all pushing the same thing: letting one person orchestrate agents and cloud infrastructure to complete a software production process that once required a small team.

The cloud is becoming the agent's production line​

The biggest change the electricity revolution brought wasn't swapping steam engines for electric motors — it was redesigning the entire production line around electricity.

The same is true of AI.

If you just drop agents into the traditional cloud console and ops workflow, the efficiency gains are easily cancelled out by environment noise. The real opportunity lies in reconstructing the cloud around how agents work: tools callable, context understandable, permissions controllable, results verifiable, resources elastically provisioned.

In the future, the cloud will no longer be just a platform where engineers rent resources.

It will become the production line where agents generate, run, verify, publish and maintain software.

And the meaning of the "super individual" isn't one person doing everything — it's one person orchestrating a set of agents and a full stack of cloud infrastructure to turn their ideas into real-world products and services quickly.

Redesigning the cloud for the super individual is redesigning software productivity for the agent era.

Want an agent to run this production line for you? Click "Read more" to get started.

What Kimi K3 + CloudBase is good for​

Kimi K3 took first place globally on the Code Arena frontend coding blind test (1679 points, beating Claude Fable 5 and GPT-5.6 Sol), with native vision understanding and a million-token context.

Kimi K3 excels at frontend programming and interactive apps, with long-range coding capability — it can sustain long-running tasks and understand and process large codebases. It also supports iterating on tasks with screenshots and visual feedback, making it a fit for frontend, game development and other scenarios that need vision understanding combined with code.

Leveraging its context and agent capabilities, Kimi K3 + CloudBase can integrate information from large volumes of web pages, PDFs, papers and data in industry research, scientific analysis, data processing and visualization tasks, and produce reports, charts and interactive content.

The backend for these apps — database, cloud functions, cloud storage — all live in the same plan, no platform switching needed.

Not just Kimi K3​

CloudBase AI models currently support:

• Kimi series: K3, Kimi-K2.7-code, Kimi-K2.7-code-highspeed
• GLM series: GLM 5.2, GLM 5.1, GLM-5, GLM-5-Turbo
• DeepSeek: V4-Pro, V4-Flash
• MiniMax: M3, M2.7, M2.5
• Hunyuan series: Hy3, Hy3 preview
• Qwen3.5: qwen3.5-flash, qwen3.5-plus

Pricing matches the vendors, the calling method is the same, and switching models is just one parameter — no SDK change, no credential swap. For the full price list, click "Read more" for the resource-point pricing docs.

Three ways to use Kimi K3​

1. Plug it into the AI tool you already use​

Copy the Base URL and API Key, and plug the model into WorkBuddy, CodeBuddy, Cursor or any AI coding tool. Use it like any OpenAI-compatible model — charges go through the CloudBase console's resource-point pool, without touching your existing tool configuration.

2. Call it directly in your full-stack app​

If you're building a mini program, web app, official account or support bot, call K3 as a CloudBase capability — a few lines of SDK code give you streaming output, no separate backend needed.

const model = wx.cloud.extend.AI.createModel("cloudbase");
const res = await model.streamText({
  model: "kimi-k3", // use the actual model ID from the console
  messages: [{ role: "user", content: "你好" }],
});

Database, cloud functions, domain and tokens are all in the same plan — ship right after writing code.

3. Use CloudBase MCP to let your AI tool call K3 directly​

If your AI coding tool natively supports MCP (Codex, Workbuddy, Codebuddy, Cursor, Claude, etc.), you don't need to copy the Base URL and API Key — just configure CloudBase MCP. The tool gets CloudBase's calling capability directly, and K3 can be called within the session.

Add a block to your project's MCP config (Cursor example, file is .cursor/mcp.json):

{
  "mcpServers": {
    "cloudbase": {
      "command": "npx",
      "args": ["@cloudbase/cloudbase-mcp@latest"]
    }
  }
}

Database, cloud functions, domain and tokens are all in the same plan — ship right after writing code.

How to get started​

1. CloudBase console → Plan usage page, confirm the plan is Standard or Enterprise
2. AI console → text-generation model, enable Kimi K3
3. Copy the Base URL and API Key into your AI dev tool, or call it directly from your app with the SDK

In one sentence​

For building mini programs, one CloudBase plan is all you need.

• A Token Plan that comes with cloud resources — ship right after writing, no platform switching
• K3, GLM 5.2, DeepSeek, Qwen all in one pool — switch models with one parameter
• You just call it; no deployment on your side

Meiya Fengniao focuses on enterprise data query and analysis services, with a business model similar to Qichacha and Tianyancha. Through the differentiated "register and get 5 years of SVIP" strategy, it's rapidly accumulating users and expanding its market. But for a team like this, sustaining product capability, service quality and market coverage in the competitive enterprise-data track by simply adding headcount isn't the optimal answer.

Over the past half year, Andy, head of the AI department, has been pushing one goal: use AI to give every employee "the productivity of one person being a company".

"What we're doing is OPC, One Person Company. This goal is becoming more and more possible." — Andy, head of AI at Shanghai Meiya Fengniao

Many things used to be shelved because of production-tool limits​

A big chunk of Fengniao's business is data crawling and ingestion. A product manager decides "we need this data", files a request with a crawler engineer, who schedules it, writes the crawler, ingests it and publishes it. From requirement to usable, a complete chain is usually weeks.

Engineers have limited time; what gets scheduled is the main-product requirement. What doesn't get scheduled is the "also wanted, but not urgent" long tail. HR wanted to run a team-building vote, and used Wenjuanxing as a stopgap. A business colleague wanted to peek at a competitor's public data, and had to file a request and wait.

"Before, a product manager could basically only file requirements — they couldn't do the details. To be blunt, only people who can code can turn an idea into something that runs. The other 80% of the company, however clear their ideas, had to queue behind that 20%."

What Andy targeted first when pushing AI Native was exactly this.

A product manager opens CodeBuddy, connects to CloudBase, and runs it themselves​

Here's a real collaboration flow.

• Before: the product manager says "I want this website's data for these fields", the crawler engineer takes the requirement, develops, ingests, and it comes back to the product.
• Now: the product manager opens CodeBuddy (Tencent's AI coding tool), connects to a CloudBase, and tells AI directly: "I want to crawl this data from this website, ingest it here." AI writes the code, runs it, and lands the data at the specified location. The product manager doesn't write a single line.

Andy knows this combo best; the standard dev chain he recommends to the team is:

• AI coding tool: CodeBuddy (Codex / Claude Code also work; Andy prefers domestic tools)
• Integration: MCP or Skill, letting the AI coding tool call CloudBase's capabilities over a standard protocol
• Backend / compute: CloudBase provides static hosting and object storage

CloudBase does two things in this combo.

Give AI a "safe, physically isolated environment"​

"You have to consider that AI has uncertainty when you develop with it. It's smart and flexible, but if it runs in production, it can easily cause disaster. Let AI work in a safe environment — no matter how it messes up, it won't ruin the results."

Hand the whole CloudBase to AI. AI installs environments, runs commands, writes code, debugs — anything. After development, package the whole environment into a docker image and migrate it to production (CloudBase's own image service, or the company's other host containers).

Andy calls this usage "an isolated physical machine for AI development." It solves the thorniest problem in AI coding today: AI's uncertainty vs production stability. It's a usage he figured out himself — no existing tutorial.

Make finished work immediately usable​

Andy's first project trying CloudBase was directly hosting the finished app on static website hosting, getting a public link everyone in the company could access.

"Host it on CloudBase when done, and access it through a public link."

Development and deployment are continuous — no "find an ops colleague to help publish" step.

Under a month, the team produced about 10 internal apps​

This combo ran through Fengniao faster than Andy expected.

The first batch was lightweight survey and voting apps. HR's team-building vote, once done through Wenjuanxing, now became the company's own small website, hosted out.

Next came data collection. Business colleagues tell AI themselves to "crawl this website's data, ingest it here", and crawlers run on CloudBase.

Then some POCs, hosting AI-written demos directly on CloudBase for internal validation.

"Now there are about 10, because we have plenty of things to do. With AI development, it's actually fast."

10 apps in a month. Behind that number is the first time non-technical roles in the company could independently deliver an accessible, usable internal app.

More concretely, the change in the collaboration chain:

• Before: all internal needs → find R&D → schedule → wait → launch
• Now: everyone uses AI coding tools + CloudBase to do their own needs → launch themselves

R&D colleagues are freed from the "bottleneck" position to work on architecture, models and the AI framework itself. Long-tail needs are absorbed, and main-line needs get more R&D resources.

Fengniao is an SMB, with no big-company AI platform investment and no dedicated AI tooling department. Andy and a few colleagues walked this path through in under half a year. There's no existing tutorial — they left footprints on a road no one had walked.

If this "one person independently delivering an app" capability needs a name, OPT (One Person Team) fits. One person is a small team; the AI coding tool is the keyboard, CloudBase is the backend scaffold, and the finished product is hosted out directly for others to use by opening a link. This was something business roles in B2B companies couldn't do before — now they can.

OPT is the capability unit. One level up, the OPC (One Person Company) Andy is pushing strings all these OPTs together: when everyone can deliver value independently, the company approaches "every employee is a company."

Andy's experience​

Half a year of pushing AI Native, Andy distilled a few plain judgments.

The key to AI Native is whether non-technical teams can use it​

"My own architecture and ops capability is fine. But going AI Native now, the most important thing isn't whether the technical team can do it — we want to popularize it to everyone in the company, especially non-technical colleagues."

The technical team using AI is baseline. Letting non-technical colleagues use AI to directly produce business value is the real turning point.

CloudBase suits non-technical roles too​

"I personally think CloudBase's biggest user group isn't those doing tech or AI specifically. I have N machines and N resources, and I've probably built my own habitual way of using them — for me anything works the same. But for many non-technical people, or people without many resources, CloudBase might be their only channel."

Technical people have their own cloud-resource habits; CloudBase is an option for them. But for an HR, a product manager, a business colleague, asking them to register a Tencent Cloud account, manage SSH keys, set up environments and configure firewalls — one hurdle blocks them at the door. CloudBase flattens all this to "AI sets it up for you, you get a public link", and that's its greatest value to a company.

Design the architecture yourself, let AI write the code​

"I personally prefer domestic tools, including CodeBuddy. I did some architecture design; model capability gaps are small now. If the architecture design succeeds, these tools will definitely work well. If you use Codex or Claude, you'll rely more on someone else's design — disadvantageous in the long run."

Model capability gaps are converging fast; the tool is no longer the variable. The variable is whether the architecture is your own. If the architecture is yours, the tool is just a handy tool, whoever's it is.

OPC happens in two steps​

"Short term, we'll first embed the flow into the existing system; can't reach 100% OPC, only cover part of the flow. In a few months we might reach 50% OPC — no manual management, all AI. For 100% eventually, I think the key is you can't use the old framework; you have to build a completely new framework for AI, then pour the old stuff in."

Step one, embed AI into the existing flow to reach 50% OPC — half the company's flows no longer need manual follow-up. Step two, redesign a new AI-native framework, migrate all existing resources over, reaching 100% OPC.

"We're at about 15% now, preparing to do more. The biggest point in the coming months is raising the OPC ratio to about 50%."

From 15% to 50% to 100% isn't a number on a slide — it's the real timeline Andy set for his team. This is Fengniao's AI Native roadmap for itself.

Who Fengniao's practice matters to​

• If you're in business, product, operations or HR: you've probably felt this — you clearly know what an internal tool should look like, but you can't build it, and R&D's schedule is never as fast as you want.
• If you're a tech lead or boss: you've probably done the math — R&D resources are among a company's most expensive costs, and spending them on long-tail internal needs is waste. When non-technical colleagues can build internal apps themselves with AI + CloudBase, R&D resources are freed for the truly core work.
• If you follow AI Native, OPC/OPT topics: what Fengniao does is now referenceable by many SMBs. OPC can also happen inside an SMB's organization. From OPT (One Person Team) to OPC (One Person Company) is a progression from "capability unit" to "organizational form."

A company truly entering AI Native is measured by whether it has brought every person close to the OPT and OPC state.

The organizational difficulty is worth mentioning more than the technical one​

Talking with Andy, he kept returning to one point.

The technical stuff isn't complex — half a year runs it through. The hard part is organizational. It's about willingness to change colleagues' work habits and bear the cost of short-term efficiency loss for a better long-term form.

"The early phase is definitely slow; once it's used, creating an environment takes minutes and it's fast. Promotion takes time — you gradually persuade people and change their work habits."

Willing to spend a month or two persuading colleagues to change habits, willing to genuinely make AI Native a company-wide thing — this is a rare kind of push in a small company.

CloudBase is an invisible character in their story. During development it's the AI's physically isolated machine; when done it's the public link; when no one uses it, it gets reclaimed. It's behind the scenes, present at every step.

In closing: one enterprise usage of CloudBase​

Fengniao is an Enterprise-plan CloudBase user. The CodeBuddy + static hosting + Docker image migration chain was summarized by Andy and his team as they went — no tutorial, no solution consulting, assembling CloudBase's standard capabilities to their own needs.

This is one way to use CloudBase in an enterprise. You can start today; the minimal path needs just one AI coding tool account and one CloudBase environment.

🔗 Try CloudBase now: https://tcb.cloud.tencent.com/

If you're already on the path, we welcome your submissions to share!

What is CloudBase

Tencent Cloud CloudBase (cloud development) is Tencent Cloud's full-stack integrated backend infrastructure for the AI era, providing cloud functions, cloud database, object storage, static hosting, AI model hosting and other core capabilities. Paired with the Skill and MCP protocols of AI coding tools like CodeBuddy / Codex / Claude Code, it lets business roles, product and R&D all take on business needs directly.

1 billion tokens and 100,000 images means you can confidently bake AI capabilities "thick" into your product without staring at the usage bar. The resource pack is valid for 6 months from the date of successful application.

Registration remains open to all industries​

Continuing the earlier promise, good ideas aren't restricted by category — developers from every industry can apply.

Registration: WeChat Official Account Platform → Industry capabilities → Mini Program Growth Program.

Those without a CloudBase environment can get a free 6-month Personal environment; existing users get an automatic upgrade or a 120-yuan voucher, with the AI resource pack included either way.

Three steps to get started​

Step 1 · Create a CloudBase environment. Register on the CloudBase website, create your first Personal environment, and sign up for the WeChat AI Mini Program Growth Program at the same time — token and image-generation quotas are credited automatically.

Step 2 · Enable the LLM. CloudBase console → AI → text-generation model, check Hy3 preview or any other model you need, and you can start calling it right away.

Step 3 · Generate your first mini program. Use WeChat DevTools → cloud development → AI assistant, or generate complete mini program code in natural language via CloudBase MCP/Skill in an AI coding tool, and deploy within minutes.

FAQ​

Q1: Where can I view AI resource pack usage? Scan the QR code to sign in to the CloudBase web console, or check the "cloud development → AI" module in the latest WeChat DevTools. You'll be reminded via WeChat Official Account messages when usage reaches 80%, 90% and 100%.

Q2: What do I do when the AI resource pack runs out? Switch to the CloudBase resource-point plan, whose resource points directly offset LLM token usage. See the CloudBase docs "Connect an LLM - resource-point plan" for details.

Q3: How do I develop a mini program in natural language? Configure CloudBase MCP/Skill once (fill in the CloudBase Base URL and API Key in tools like CodeBuddy, Cursor, Codex), then describe your needs in natural language to generate and deploy complete mini program code.

Q4: Can mini-game developers use these resource packs? Yes — they get the same CloudBase AI resource pack support as mini program developers. Entry: MP console → Features → Game capability map → AI Growth Program.

Q5: Where do I get the LLM API Key? CloudBase console → Environment settings → API Key. The Base URL is https://<ENV_ID>.api.tcloudbasegateway.com/v1/ai/cloudbase, OpenAI-protocol compatible.

Q6: Can individual businesses develop AI mini programs? Yes. Individual businesses holding a business license can apply to add the "deep synthesis" category. CloudBase provides the corresponding algorithm qualifications — submit together with the WeChat official documentation.

Register an environment on the CloudBase website and sign up for the WeChat AI Mini Program Growth Program to get the full resources and start your 6-month development cycle.

I built a to-do mini program in Cursor with one sentence. Never opened WeChat DevTools, never opened the CloudBase console.

First, some background, so you can judge whether this post concerns you.

There's a clear trend in the 2026 dev-tool world: big companies are all "opening their capabilities to AI agents". GitHub shipped Copilot Extensions, Vercel and Supabase opened MCP in turn, and even databases are competing to be the "hands and feet" of agents. This month, WeChat DevTools joined in — and what it gives agents isn't just code completion, it's the whole "cockpit" of mini programs.

This post takes about 6 minutes. If you build mini programs, or plan to, read to the last section.

One: if you build mini programs, recall yesterday's dev rhythm​

AI writes a chunk of code → you switch to WeChat DevTools → click compile → check the simulator → copy the error → switch back to AI → paste → AI fixes it → switch back again…

One feature, twenty or thirty window switches.

The problem isn't that AI is dumb. Your agent can read/write code and run commands, but it can't see the "world" inside DevTools: whether compilation succeeded, what the page renders like, what errors the Console reports, whether the cloud function actually deployed.

It's like a top chef who has recipes memorized cold but can't see the pot, smell the food, or taste the seasoning — cooking from imagination while you taste-test for it over and over. This is "blindfolded programming."

All the efficiency is wasted on switching, not on writing code.

Two: WeChat DevTools handed the "cockpit" to agents​

Recently WeChat DevTools did something: it opened a set of operable, debuggable, verifiable mini program Skills to developers' coding agents.

Translation: your agent can now complete the entire dev flow inside DevTools by itself — open a project, read status, adjust config, compile, operate the simulator, read logs, locate problems, preview/upload, manage cloud development resources.

Before, AI could only write code for you. Now it can verify whether the code is correct on its own. That difference is the premise for everything that follows.

A side-by-side makes it clear:

Three: scenario one — one sentence, the agent builds the DB, deploys functions, previews on device​

I tried the plainest scenario: typed "build a to-do mini program, store data in CloudBase, previewable on a real device" in Cursor.

Then I watched it run the whole thing on its own: create database collections, write cloud functions, deploy via CloudBase, summon the simulator to screenshot-verify, and finally push a real-device preview to the phone.

My only involvement mid-way — clicking "Allow" in a popup.

The point isn't "AI wrote code", but "AI verified the code actually landed". Build the DB, deploy, verify, preview — this chain used to require clicking five or six places manually; now it ran end to end in your familiar editor.

It's also here that CloudBase naturally entered the story: cloud function deployment, cloud database reads/writes, permission rules — all done by the agent through CloudBase's capabilities. Without the CloudBase half, the agent could at most write your front-end code, and you'd have to take over manually afterward.

Four: scenario two — stop hand-carrying errors, AI reads the logs itself​

The second scenario is even better.

A cloud function errors. Before, you'd hand-carry the error from the console to AI, and it would guess. Now the agent digs through CloudBase logs (CLS) directly, locates the root cause itself, fixes it itself, redeploys itself.

This is the real "closed loop". The old "copy error — paste — AI guesses — you verify" round trip collapsed into a single sentence.

Five: CloudBase — the other half that closes the agent's loop​

Looking at WeChat DevTools Skills alone, the agent can compile, screenshot and drive the simulator. But to truly go "from idea to launch", the cloud half is still missing: database, cloud functions, storage, permissions, logs.

That half is CloudBase.

Let's be concrete — this is also why I dare recommend you try it. For individual developers, CloudBase's free quota is generous:

• Cloud database: 50,000 reads / day, 30,000 writes / day (official base-tier free quota)
• Cloud functions: free monthly call quota; the Personal plan is enough to run a practice project
• Cloud storage / static hosting: free within the base quota
• Monthly cost: for a personal practice project, the dev/test phase is basically ¥0

The 2026 indie developer recipe = AI Agent × WeChat DevTools Skills × CloudBase One person. Three tools. From idea to store.

(You can screenshot this section and post it to Moments.)

One honest line: free is phased, not permanent. Once traffic grows, you pay as you go — that's the norm for all cloud services. But taking an idea from 0 to a presentable prototype — the free quota is more than enough. I've confirmed that for you.

Six: the safety brakes​

Some will definitely worry: the agent can deploy and publish — won't it run wild?

Three safeguards:

1. Dangerous operations (deploying cloud functions, publishing trial versions) pop an explicit confirmation — you authorize before execution;
2. Fetching sensitive info like AppID and cloud environment requires your explicit authorization;
3. All Skill calls run locally inside DevTools; code and logs aren't uploaded to the cloud.

In other words, it can work fast, but the steering wheel stays in your hands.

Seven: two steps to get in​

If you want to try, two steps:

Step 1: download the new WeChat DevTools. Get Nightly Electron Build 2.02.2607032 or above from the DevTools download page.

Step 2: install the Skill — two ways.

Method one (geek's choice): after installing, run wechatide in the terminal, copy the Skill path it outputs, and paste it to your agent.

Method two (beginner-friendly): DevTools menu → "Export DevTools Skill" → export → import into your AI agent.

The CloudBase half needs no separate setup — the agent authorizes on demand when it's needed.

My total bill for all this was ¥0. Not because I'm cheap — the free quota genuinely lets an indie developer take an idea end to end.

If you already use CloudBase, this combo just saves you window-switching; if you haven't — this post is to let you know that opening an environment and running a mini program now has a far lower barrier than when I wrote similar tutorials last year.

Think I'm wrong? Call me out in the comments. Find it useful? Share it with that friend who always complains "mini program dev is too fragmented."

I'm A Shu. Next up: how one person grows a mini program until it makes money.

1. You clearly see a field in a log (like memory_usage), but the option is nowhere to be found in the search panel
2. You finally write a correct CQL query, but the system auto-appends default conditions like requestId and timestamp, and the result comes back empty

This log search update fixes both at once.

What changed​

Visual search fields auto-sync​

Previously, the visual search field list was maintained through backend version updates. A field you logged (like memory, status_code, function_name in the cloud function example) might not appear in the search panel even after being reported — you'd have to wait for the next release.

Now the system dynamically pulls every key reported in the logs, and newly reported log fields automatically appear in the selectable list — no version update needed.

More controllable search interaction​

In statement mode, the system used to auto-append default conditions like requestId and timestamp to your hand-written query, often producing results that didn't match your expectation — the query was right, yet no data came back.

Now the system uses exactly the query you type, without auto-appending any default condition. You search what you want and get it.

How to use it​

No extra configuration needed — go to console → Log monitoring → Log management.

• Visual mode: check the fields you want to filter and combine queries
• Statement mode: write CQL by hand; the system no longer "auto-completes" for you

In one sentence​

No more missing fields, no more modified queries. The field you see is the field you can search; the query you write is the query that actually runs.

CloudBase email login now adds a Magic Link mode: after entering their email, the user receives a login link in the message and just clicks it to sign in — no more typing a 6-digit code.

What this change gives you​

• Three fewer steps in the login flow: no more "read code → copy → switch back → paste"
• Works on the hosted login page out of the box: once enabled, the email login area automatically shows a "Send login link" button
• Configurable redirect: after the user clicks the link and passes verification, they're redirected to the page you specify (order page, dashboard, etc.)
• Switch between modes on demand: products that keep the email code flow are unaffected — adjust per business need

How to get started​

1. CloudBase console → Authentication → Sign-in methods → Email login
2. Select Magic Link mode (or keep the code mode)
3. To customize the redirect, pass email_redirect_to when sending the verification request

How to call it​

In Magic Link mode, pass the email_redirect_to parameter when sending the email verification request:

{
  "email": "user@example.com",
  "target": "ANY",
  "email_redirect_to": "https://your-domain.com/dashboard"
}

When email_redirect_to is omitted, it automatically falls back to the code mode:

{
  "email": "user@example.com",
  "target": "ANY"
}

The redirect URL must be a full URL and can only be a CloudBase default domain or a configured custom domain (to avoid redirect failures after the user clicks the link).

Notes​

• Magic Link supports email login
• Default validity is 600 seconds; it expires once used
• Both the hosted login page and custom SMTP are supported, and both modes work

CloudBase now ships the Integration Center, which pushes this heavy lifting down to the platform layer. You write business logic; the platform does the rest.

What the Integration Center does​

Four steps to integrate​

1. Create the integration: Integration Center → pick a type (e.g. "Mini Program WeChat Pay") → fill in credentials and config
2. Auto-deploy: the platform generates an HTTP cloud function and injects credentials as env vars
3. Call it: invoke the integration function from front end or back end via SDK or HTTP (orders, queries, refunds)
4. Handle callbacks: async callbacks are verified and decrypted by the Integration Center, then forwarded to your function route as plaintext

Once created, the integration function appears in your cloud function list with a name like <integration-name>-<random-string>. Call it straight from the SDK — no signature-verification code required.