Cloudflare VibeSDK

The thing you feel immediately is that there is no development server to wait on. Each preview is bundled and loaded on demand, so the page you asked for appears in seconds and the next change replaces it, which for prompt-and-look work is the difference between a session that flows and one that stalls.

In exchange the whole platform is yours to deploy and yours to run, which is the point and also the work. Pick it if you want the generated apps and their history in an account you already administer. Pick Lovable if the appeal was never having to hold any of it.

The risk is what open means here. The workspace, the version store, the preview loader, the per-application database and the model routing layer are each a proprietary service of one provider, and the code orchestrates them rather than abstracting them. You can read all of it, deploy all of it, and only into one place, so the exit is a rewrite of the platform rather than a migration.

Export your generated projects early and often. What it does right: shell access is disabled outright, so the agent's capabilities are an explicit list instead of an open-ended command line.

1. Generation is iterative by design, replacing the staged pipeline earlier builders used with a loop the model drives through tools. 2. Those tools read and write the project workspace, create restore points, deploy previews, and read browser console output, so the failure signal comes from the running artifact and returns to the same loop that produced it. 3. Underspecified requests trigger structured clarifying questions rather than assumptions.

2. Rollback replays a chosen commit forward as a new commit, leaving history intact. Verification against a deployed runtime is the strongest form available to a generator, and few of them do it.

Infrastructure demand generation, executed well. The platform is free, deployment into the vendor's account is a single button, and everything the resulting applications do afterwards is billed by that vendor: compute, per-project storage, version history and the model routing layer. Give away the builder, meter what it builds.

That alignment is the reason to believe the project persists: it is not a bet on the app-builder market, it is a bet on developers running things somewhere. No acquirer, no pivot, and no free tier that has to be defended by a fundraise. Position: long, and treat vendor commitment as the cost of the product.

The commercial shape is fine: no seats, no licence, and the running cost lands on an infrastructure account we can already budget and monitor. If we hold that vendor relationship, the governance is our existing governance. Deployment is one button, which is genuinely a memo rather than a project.

What it does not do is fit how we ship. Output is a deployed application, not a change a reviewer approves, and it covers one language family, so it never reaches most of the team. Approved with conditions: internal tools and prototypes only, on a separate account, with export required before anything is treated as a real codebase.

MIT, and unusually for a hosted-looking product the deployable thing is the actual product rather than a demo cut of it. Model routing goes through a gateway I configure, so which provider answers is my decision and the caching and observability come with it. Generated projects can be exported when I want to continue outside, which is the escape hatch I check for first.

What I cannot do is run any of it on my own metal, and there is no tool protocol client to attach the servers I already have. Read it, deploy it, do not confuse it for portable.