Tens of thousands of new apps are created on CloudBase every day. Most of them are built automatically by AI agents.
Close to half of the operations we serve every day no longer come from a human developer typing in a console. They come from agents using the CLI, MCP, or even simulated browser clicks.
More table creation, permission setup, deployment, and debugging now happen inside a conversation between a developer and an agent. The human describes the requirement and checks the result; the agent operates the backend directly.
The conclusion: CloudBase is becoming the default cloud backend for agents and app-generation platforms.
What are they building?
The growth comes from many different kinds of software demand. Some of it is a one-person business. Some of it becomes a work published on a platform. Some of it runs inside an enterprise.
Individual developers and OPCs: one person ships a complete app
Individual developers and one-person companies (OPCs) are a major source of these new apps, and many of them do not write code for a living:
- Laomo, 51, has no coding background. He built a knitting mini program in three days that now serves more than 10,000 fellow enthusiasts.
- Muze spent 16 years as a healthcare IT product manager, then founded a one-person company. Using AI coding tools and CloudBase, he delivered a cardiovascular disease collaboration platform on his own in four months. It is now used by 140 primary-care institutions and is preparing for Level 3 of China's classified protection certification. Under the traditional model, that would take a team of three to four people more than half a year.
- The owner of Jinguyuan Dumpling House in Beijing built "Jinguyuan Dumpling House SKILL" in a single afternoon and evening, so customers' AI assistants can look up store details and recommend dishes. The announcement post was shared 19,000 times.
These apps differ greatly in scale but share the same path: the creator knows the business best, the agent writes the code, and CloudBase carries the backend — database, cloud functions, storage, and authentication. No team to assemble, no servers to buy or operate. An idea becomes a product that keeps running.
Keeping a one-person product running also means solving revenue: WeChat Mini Programs now offer virtual payment to eligible individual entities. Utility mini programs can sell membership days or usage packs, and earnings can be withdrawn directly.
CloudBase provides a mini program virtual payment skill and matching cloud functions, so an agent can handle order signing, delivery callbacks, and order queries. Payment integration that used to require a dedicated backend developer can now be done in one conversation. A WeChat Mini Program built on CloudBase can be a real business.
Send this to your agent and try it now: "Read https://docs.cloudbase.net/skill.md and build me a _____ then deploy it."
Education, retail, and SaaS companies: custom projects and internal tools
CloudBase also serves many enterprise customers. Their demand comes from concrete business needs: custom features for clients, tools for internal processes.
- At Kujiale (kujiale.com), a project manager who does not write code delivered two custom projects for clients in one month using an agent plus CloudBase.
- A well-known education company in China built an internal Vibe Coding platform on CloudBase, so every teacher can create the app they need for internal staff, parents, and students.
- A leading aPaaS (Application Platform as a Service) vendor is building its new AI Coding product entirely on CloudBase, giving its customers faster, cheaper, and more flexible app development.
These three cases start from different places: a business person delivering client projects directly, a company opening development to its own employees, and a vendor using CloudBase as the backend of its own product. They converge on one path:
Let the people closest to the requirement take part in building. The agent handles implementation. CloudBase provides a unified backend.
When that "AI generates apps" capability stops serving only the company itself and becomes a product for a large user base, the backend has a new set of questions to answer.
Zhihu and WorkBuddy: let AI handle coding, let CloudBase handle the backend
When an app becomes content on a platform, the backend has to be supplied, hosted, and managed the way content publishing is.
In Zhihu AI Works, creators upload the source code of an app built with AI coding, and the platform handles the build and deployment. Once a work passes review and is published, users can try it directly inside Zhihu. CloudBase provides the app deployment capability in that pipeline.
WorkBuddy moves app generation into the conversation itself: describe what you need, and it generates a web app with a database, file storage, and sign-up/login — or a WeChat Mini Program. Every app that enables cloud services gets its own CloudBase environment behind it.
The two products behave differently, but both have to host a large number of apps created on demand. Apps appear at any moment, traffic varies wildly, some works stay low-traffic for a long time, and a few may suddenly go viral.
For a platform, each app's backend has to be a standard capability reachable through an API: created when the app is created, isolated from other apps' data, with queryable usage, and reclaimable once the app goes inactive.
The CloudBase platform edition is designed for exactly this:
- A single Tencent Cloud account can create and manage a large number of isolated environments, and issue each user an API key scoped to their own environment.
- A user's agent connects to CloudBase directly with that API key. No platform backend in the middle, no extra login flow.
- CloudBase provides unified metering and usage queries, so the platform can see what each environment consumes and design its own quotas and pricing on top.
Building an "AI generates full-stack apps" feature is getting simple for any platform: let AI handle coding, let CloudBase handle the backend.
Learn about the CloudBase platform edition.
Why do they all choose CloudBase?
A one-person business, an enterprise business system, and a platform hosting millions of apps differ in scale and shape, but their backend requirements point at the same three things:
- Cost should match actual usage.
- Multi-tenant isolation and control should be simple.
- Backend capabilities should be directly understandable and operable by agents.
Those are the three directions CloudBase keeps investing in.
Low cost: a million databases can still be cheap
A team used to run a handful of long-lived apps. Now AI lets anyone generate several apps through an agent. If every app has to hold a fixed slice of cloud resources for good, even a low unit price turns into a lot of idle spend at scale.
What we want to cut is the fixed cost that has nothing to do with actual usage, so that a large number of low-traffic apps have a reasonable long-term running cost.
CloudBase PostgreSQL offers a Micro instance, and environments can be created in seconds. The database stops computing while idle and resumes when a request arrives. An app does not have to be deleted or isolated just because nobody visited it for a while, and nobody pays for idle compute.
As load grows, each environment's PostgreSQL can be scaled independently, and a steadily growing business can move to larger instances. A platform does not have to scale every app up because one app got popular.
Through all of this the app keeps using the same PostgreSQL schema, permission policies, and API model. Teams can adjust resources by load, then optimize queries, indexes, and architecture around the real bottleneck.
Just as more efficient steam engines did not reduce coal consumption but unlocked far larger industrial demand, cheaper backend services are not only about saving money — they make a huge number of apps viable that were previously not worth building.
Enterprise multi-tenant isolation: hand resources to users and agents with confidence
Each CloudBase environment is a fully independent set of resources: PostgreSQL, cloud functions, storage, authentication, and the rest. A platform only needs to issue the environment's API key to a user or their agent, and tenant control-plane isolation is in place.
In the MCP/CLI authorization flow we also support connecting to enterprise SSO identity providers, so internal users log in directly without a second identity system.
Billing units matter just as much to Vibe Coding platforms. CloudBase provides unified resource metering, so a customer platform can manage the total and per-tenant usage, then design its own quotas and pricing without building a separate cloud billing system.
PostgreSQL Native: making the backend an agent primitive
Primitives is a slightly academic word. In plain terms: a small set of simple operations that are expressive enough and compose well with each other.
To build a backend, an agent needs to know how data is organized, who can access it, and what a successful operation returns. PostgreSQL offers a mature, explicit way to express all three: schemas, constraints, transactions, indexes, database functions, and row-level security are all defined in SQL. An agent can read those definitions, change them, and verify the result by running queries and tests.
This year we introduced a new PG Native architecture on top of PostgreSQL, folding complex backend capabilities (auth, permissions, triggers, queues, scheduled tasks) into plain PG plus SQL semantics.
Take a collaborative app: "who is the current user" and "which team do they belong to" reuse the same identity information. Access boundaries for records and files are each defined by an RLS policy, and an agent configures and checks those rules with the same SQL semantics. Resources still have to be granted explicitly, but identity and permissions no longer have to be stitched together from scratch.
CREATE TABLE docs (
id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
title text,
owner_id text DEFAULT auth.uid()
);
-- Row-level security: each user can only touch their own docs and files
CREATE POLICY own_docs ON docs FOR ALL TO authenticated
USING (owner_id = auth.uid()) WITH CHECK (owner_id = auth.uid());
CREATE POLICY own_files ON storage.objects FOR SELECT TO authenticated
USING (owner_id = auth.uid());
Once the schema exists, CloudBase exposes a RESTful API through PostgREST. Common reads and writes can call those endpoints directly; more complex logic uses transactions, database functions, or server-side compute. Vector search works through PostgreSQL extensions such as pgvector.
const docs = app.rdb().from("docs");
const { data } = await docs.select("id, title"); // only your own docs are returned
await docs.insert({ title: "Product plan" }); // owner_id is bound to the current user
The AI only needs to understand Postgres and SQL. CloudBase does the rest.
What's Next
The Postgres Native architecture answers the question of whether an agent can understand and operate backend capabilities. Talking to customers and developers, we found two more questions that deserve the same attention:
- When an agent builds, how do you let it experiment freely without dropping the production database?
- When apps move from "read and write data" to "live state", is a CRUD-only database still enough?
Two recently launched capabilities answer them.
Environment Branching: manage backend environments like code
Git lets developers change code safely on a branch, but databases and backend environments have long lacked the same safety net. A trial migration or one wrong agent action can hit production data directly.
Branching takes an existing environment and produces an independent branch with a full copy of the schema, RLS policies, cloud functions, and data, plus a temporary key that only reaches that branch. The agent can create tables, change permissions, and write test data against a real-size copy, while its credentials cannot touch the main environment.
We believe that the deeper agents get involved in backend development, the more "safe to experiment" should be a default property of backend infrastructure rather than something enforced by prompt wording or command scanning.
Read the environment branching docs.
Realtime: data changes as subscribable events
In a traditional app, data is a static snapshot fetched request by request. Chat, presence, and collaborative editing are standard now, and users expect to see a change the moment it happens — the relationship between an app and its data is shifting from "query on demand" to "keep in sync".
Realtime lets a client subscribe directly to PostgreSQL changes and reuse the same RLS policies as CRUD. There is no separate message system and no second permission model to maintain.
For an agent, realtime should not be a different backend it has to learn. It is just another expression of the tables, rows, and permissions it already understands.
Read the realtime docs.
Both capabilities are in Private Alpha. Contact us to join the preview.
Even the smallest idea deserves to run in production
A website, a mini program, or a mobile app used to need enough users or a big enough budget to cover development and maintenance. Many concrete needs therefore stayed in spreadsheets, in chat threads, or in manual work.
AI is cutting the cost of building software. If the backend an app needs is also available on demand and cheap to run, then an app that serves a handful of people, one shop, one department, or one fan community becomes viable. A developer no longer has to find a large market before building.
From fan communities built by one-person companies and dumpling-house ordering, to internal collaboration systems and custom client projects, to consumer platforms serving millions and AI agents — the businesses differ, but the trend they express is the same:
Software supply is moving from a small number of standardized products to a huge number of apps driven by specific needs. The backend has to follow: on demand, cheap to run, and directly operable by agents.
The tens of thousands of apps added on CloudBase every day are one result of that shift. Our mission is to make sure what AI generates is not just local code but an app actually running online — so that cloud services and backends stop being a barrier to creating, and every idea that becomes an app is worth shipping.
