Cloudflare VibeSDK: self-hosting an open-source vibe coding platform on Workers

The problem VibeSDK solves: running the whole agent loop yourself

Most AI app builders are hosted products. You type a prompt, the vendor's servers run the model, the vendor's servers hold your generated code, and the preview lives on a domain you do not control. VibeSDK takes the opposite position. It is a platform you deploy into your own Cloudflare account, and the README describes it as an open source, agentic platform for building and deploying full-stack applications on Cloudflare. The audience is therefore narrower than a consumer tool's: engineering teams who want an internal vibe coding surface, or companies that want to offer code generation to their own users without handing the workspace to a third party.

The repository layout supports that reading. There is a `worker/` directory for the Worker entrypoints, a `space/` workspace package, `sdk/`, `shared/`, `migrations/` for D1, and `wrangler.jsonc` alongside `wrangler.staging.jsonc` and `wrangler.test.jsonc`. That is the shape of a deployable service, not a demo. The trade-off is explicit: you get control of the data path and the model routing, and in exchange you own the Cloudflare configuration, the DNS, and the billing.

How the ThinkAgent, SpaceDO and Worker Loader fit together

The architecture table in the README names six moving parts. `ThinkAgent` is the agent, powered by Cloudflare Think and backed by a Durable Object that runs the model-and-tool loop. `SpaceDO` is a second Durable Object that provides each project's isolated workspace and files. Cloudflare Artifacts is a binding that stores commits, branches, history and restore points. The Worker Loader binding loads bundled code as a Dynamic Worker preview. Each generated app becomes an `App` Durable Object Facet with isolated SQLite storage, and AI Gateway routes the configured model providers with observability and caching.

The data flow is a loop rather than a pipeline. The user talks to ThinkAgent; ThinkAgent talks to models through AI Gateway and reads or writes files in SpaceDO; SpaceDO persists history through Artifacts and hands committed code to the Worker Loader; the loader produces a Dynamic Worker preview; that preview forwards backend requests and WebSockets to the generated App Facet, which owns its SQLite data. Browser console output flows back into the loop so the agent can repair runtime errors and redeploy.

Two design choices stand out. First, previews are Dynamic Workers, not long-running development servers, and the README states each committed deployment is bundled with `@cloudflare/worker-bundler`. That removes a whole class of idle-server cost, but it also means a generated app must be bundleable for Workers. Second, Think's explicit tools read and edit the workspace, create restore points, deploy previews, inspect browser logs and ask clarifying questions, and the README says bash access is disabled. The agent cannot run shell commands. For safety that is a sensible default; for build steps that expect a shell, it is a hard boundary.

Installing VibeSDK locally and running a first project

The README's quick start assumes Node.js 18 or later, Bun, and a Cloudflare account with an API token. Note that `package.json` declares `"node": ">=22"` in its engines field, which is stricter than the README's stated prerequisite. Clone the repository, install dependencies, run the setup script, then start the dev server:

git clone https://github.com/cloudflare/vibesdk.git
cd vibesdk
bun install
bun run setup
bun run dev

The README says to open `http://localhost:5173` afterwards. The setup script is not a stub: according to the README it configures local and production environments, Cloudflare resources, AI Gateway and model providers, authentication, and database migrations. Expect it to ask for your API token and provider credentials.

Feature toggles are dashboard-managed rather than committed in `wrangler.jsonc`, and production values survive deploys through `keep_vars: true`. For local work you set them in `.dev.vars`. The README lists `ENABLE_ARTIFACTS`, `ENABLE_READ_REPLICAS`, `ENABLE_CLOUDFLARE_LIMITS`, `ENABLE_USER_ACCOUNT_DEPLOY`, `ALLOWED_EMAIL`, `USE_CLOUDFLARE_IMAGES` and `USE_TUNNEL_FOR_PREVIEW` as defaulting to off when unset, while `ENABLE_EMAIL_AUTH` defaults to on and `ALLOCATION_STRATEGY` uses its normal default. There is a `.dev.vars.example` in the repository root to copy from.

Console-log inspection needs a second process. The development command table lists `bun run dev:browser` as the optional local browser sidecar used for console-log inspection, so if you want the agent's verify-and-repair step to see browser output locally, run it alongside `bun run dev`.

Production deployment needs Workers for Platforms, not just a Workers account

The Deploy to Cloudflare button is the shortest path, and the README is unusually direct about what it costs you in prerequisites. You need a Cloudflare account with the required Workers features enabled, a Workers Paid plan and Workers for Platforms access for production app previews, an API token with access to the resources created by setup, credentials for at least one supported model provider unless you use provider keys stored in AI Gateway, and a custom domain for production including wildcard DNS and Advanced Certificate Manager when required by your subdomain layout.

That list is the real adoption gate. Workers for Platforms is the mechanism behind serving many generated applications as separate Dynamic Workers, and the wildcard DNS requirement follows from giving each generated app its own hostname. If your organisation cannot get that entitlement, or cannot add wildcard DNS to the domain you want to use, the preview path will not work as documented. The README points to `docs/setup.md` for current permissions, DNS, AI Gateway, provider, OAuth and production configuration, and that file, not this article, is where the exact permission list lives.

Version history, rollback and per-app SQLite

Two capabilities separate VibeSDK from a chat window that emits code. The first is version history. The README states that rollback restores a selected commit into the current branch, creates a new commit, and redeploys without rewriting history. That is a forward-only model: you never lose the state you rolled back from, and every restore point is a real commit in Cloudflare Artifacts. It also means history grows rather than being rewritten, which is good for auditability and less good if you expected rollback to erase a bad generation from the record.

The second is application data. Each generated app gets a Durable Object Facet with isolated SQLite storage, and the README says users can inspect and reset it. Isolation per app is the important part: one generated project's data does not leak into another's. The README does not document what happens to that SQLite data when a project is deleted, nor whether resetting the database is itself reversible. Treat reset as a destructive control until the setup documentation says otherwise.

Project export is the escape hatch. The README lists export of generated projects for continuing development outside VibeSDK, which matters if you want to move a project to your own repository and CI rather than keep it inside the platform.

Where VibeSDK is the wrong tool

The README's own constraints rule out several use cases. Bash access in the agent is disabled, so a workflow that depends on running arbitrary shell commands inside the workspace is not supported by the documented tool set. Previews are Dynamic Workers produced by `@cloudflare/worker-bundler`, so a generated application that assumes a conventional Node.js server, a persistent process, or a database driver that will not run on Workers is a poor fit. The platform's whole value proposition is that the generated app is a Cloudflare app.

There is also an operational cost that a hosted builder hides. Feature toggles are managed in the Cloudflare dashboard per environment rather than committed, which the README frames as a way to keep production values across deploys through `keep_vars: true`. The consequence is that your production behaviour is partly configured outside version control, and reproducing an environment means reproducing dashboard state. Teams that expect configuration to be entirely declarative will find that uncomfortable.

Finally, the README does not document rollback of a deployment as distinct from rollback of a commit, nor does it describe rate limiting or quota behaviour for generated previews. If you plan to expose the platform to external users, those are gaps you have to close yourself.

VibeSDK compared with a local agent runner such as Claude Code

The closest alternative in practice is not another hosted builder but a local coding agent that operates on a repository you already own. The difference is architectural. A local agent edits files on your machine, runs commands in your shell, and leaves version control to git as you normally use it. VibeSDK instead puts the workspace inside a Durable Object, stores history in Cloudflare Artifacts, and serves the result as a Dynamic Worker preview with its own SQLite facet.

That buys multi-user isolation and a browser-accessible preview without a development server, and it costs you the shell. A local agent can run your test suite, a migration, or a build script; VibeSDK's agent cannot, because bash access is disabled and its tools are limited to reading and editing the workspace, creating restore points, deploying previews, inspecting browser logs and asking clarifying questions. If your project's correctness depends on running commands, the local agent is the better fit. If you need many people generating and previewing apps against infrastructure you control, VibeSDK's model is the one that scales without a fleet of long-running servers.

Licence and the upgrade cost of a fast-moving platform

VibeSDK is MIT-licensed, and the LICENSE file sits at the repository root. MIT is permissive: you can use, modify and redistribute the code, including in a commercial offering, provided the copyright notice and permission notice are preserved. That is a statement about the licence text, not legal advice about your situation, and it says nothing about the Cloudflare services the platform depends on, which are governed by Cloudflare's own terms and pricing.

The upgrade cost is where you should budget time. The repository ships `wrangler.jsonc`, `wrangler.staging.jsonc` and `wrangler.test.jsonc`, three environment configurations that all have to be kept in step with the code, plus D1 migrations under `migrations/` applied through `wrangler d1 migrations apply vibesdk-db`. Releases have moved quickly: v1.3.0 in December 2025, v1.4.0 later that month, and v1.5.0 in February 2026, with the last push to the default branch on 2026-09-08. The repository is not archived, but the README notes dashboard-managed toggles mean production values survive deploys, which cuts both ways: your configuration will not silently reset on upgrade, and it also will not be reviewed by a diff when you upgrade.

Editorial conclusion

Adopt VibeSDK if you already run Cloudflare Workers and want an agentic builder you control end to end, and you accept that production previews require a Workers Paid plan plus Workers for Platforms access. Do not adopt it if you want a hosted product with no infrastructure, or if you need the agent to run arbitrary shell commands, because Think's bash access is disabled. Before committing, verify two things: that your account has the Workers for Platforms entitlement and the DNS layout for per-app subdomains, and that the setup script's generated configuration matches the model provider and authentication options you intend to use.

Frequently asked questions

Official sources

1. cloudflare/vibesdk on GitHub
2. License: MIT
3. Project website
4. README
5. Releases