bolt.diy: Self-Hostable Open-Source Bolt.new With Any LLM

AIBoltLovableGitHub

bolt.diy (~20k stars) is the community open-source path for a Bolt.new-style experience: prompt full-stack apps in the browser, run them in a sandbox, iterate in chat, and bring any LLM you want. It previously lived under names like bolt.new-any-llm and other StackBlitz Labs experiments — always confirm the canonical stackblitz-labs/bolt.diy URL before linking in docs or courses.

Rename history and why it matters

The Bolt ecosystem fragmented quickly: commercial bolt.new, StackBlitz’s WebContainer magic, and community forks that added provider choice. Bookmark rot is real — students still clone repos that say “any-llm” but point to stale remotes. Your team README should cite github.com/stackblitz-labs/bolt.diy and pin a commit SHA for workshops.

What bolt.diy gives you

  • Browser-based builder UI familiar to anyone who tried Bolt.new or Lovable
  • Model flexibility — OpenAI, Anthropic, Ollama, OpenRouter, etc., depending on config
  • Self-hosting for teams that cannot use hosted vibe-coding SaaS
  • Teachable internals — see how prompts, file trees, and dev servers wire together
  • Escape hatch — export or copy the generated project and keep building locally

Typical self-hosted setup

Follow the repo README — env var names change between releases. A common pattern:

Bash
git clone https://github.com/stackblitz-labs/bolt.diy.git
cd bolt.diy
pnpm install
cp .env.example .env
# Add provider keys + optional Ollama base URL
pnpm dev

You need Node 18+ (or whatever the README specifies) and at least one LLM endpoint. For demos without cloud spend, point at a local Ollama model — quality drops, but workshops stay free. Production teaching usually needs a capable frontier model for multi-file coherence.

Workflow: prompt → run → eject

  1. Describe the app — scope small: “todo list with dark mode” not “Uber for plants”
  2. Let the sandbox install deps — watch for hallucinated package names
  3. Iterate in chat — UI tweaks, add API route, fix layout
  4. Snapshot to Git early — export zip or push to a new repo
  5. Eject to local IDE — continue with Aider, Cline, or Cursor
  6. Wire real backend — usually Supabase for auth and Postgres
  7. Rebase onto a clean starter if the generated tree is messy — see the Lovable stack

bolt.diy vs commercial Bolt vs Open Lovable

bolt.new (hosted) optimizes for instant gratification with StackBlitz’s infra — less ops, less control. bolt.diy trades setup time for keys-you-own and customization. Open Lovable emphasizes cloning existing sites via Firecrawl scrape + chat, not only greenfield prompts. Pick bolt.diy when your curriculum is “understand Bolt-like builders” or when compliance requires self-host.

Best practices

  • Pin dependencies after export — generated apps may use floating ranges
  • Add ESLint/TypeScript strict post-export before production
  • Replace inline secrets with env vars — builders love demo keys in source
  • Run security review before exposing self-hosted instances to the public internet
  • Teach limits — builders excel at CRUD UI, struggle with complex domain logic

WordPress angle

bolt.diy is not a WordPress replacement. Typical agency pattern: prototype a React marketing app in bolt.diy, keep editorial content in WordPress + ACF, and bridge with headless APIs or embedded islands. For bulk ACF text edits on the WP side, use Quickfields — do not ask the builder to “generate a WordPress plugin” for content ops unless you plan to maintain PHP.

Risks

  • Exposed admin instances — self-hosted builders can become expensive prompt injection playgrounds if left wide open
  • Token cost spikes during naive student loops
  • Vendor assets — generated UI may pull random CDNs
  • Stale forks — tutorials pointing at old bolt.new-any-llm repos

FAQ

Is bolt.diy official StackBlitz? It lives under StackBlitz Labs on GitHub — related spirit, community-maintained path; read the README license and support expectations.

Can I use only local models? Yes with Ollama-compatible config — expect more iteration cycles.

Does output match Lovable? Similar vibe (React, Tailwind often), but export hygiene varies — always review.

What after bolt.diy? Production path = Git + proper CI + understanding codegen history without staying in the sandbox.

Hosting bolt.diy for a team

Self-hosting means you own uptime, TLS, and auth. Put bolt.diy behind SSO or VPN for internal hack weeks; never expose an unauthenticated instance to the public internet unless you enjoy surprise cloud bills. Run behind reverse proxy with rate limits, separate API keys per engineer, and nightly teardown of idle sandboxes. Log prompt metadata for cost allocation per project.

Curriculum: teaching with bolt.diy

Day one: prompt a todo app, discuss hallucinated dependencies. Day two: export to Git, add ESLint, run tests. Day three: connect Supabase auth. Day four: compare output with Open Lovable on the same spec. Day five: refactor in Aider — teach that builders start apps; engineers maintain them. Mention the rename from bolt.new-any-llm so students bookmark the right repo.

When bolt.diy is the wrong tool

Skip it for mature brownfield repos with years of custom architecture — use IDE agents instead. Skip it for WordPress plugin maintenance. Skip it when compliance forbids browser-based code execution altogether. Reach for it when you need a self-hosted Bolt.new demo with your own model contract.

Integration with the Lovable stack

Most bolt.diy exports land close to the Vite + React + Tailwind + shadcn convention — on purpose. After export, diff your tree against a clean shadcn starter: delete duplicate utils, align components/ui imports, and move env vars into .env.local with Zod validation. Then wire Supabase keys per our Supabase companion post. The builder gets you to 70%; normalization gets you to something mergeable.

Repo

github.com/stackblitz-labs/bolt.diy