VibeSDK is a platform for building, running, and hosting applications

By /

Cloudflare VibeSDK allows you to create AI-based web applications by simply describing your requirements in natural language. It is an open-source tool that runs on the Cloudflare platform and provides a secure, isolated environment that allows you to quickly build, preview, and deploy applications with one click. You can customize the AI’s behavior patterns, govern code paradigms, and protect data privacy.
It’s perfect for businesses, startups, and teams of all kinds—even if team members don’t have deep coding skills, it can build applications with it, greatly improving development efficiency, and making it easy for non-technical people to build the tools they need. Additionally, the platform supports real-time previews, chat-based interaction modes, and can be integrated with GitHub for smooth workflow collaboration.

How did you build a complete platform of “AI application generation + running + hosting”?

While many AI projects are still in the “model tuning API” stage, Cloudflare has open-sourced VibeSDK – an engineering-grade project that clearly doesn’t just care about models, but directly targets the “AI product form”.

It’s not a simple SDK or a single feature library, but a set of self-built AI Web App generation platform templates:
Generate code in stages from natural language input → AI → sandbox real-time preview → Deploy to the Cloudflare platform with one click, and the whole process is connected.

This article starts from the source code directory structure and disassembles the hidden system design behind VibeSDK.

Understand what VibeSDK is in one sentence

VibeSDK is a complete implementation of an “AI application generation platform” rather than a model SDK.

The problem it solves is not whether the AI will generate code, but:

How to turn AI-generated code into a web application that can run, preview, deploy, and multi-tenant.

The project is open-sourced by Cloudflare , and the underlying is deeply bound to Cloudflare’s Workers, Durable Objects, D1, R2, AI Gateway, Workers for Platforms, and other capabilities.

Before looking at the source code, establish an overall system perspective

From the README and repository structure, we can abstract the four core subsystems of VibeSDK:

  1. Web console (UI)
    Users enter requirements, view build progress, preview in real-time, and click deploy
  2. AI Agent backend
    Break down natural language into phased tasks (planning/build/refine) to maintain session status
  3. Sandbox runtime
    Install dependencies, run build projects, and provide a preview URL in an isolated environment
  4. Platform-based deployment layer
    Deploy build apps to Workers for Platforms as “user projects” for multitenant hosting

Next, we directly use the source code directory to compare this structure.

Top-level directory overview: Which system does each folder correspond to?

From the perspective of the repository root directory, the structure of VibeSDK is very “platform-based”, rather than an ordinary front-end and back-end project.

1. The main application of the product (the web platform you actually visit)

src/
public/
worker/

Together, these three constitute the “main application” of VibeSDK.

  • src/
    The front-end code (React + Vite) is responsible for:
    • The user enters a prompt
    • Display generation phase
    • Display real-time logs, preview iframes
    • Trigger the deploy action
  • public/
    Static resources such as icons, public files
  • worker/
    Cloudflare Workers backend:
    • API routing
    • AI calls
    • Session management
    • Durable Object definition
    • Interact with sandbox / platform resources

This is important: VibeSDK’s “backend” is not a traditional server, but runs entirely on Workers.

2. SDK and Sharing Type (Preparing for Secondary Development)

sdk/
shared/types/
  • sdk/
    The official TypeScript SDK provides something similar:const client = new PhasicClient(...) const session = await client.build(prompt) await session.wait.deployable() it exposes a “phasic session object” instead of a simple HTTP package.
  • shared/types/
    The type definition shared by the front and back ends guarantees:
    • API data structures are consistent
    • Session/Phase/Event types are unified

This shows that VibeSDK was designed with the assumption that:
Platform capabilities are meant to be “programmatically called”, not just for the UI.

3. Data layer: D1 + Drizzle’s engineering choice

migrations/
drizzle.config.local.ts
drizzle.config.remote.ts

VibeSDK uses Cloudflare D1 (SQLite) + Drizzle ORM.

From an engineering point of view, this is a very “platform-friendly” option:

  • D1：
    • Native to the edges
    • Low deployment costs
    • Enough to support session/project/audit data
  • Drizzle：
    • Strong type
    • Easy to share models with TS front-end and back-end
    • Migrate files in a clear and controllable manner

Two sets of drizzle configs local/remote, typically used for:

  • On-premises development build migration
  • Remote Cloudflare D1 instance application migration

4. Sandbox and Runtime: Generating code is not “just write it”

container/
SandboxDockerfile
debug-tools/

This is a layer that many AI projects don’t have at all, but VibeSDK explicitly takes it as the core.

  • SandboxDockerfile
    Define the base image for the Preview Runtime:
    • Node/package manager
    • Build tools
    • Restrictions on running permissions
  • container/
    Implementations related to sandbox running, preview environment scheduling

Why do you have to do this?

Because VibeSDK doesn’t just generate code, it to:

  • Install dependencies
  • Start the dev server
  • Expose the preview URL
  • Isolate user code to avoid security issues

This step determines the essential difference between “generator” and “product”.

5. Engineering and automation tool chain

scripts/
test/
vitest.config.ts
.github/
.husky/

These directories make VibeSDK more like a long-term maintainable platform project:

  • Automated scripts (local start, migration, deployment)
  • Vitest
  • CI / Git Hooks
  • Code specification and quality control

6. Deployment and platform configuration: Truly fully utilize Cloudflare’s capabilities

wrangler.jsonc
wrangler.test.jsonc
.dev.vars.example
vite.config.ts
worker-configuration.d.ts

This is the most “Cloudflare-flavored” part of VibeSDK .

 wrangler.jsonc In , you can usually see:

  • Durable Object Binding (session / agent state)
  • D1 database binding
  • R2 Bucket (Template, Generation Product)
  • KV Namespace (Lightweight State/Cache)
  • AI Gateway configuration
  • Workers for Platforms dispatch namespace

This last point means:

User-generated applications are deployed to the platform as “sub-workers” instead of running in the main application.

This is the key to VibeSDK being a multi-tenant platform.

How does a complete call flow in the system?

From the source code structure, a typical link can be restored:

  1. The user enters a requirement on the frontend
  2. worker/ Create or restore a session(Durable Object)
  3. AI Agent Phased Code Generation (Planning → Build → Refine)
  4. The build project is sent to the sandbox to run
  5. The frontend displays the Preview URL in real-time
  6. The user clicks Deploy
  7. Projects are published as standalone apps through Workers for Platforms

The whole process, without traditional servers.

VibeSDK is really powerful

  • It’s not a demo, it’s a platform-level reference implementation
  • It breaks down AI-generated questions into:
    • State machine
    • Life cycle
    • Isolated operation
    • Platform hosting
  • It clearly answers a question:
    “How can AI applications be scaled and productized?”

GitHub：https://github.com/cloudflare/vibesdk
Tubing:

Scroll to Top