bolt.diy’s pitch is simple: prompt in, app out, no server required. What’s less visible is what’s actually enforcing that experience, and what it quietly assumes you’ll never try to do.
I went into the repo to find out. Three things stood out: the sandbox is doing more constraining than most users realize, the system prompt is where most of the real engineering effort lives, and the architecture running today is simpler than “AI agents building your app” makes it sound.
What WebContainer Actually Is
bolt.diy runs on WebContainer, StackBlitz’s in-browser Node.js runtime. The important detail is in how it’s described in the project’s own system prompt: an environment that emulates a Linux system to some degree, but runs entirely in the browser rather than on a cloud VM. There’s no server executing your code. Your laptop’s browser tab is.
That single design choice explains most of what bolt.diy can and can’t do, and it’s worth being specific about the “can’t,” because it’s more restrictive than “runs in a browser” makes it sound:
- No native binaries. Nothing gets compiled to machine code, because the browser can’t execute it. Only JavaScript and WebAssembly run.
- Python is present but gutted. The shell ships
pythonandpython3, but they’re limited to the standard library only. There’s nopip. Standard library modules that depend on system-level dependencies, likecurses, don’t work either. - No C or C++ compiler exists in the environment. WebContainer cannot compile native code, full stop.
- Databases have to avoid native code too. The system prompt explicitly steers the model toward
libsqlor SQLite-style options over anything that depends on native bindings.
None of this is a limitation bolt.diy’s maintainers are hiding. It’s a limitation of running Node in a browser sandbox instead of a real server, and the project’s response to it is instructive: rather than trying to paper over the gap in the UI, they encoded the constraints directly into the model’s instructions.
The system prompt is the actual product
Strip away the chat interface and the file tree, and what’s left is a several-thousand-word instruction set that has to compensate, in real time, for everything the sandbox won’t do. A few examples worth calling out because they reveal how much of this is defensive engineering rather than feature-building:
No diff-based editing. The prompt tells the model that WebContainer cannot execute diff or patch operations, so every file has to be rewritten in full on every change, no partial updates. That’s a real cost: more tokens per edit, more chances for the model to accidentally drop something it wasn’t supposed to touch. It’s not a stylistic choice, it’s a constraint imposed by what the sandbox can and can’t apply.
Shell scripts are discouraged in favor of Node.js. The environment doesn’t fully support shell scripting, so the prompt actively pushes the model toward writing scripting logic in Node instead of bash, wherever there’s a choice.
The model gets a warning about a specific internal artifact type it must never use. The prompt calls this out as non-negotiable, which is an unusually blunt instruction to find in a system prompt, and it tells you the maintainers have been burned by the model reaching for it before.
This matters because bolt.diy’s own project roadmap lists running agents in the backend, instead of a single model call, as a high-priority item that has not been built yet. Today’s bolt.diy is one model, one long system prompt doing a lot of defensive work, and a single conversation loop. Multi-agent orchestration is on the roadmap, not in the shipped code.
The provider layer is genuinely extensible, and that’s the real differentiator
Where bolt.diy earns its “any LLM you want” tagline is the provider abstraction. Each supported LLM provider is implemented as its own class extending a shared BaseProvider, giving the project two distinct ways to expose models: static lists of pre-defined models that are always available, and dynamic model discovery that pulls the current list directly from a provider’s API at runtime. That’s why adding a new provider doesn’t require touching the core chat loop, and it’s why the project has been able to track new model releases (Claude 4 Opus, Grok 4, Kimi K2) as fast as the community writes provider classes for them.
This is the one area where bolt.diy is unambiguously more architecturally interesting than a typical hosted competitor. Lovable and Bolt.new pick a model for you. bolt.diy makes model choice a first-class, swappable concern, currently spanning 19 providers, extendable to anything the Vercel AI SDK supports.
The licensing detail almost nobody’s coverage catches
bolt.diy’s source code is MIT licensed, which means you can fork, modify, and redistribute the codebase freely.
That’s not the whole picture, though. bolt.diy’s own README is explicit that the WebContainers API it depends on requires a separate commercial license for production use in a for-profit setting. Prototypes and proof-of-concepts are exempt. Serving actual customers, prospective customers, or employees is not, according to the project’s own documentation.
That’s a meaningfully different claim than “fully open source, use it however you want,” and it’s the kind of detail that only shows up if you read past the license badge into the actual terms.
What this adds up to
bolt.diy is a well-engineered workaround for a genuinely hard constraint: running a full development environment with zero backend, entirely inside a browser tab. The provider architecture is the strongest part of the project and the clearest reason to fork it over alternatives. The system prompt is where the real complexity lives, and it reads less like a product spec and more like a running list of everything the sandbox has broken so far. And the multi-agent architecture that shows up in the project’s roadmap hasn’t shipped yet, which is worth knowing before you assume it’s already running underneath the interface.
If you’re evaluating this for anything beyond a prototype, read the WebContainers licensing terms before you build a business plan on top of “it’s MIT, so it’s free.”
Sources: bolt.diy GitHub repository (stackblitz-labs/bolt.diy), including README, LICENSE, FAQ documentation, project roadmap, and app/lib/common/prompts/prompts.ts.