bolt.diy

You will like bolt.diy if you liked Bolt.new and hated watching credits drain: same idea, your own keys, no meter but the provider's. The catch is the runtime: everything runs in WebContainers, so it is a JavaScript and TypeScript world with no Python backend, and a big project makes the browser tab sweat until you split it or give up.

Pick it for front-end prototypes and for learning how these builders work from the inside. Pick Dyad if you want a real project on disk that your editor and your CI can see.

The risk is the foundation. The readme states the WebContainer API requires a commercial license for production commercial use, so the fork's own terms are permissive and the runtime underneath is not, which means a company shipping a product on it owes a license the star count never mentions. Open on top, proprietary at the bottom, and the bottom is the part that runs the code.

Read the WebContainer terms before the first paying customer, not after. What it does right: it lives under stackblitz-labs, the parent's own org, so it is a sanctioned fork, maintained rather than frozen.

The architecture is the StackBlitz one. 1. A Node runtime executes in the browser tab, so model output runs immediately rather than on a server. 2. Files are written to a virtual filesystem the terminal and dev server share, so an edit is visible to both without a sync step. 3. Verification is observational: the user watches the preview, and nothing runs a test unless asked. 4. Projects import from a git URL.

No benchmark exists, and none would apply to a tool whose output is judged by eye. The observation: step three is the one that decides quality, and it is the one left to the user.

Open source as a marketing plan, and not the fork's own. StackBlitz hosts a free competitor to Bolt.new under stackblitz-labs because every bolt.diy user learns Bolt, and some of them will pay for the version with hosting attached. Near twenty thousand stars is real distribution and zero revenue, which is fine for a funnel and fatal for a company, and this is a funnel.

Exit paths: absorption into the paid product, or quiet abandonment when the funnel stops converting. Nobody acquires a fork. Position: use it, hold nothing, and keep your own copy of the repo.

The demo is an app appearing in a browser tab from a prompt. Procurement: no vendor, so no MSA, no SSO, no SCIM, no audit trail, no retention terms, and no one to name on the risk register. No headless mode, so nothing runs in CI. Deployment is sixty laptops running pnpm run dev or an Electron build, each with a provider key in a local file that IT cannot see.

Onboarding is a clone and a key, which is also the security problem. Not yet for the organization; approved for a prototyping lab of five with keys issued centrally.

I can read all of it. MIT license, keys go in .env.local copied from .env.example, and the provider list runs to nineteen including Ollama and LM Studio, so the model never leaves my machine and the only network call is the one I choose. It is an MCP client, and docker compose --profile development brings it up in a container with my keys mounted rather than pasted.

A fork of the fork is a git clone away, and the history shows people have already done it once. This is the Bolt I would run, and the one I would patch when it breaks.