OpenAI Codex's release of the Sites capability sends a very clear signal: AI programming products are moving from "helping developers write code" to "helping users directly own an accessible, savable, deployable application."
In Sites, users don't need to understand servers, databases, object storage, domains, build pipelines or permission configs — they just describe their needs in Codex, and Codex creates the site, saves versions, deploys it, and returns an accessible production URL.
This looks like OpenAI adding a hosting plugin to Codex, but the product trend behind it is bigger: in the future, every AI assistant, AI programming platform and enterprise knowledge workbench may need built-in "generate an app and ship it" capability.
For domestic model vendors, AI app platforms and AI assistant products, a very real question follows: if you want to build an OpenAI-Sites-like product, how should you build the underlying app infrastructure?
CloudBase provides a complete solution.
1. What OpenAI Sites actually solves
From public docs, OpenAI Sites is currently in Preview, aimed mainly at ChatGPT Business and Enterprise workspaces. Its core capabilities boil down to five things:
- Generate apps in natural language: users describe a website, web app, dashboard or mini game with
@Sitesin Codex; - Save versions: Codex associates a deployable build with a Git commit, as a reviewable release candidate;
- Deploy: publish a saved or verified version as a production URL;
- Out-of-the-box backend: D1 for structured data, R2 for file storage, workspace identity for internal apps;
- Access control and secret management: admin-only, workspace-wide, or custom user/group access; runtime secrets configured through the managed platform, never in source.
Abstract these and Sites is fundamentally not a simple website hosting service, but an AI-native app delivery platform:
Natural-language requirement → agent generates code → auto-configures database / storage / identity / env vars → saves a reviewable version → deploys to production → controls access scope
In other words, Sites' key isn't "deploy a static page" — it's embedding "deployment, storage, identity, permissions, version management" — work that used to belong to DevOps and backend engineers — into the AI agent's workflow.
Once users get used to "one sentence to generate and access an app," AI products can no longer stop at code or page generation; they must complete the app-delivery loop.
2. What model vendors / AI app platforms building Sites really lack is the app runtime foundation
If your customers are model vendors, AI app platforms or AI assistant products, the focus shouldn't be only "how the agent runs."
These platforms usually already have their own models, chat entry, code-generation agents and sandbox execution environments — some can even generate a front-end project.
What they really need to complete is the D1 / R2 / Supabase / Vercel combination behind OpenAI Sites: making the model-generated app not just code snippets or preview pages, but a real app with a database, file storage, login, APIs, permissions and a production URL.
In other words, the key to a domestic Sites isn't building another coding agent — it's giving existing agents an app backend and hosting foundation that models can call reliably.
1. You need a "D1": structured data available by default
In Sites, D1 solves the most basic yet critical problem: after an app is generated, where does the data live?
CloudBase can play this "domestic D1 / Supabase Database" role, providing PostgreSQL / cloud database so generated apps natively have structured-data persistence.
2. You need an "R2": files and build artifacts storable by default
Real apps always involve files: avatars, images, attachments, audio/video, import/export files, and front-end build artifacts.
CloudBase cloud storage can play the "domestic R2" role, storing user uploads, static resources and build artifacts, combining with the database for "file content + metadata search".
3. You need a "Supabase": login, permissions and APIs together
Sites doesn't just deploy pages — it handles workspace identity, public login and access control. CloudBase can provide a Supabase-like BaaS combination: authentication (anonymous, email, phone, WeChat, Google, OAuth, SSO, SAML), data permissions, cloud functions, env vars and secrets, management-plane APIs / MCP.
4. You need a "Vercel": ship right after generation
Users of Sites-like products don't expect "a zip package" — they expect "a link I can open." CloudBase's static hosting, cloud functions, container hosting and HTTP access services form the deployment foundation for generated apps.
3. CloudBase's positioning: the Backend Cloud that model vendors / AI app platforms need for Sites
CloudBase's positioning here isn't replacing the customer's model, agent or product entry — it's becoming the default Backend Cloud that models call when generating apps.
Think of it as a domestic capability combination:
CloudBase = D1-like database + R2-like object storage + Supabase-like BaaS + Vercel-like hosting
The ideal architecture should be:
User enters requirement → the platform's own Chat / Agent / Coding Runtime → generates front end, back end and data models → creates database, storage, functions, hosting and permissions via CloudBase API / MCP → CloudBase hosts the live app → returns the production URL
4. Mapping CloudBase against OpenAI Sites' key capabilities
| OpenAI Sites capability | CloudBase equivalent |
|---|---|
| Create site / web app / game in natural language | Platform's agent generates; CloudBase provides callable database, storage, functions and hosting resources |
| Save versions for review | Save source commits, build artifacts, database changes, env config and deploy metadata as reviewable release candidates |
| Deploy as a production URL | Static web hosting, cloud functions, container hosting, HTTP access service, auto-generated HTTPS address |
| D1 structured data | CloudBase PostgreSQL / cloud database, with SQL, transactions, foreign keys, RLS |
| R2 file storage | CloudBase cloud storage for images, docs, audio/video, build artifacts and user uploads |
| Supabase-like BaaS | Authentication, data permissions, cloud functions, env vars, management-plane API / MCP in one place |
| Workspace identity / public login | Anonymous, email, phone, WeChat, Google, OAuth, enterprise SSO, SAML identity sources |
| Access control | Tenant- and app-level permission control via CloudBase environments, security rules, gateway and the platform's own account system |
| Env vars / secret management | Cloud function env vars, temporary credentials, secret hosting — runtime config never in source |
| Multi-tenant isolation | One tenant per CloudBase environment, with compute, data, storage and network isolated by nature |
5. Customer cases
1. Tencent Tusi APP
Tusi APP (https://tusi.qq.com/) is the "app generation and idea co-creation platform" from the Tencent App Store team. Users type prompts, AI completes development and deployment, and produces a downloadable, installable app.
Tusi uses CloudBase as its main backend: cloud database with tenant-level isolation by nature; authentication with WeChat, phone, email and anonymous login built in; MCP/Skills wrapping backend resources as standard MCP tools for declarative agent invocation.
2. GenieAI (CodeBuddy)
GenieAI (https://genie.codebuddy.ai/) is the online AI programming workbench from Tencent Cloud CodeBuddy, covering the full flow from requirement understanding, UI design and code generation to database configuration and one-click deployment.
GenieAI chose CloudBase as its backend infrastructure: PostgreSQL with native transactions, foreign keys, complex SQL and vector search; authentication with Google, Apple and email login; one-click deploy and white-label domains giving every project an HTTPS link in seconds.
6. Closing: AI app platforms need their own D1 / R2 / Supabase
OpenAI Sites' release shows the AI programming competition is entering its next phase:
- Phase one: "AI can write code";
- Phase two: "AI can modify projects";
- Phase three: "AI can deliver a complete app online."
At phase three, the infrastructure that truly matters is no longer just the model — it's the app-delivery foundation behind it: database, object storage, authentication, cloud functions, hosting, versions, permissions, multi-tenancy, billing and auditing.
CloudBase's value is exactly this: reorganizing capabilities once scattered across different cloud products, consoles and ops flows into a Backend Cloud that models and agents can call directly.
For model vendors, AI app platforms and AI assistant products that want to follow OpenAI Sites, the shortest path isn't building an entire cloud platform from scratch — it's plugging CloudBase behind your product:
Your model + agent experience + CloudBase Backend Cloud = a Sites-like product for the domestic market
