Overview
Built on Tencent CloudBase, this solution provides end-to-end infrastructure for Vibe Coding platforms (such as Lovable, Bolt.new, Vercel v0, OpenClaw) — covering Agent runtime → code execution → app deployment → multi-tenant isolation, enabling your users to get a fully functional application with a complete backend from a single prompt.
This solution is currently in beta testing. Contact the product team for access.
Challenges You Face
Building a production-grade Vibe Coding platform requires solving these core problems:
| Challenge | Problem Description | CloudBase Solution |
|---|---|---|
| Secure code execution | LLM-generated code must run in an isolated environment without affecting production servers or exposing platform credentials | Sandbox — isolated containers, on-demand creation/destruction, workspace persistence |
| Agent orchestration & scheduling | Agent Loop needs to manage prompt orchestration, tool routing, session persistence, and flexible model switching | Agent Loop + MaaS Model Service |
| Complete app backend | User-generated apps need databases, APIs, file storage, and authentication — not just static pages | App Backend & Hosting — database, cloud functions, cloud storage, authentication, static/container hosting, all in one |
| Multi-tenant isolation | Each user's data, compute, and storage must be strictly isolated, while the platform needs unified management and billing | Multi-tenant Architecture — one-tenant-one-environment, natural resource isolation, CAM and white-label permission schemes |
Architecture
The solution adopts an N+1 architecture — 1 platform CloudBase environment hosts the Vibe Coding platform itself (Agent Loop, Sandbox, model inference), while N user CloudBase environments host the applications generated by users (database, cloud functions, hosting, etc.). Environments are naturally isolated from each other:
Core Design Principle: Controlled Trust Boundary
- Agent Loop (trusted): Deterministic code written by the platform, holds all credentials, responsible for orchestration and decision-making
- LLM (untrusted): Model output is unpredictable, has no access to any credentials
- Sandbox (untrusted): Executes LLM-generated code, only holds the current user's environment-level credentials
Why Must Agent Loop and Sandbox Be Separated?
This design draws from the Brain / Hands separation architecture proposed by Anthropic — the Agent Loop is the "Brain", responsible for reasoning and decision-making; the Sandbox is the "Hands", responsible for code execution. They must run in separate processes or even separate containers, for the following reasons:
1. Security Isolation: Credentials Must Never Be Reachable from the Sandbox
If the Agent Loop and Sandbox run in the same container, malicious code generated by the LLM (e.g., via prompt injection) could simply read environment variables to obtain platform credentials, then create unrestricted new sessions and spread the attack. After separation, the Sandbox holds no platform-level credentials — even if compromised, the blast radius is limited to a single user's environment-level keys.
2. Fault Isolation: Components Can Fail and Be Replaced Independently
In a coupled architecture, the container becomes an irreplaceable "pet" — if user code in the Sandbox causes an OOM or container crash, the entire Agent session is lost. After separation, the Sandbox becomes disposable "cattle" that can be discarded and rebuilt at any time. The Agent Loop simply recovers its state from the session log and attaches a new Sandbox to continue working.
3. Performance Optimization: Inference Doesn't Have to Wait for Container Startup
Many Agent interactions (such as pure conversation, prompt orchestration, tool routing decisions) don't need a Sandbox at all. In a coupled architecture, every session must wait for container startup, significantly increasing Time to First Token (TTFT). After separation, requests that don't require code execution can begin inference immediately, with Sandbox started on-demand only when needed.
4. Elastic Scaling: Multiple Brains Scheduling Multiple Hands
The separated architecture enables a single Agent Loop to schedule multiple Sandboxes on-demand (e.g., running frontend builds and backend deployments simultaneously in different containers), or multiple Agent Loop instances to share the same Sandbox pool, achieving more flexible resource scheduling.
For detailed trust boundary design and request lifecycle, see Agent Runtime - Controlled Trust Boundary.
Core Capabilities
| Capability | What It Solves | Documentation |
|---|---|---|
| Agent Runtime | Agent Loop orchestration, Sandbox secure execution, MaaS multi-model access — drives the full chat → code → deploy workflow | Agent Runtime |
| App Backend & Hosting | Provides database, cloud functions, cloud storage, authentication and other backend capabilities for Agent outputs, plus static hosting, container hosting, and custom domain support | App Backend & Hosting |
| Multi-tenant Isolation | One-tenant-one-environment with natural compute/data/storage/network isolation, supporting both CAM and white-label permission schemes with unified management and billing | Multi-tenant Architecture |
| Open-source Reference | A complete open-source Vibe Coding platform built on CloudBase — deploy directly or use as a starting point | OpenVibeCoding |
Next Steps
- Dive into the architecture: Start with Agent Runtime and read through each chapter in order
- Get hands-on: Check out the open-source project OpenVibeCoding — clone and run immediately