Bolt.diy

What it is and how it works

Bolt.diy is a community-maintained fork of StackBlitz's bolt.new, the browser-based "prompt-to-app" tool that made a splash by letting users describe a web app in plain English and watch it get scaffolded, coded, and run in real time. The core engineering trick both tools share is WebContainer — StackBlitz's in-browser Node.js runtime that boots an actual filesystem, package manager, and dev server inside a WebAssembly sandbox running in the browser tab itself. No Docker container, no remote VM: npm install, a Vite dev server, and a live preview all execute client-side. That's what makes the "sandboxed execution" claim genuine rather than marketing — the generated code never touches the host OS directly, and a bad LLM-generated rm -rf or infinite loop is contained to the WebContainer's virtual filesystem and process space.

What bolt.diy bolts onto that foundation is model flexibility. bolt.new is hard-wired to Anthropic's models through StackBlitz's hosted backend. The fork rips out that constraint and adds a provider abstraction layer supporting a long list of backends — Ollama, LM Studio, and any OpenAI-compatible endpoint sit alongside hosted options like OpenAI, Anthropic, Groq, and OpenRouter. The agent loop itself is fairly conventional for this class of tool: the LLM receives a system prompt describing the WebContainer environment and available actions (write file, run shell command, install package), the model responds with a sequence of file writes and commands, the fork's runtime executes them against the WebContainer, and the loop continues with the dev server's output and any errors fed back to the model for the next iteration. There's no separate retrieval or planning stage — it's a fairly direct chat-to-action loop, which is part of why model quality on multi-step reasoning shows up quickly in output quality.

Because the whole pipeline — model call, code generation, file writes, execution — happens through a single web UI, the "local" part of local-LLM support is really about where the model runs, not where the code runs. The WebContainer sandbox is always browser-side regardless of backend; pointing the model config at Ollama just means the token generation happens on your own GPU/CPU instead of a hosted API.

Deployment patterns

The overwhelmingly common deployment is a single developer or hobbyist running it on one machine: clone the repo, pnpm install, run the dev server, open the local URL in a browser, and point the model provider dropdown at a local Ollama instance (or LM Studio's OpenAI-compatible server) running on the same box. This is a laptop-scale tool by default — there's no multi-user session management, no queueing, no persistent backend database beyond browser storage for chat history and settings.

For a homelab setup, the natural pattern is running Ollama (or vLLM/llama.cpp server for better throughput) on a separate GPU box on the LAN and pointing bolt.diy's provider config at that machine's IP instead of localhost — this decouples the WebContainer/UI process (lightweight, CPU-only) from the model-serving process (GPU-bound), which matters because bolt.diy itself has negligible resource needs; all the heavy lifting is the LLM inference happening wherever the endpoint you configured actually lives.

There isn't a well-established "team server" deployment pattern for bolt.diy the way there is for, say, a self-hosted Continue.dev proxy or a shared LiteLLM gateway. It can technically be deployed to a shared host (it's a standard Node/Vite web app, deployable to a VPS or container), but you'd be exposing a code-execution UI to multiple users sharing one browser session's WebContainer semantics, which isn't what it was built for. Most teams that want shared local-LLM coding infrastructure reach for terminal-based agents with proper multi-session handling instead.

How it compares

Against Aider, the comparison is scope, not quality. Aider is a terminal-based pair-programming agent that edits real files in a real git repo, works across any language or project type, and integrates diff-based edits with commit messages. Bolt.diy only understands the WebContanier's Node/React/Vue/Svelte world and only produces browser-previewable web apps — you can't point it at a Python data pipeline or a Rust CLI. Aider is the tool for ongoing work on an existing codebase; bolt.diy is the tool for spinning up a new frontend from nothing and seeing it render immediately.

Against Cline (the VS Code extension agent), bolt.diy trades editor integration and filesystem access for zero-setup sandboxing. Cline operates directly on your real project files inside your real editor, can shell out to your real terminal, and has no category restriction — but that also means a wayward agent action touches your actual disk. Bolt.diy's WebContainer isolation is safer for experimentation and demos but means you eventually have to export/download the generated project to do anything with it outside the browser.

Against v0 (Vercel's prompt-to-UI tool) and the original bolt.new, bolt.diy's differentiator is purely the open-source, self-hostable, bring-your-own-model angle — v0 and bolt.new are slicker, better-integrated hosted products with no local-model option at all.

Best use cases and honest limitations

Bolt.diy earns its place as the single best "watch local AI actually build something" demo available in this space — prompting a local Qwen or DeepSeek-Coder model through Ollama and watching a real React app materialize and run in-browser lands with non-technical audiences in a way that a terminal diff never will. It's also genuinely useful for fast frontend prototyping when you already know you want a standard Node/React/Vue/Svelte stack.

The limitations are real and match the provided cons closely. It's confined to web-app generation — no CLI tools, no backend-only services, no Python/Rust/Go projects. Full-stack reasoning (routing, state management, API wiring, multi-file consistency) is demanding, and models under roughly 14B parameters visibly struggle to keep the whole app coherent past the first couple of prompts; this is a tool that rewards pointing at your best available model, local or hosted, not your fastest one. And because it's a community fork tracking upstream bolt.new changes plus its own provider integrations, the commit history moves quickly and occasionally breaks — anyone deploying it for something recurring rather than a one-off demo should pin a specific commit rather than tracking main.