Run Bolt.diy Locally with Ollama: Free v0 Alternative

Why I Ditched Cloud Subscriptions for Local AI Web Generation

Related: Kokoro TTS in Open WebUI: Zero-Latency Local Voice Setup →

My monthly SaaS bill for AI coding tools hit $110 recently. I was paying $20 for Cursor, $20 for v0, $20 for Claude Pro, and eating another $50 in pay-as-you-go API costs on Bolt.new when building complex web application prototypes. The final straw came during a late-night session when Bolt.new burnt through $14 worth of Anthropic API tokens in under twenty minutes because it kept re-rendering a broken Tailwind layout in a loop.

That led me down the rabbit hole of running Bolt.diy locally. Bolt.diy is an open-source, community-driven fork of Bolt.new. It retains the browser-based WebContainer architecture, full-stack preview pane, and interactive code modification features, but removes the reliance on paid cloud endpoints.

When paired with Ollama and Alibaba's Qwen 2.5 Coder model, you get a zero-cost local engine capable of building full React applications, Express backends, and interactive dashboards right on your consumer hardware. There are no rate limits, no per-token billing, and no remote servers inspecting your code.

It is not a magic solution without trade-offs. Running full-stack AI generators locally demands substantial VRAM, carefully tuned context parameters, and realistic expectations regarding generation speed. Here is my complete, hands-on blueprint for setting up, optimizing, and troubleshooting a local Bolt.diy environment with Ollama.

Hardware Requirements and Model Sizes

Related: Connect Windsurf IDE to Local Ollama: Step-by-Step Setup →

Running Bolt.diy with Ollama requires simultaneous execution of two distinct workloads: the local LLM inference engine and the Node.js/WebContainer browser runtime.

The primary bottleneck is VRAM. Small language models like qwen2.5-coder:7b can generate simple HTML/JS fragments on entry-level GPUs, but full-stack app creation requires understanding multi-file project architecture, routing, and dependency management. That demands larger parameters and expanded context windows.

Here is what you need based on actual benchmarking across different system setups:

On my primary Linux rig equipped with a single RTX 4090 (24GB VRAM), qwen2.5-coder:14b is the sweet spot. It leaves enough VRAM headroom to expand the context window up to 32,768 tokens without running out of memory.

If you attempt to run qwen2.5-coder:32b on a 24GB card with a 32k context window, Ollama will offload several layers to system RAM, causing generation speed to drop from 22 tokens per second to under 4 tokens per second. For interactive web builders, slow generation breaks the development feedback loop.

Step-by-Step Setup: Installing Ollama, Qwen, and Bolt.diy

Related: Fix Open WebUI Web Search: SearXNG Docker Guide →

Setting up this stack requires three components: the Ollama backend, a customized Qwen model with an enlarged context window, and the local Bolt.diy web interface.

Step 1: Configure Ollama Environment Variables

First, install Ollama from the official website or via package manager. Before launching it, you must configure environment variables to allow cross-origin requests from the browser interface where Bolt.diy runs.

On Linux or macOS, open your shell profile (~/.zshrc or ~/.bashrc) and add:

export OLLAMA_ORIGINS="*"
export OLLAMA_NUM_PARALLEL=1

On Windows, open System Environment Variables and set OLLAMA_ORIGINS to *. Without this step, Bolt.diy will throw silent FETCH_ERROR exceptions in your browser console due to strict CORS policies enforced by default inside Ollama.

Restart your terminal or run source ~/.zshrc to apply the changes, then launch Ollama:

ollama serve

Step 2: Create a Custom Model with Expanded Context

By default, Ollama initializes models with a modest 2,048 or 4,096 token context window. Generating a full React app require reading package definitions, system prompts, component hierarchies, and CSS configurations. A 4k context window causes the model to lose track of earlier files midway through generation.

We need to build a custom Modelfile using qwen2.5-coder:14b (or 32b if you have 32GB+ VRAM).

Create a file named Modelfile in any directory:

FROM qwen2.5-coder:14b

Set context window to 32,768 tokens

PARAMETER num_ctx 32768

Lower temperature slightly for deterministic code structure

PARAMETER temperature 0.2 PARAMETER top_p 0.95

Run the build command inside the terminal:

ollama create qwen2.5-coder-32k -f Modelfile

Verify that the newly created model is loaded and available:

ollama list

Step 3: Clone and Prepare Bolt.diy

Ensure you have Node.js version 20.18.0 or higher installed. Bolt.diy utilizes pnpm as its package manager.

Open your terminal and execute:

git clone https://github.com/stackblitz-labs/bolt.diy.git
cd bolt.diy
npm install -g pnpm
pnpm install

Next, copy the environment template to create a local environment configuration:

cp .env.example .env.local

Open .env.local in a text editor. Ensure the default provider options include Ollama. You can explicitly set the local base URL if needed, though Bolt.diy defaults to http://127.0.0.1:11434:

DEFAULT_NUM_CTX=32768
OLLAMA_API_BASE_URL=http://127.0.0.1:11434

Start the local development server:

pnpm run dev

Navigate your browser to http://localhost:5173.

Step 4: Connecting Bolt.diy to Your Local Ollama Engine

1. In the Bolt.diy browser interface, click the Settings gear icon in the lower-left corner.
2. Select Providers and scroll down to Ollama.
3. Toggle Ollama to Enabled.
4. Set the API URL to http://127.0.0.1:11434.
5. Return to the main chat screen. In the provider dropdown menu above the chat box, select Ollama.
6. Select your custom model: qwen2.5-coder-32k.

Your local, unlimited web development workspace is ready.

Local vs Cloud Web Builders: Performance Benchmark

Related: Open WebUI Ignoring Your Uploaded Documents? Fix It →

To test real-world capabilities, I challenged three setups to build the exact same project from scratch:

Prompt: "Build a dark-mode Kanban board in React using Tailwind CSS. Include drag-and-drop support, local storage persistence, task tagging, priority filtering, and an Express API mock for saving board state."

Here is how the local stack performed against cloud-hosted commercial services:

The results show clear performance characteristics. Claude 3.5 Sonnet on Bolt.new generates code three times faster and executes complex structural changes with fewer errors.

However, local execution using Qwen 2.5 Coder 14B reached 85% functional parity for zero financial cost. It created the full folder hierarchy (src/components/KanbanBoard.tsx, src/types/index.ts, src/hooks/useLocalStorage.ts), applied proper Tailwind classes, and provided a working drag-and-drop state structure.

What Broke During Testing and How to Fix It

Related: Make Ollama Start on Boot: A systemd Service That Works →

Building web apps using local LLMs is not always seamless. Here are the specific failure modes I encountered during hands-on testing and how to solve them.

1. WebContainers Fail to Execute "boltAction" Tags

CRITICAL: You must wrap file modifications strictly inside valid <boltAction> tags. Do not wrap <boltAction> tags inside Markdown code blocks. Output plain XML elements directly.

2. Browser CORS Connection Blocked

3. Out-of-Memory (OOM) Errors Mid-Generation

PARAMETER num_ctx 16384

Rebuild the model using ollama create and restart the stack.

4. Continuous Dependencies Loop

Optimizing Qwen 2.5 Coder for Web Code Generation

Related: Why Ollama's First Response Is Slow (Cold Start Fix) →

Qwen 2.5 Coder is currently the best open-weights coding model family available for local execution. To squeeze maximum performance out of it when running local web generation, apply these optimization adjustments.

Use the Proper Model Variant

Always use the Coder variant (qwen2.5-coder), not the base instruct model (qwen2.5). The base instruct model lacks training density for system-level web project abstractions and frequently hallucinates invalid package exports.

Fine-Tune Quantization Choice

If you have a GPU with 16GB VRAM, do not run qwen2.5-coder:14b with Q8_0 quantization. The negligible gain in accuracy causes severe context truncation when the KV cache expands. Stick to Q4_K_M or Q5_K_M.

Q4_K_M retains approximately 99% of the full precision coding benchmark scores while reducing VRAM memory requirements by nearly 40%.

Enforce Incremental Prompting

Local LLMs handle targeted scope better than massive architectural requests. Instead of prompting:

"Build a complete e-commerce store with authentication, Stripe payment processing, cart management, product filtering, and a backend dashboard."

Break your build down into concrete, step-by-step instructions:

1. "Build a baseline React app using Vite and Tailwind showing a product grid with local state data."
2. "Add a slide-over cart drawer that calculates item totals and stores state in React Context."
3. "Add a product filter sidebar with category checkboxes and price range sliders."

This incremental approach keeps the active context buffer structured, reduces generation latency, and prevents syntax degradation across multi-file outputs.

Frequently Asked Questions

Can I run Bolt.diy locally without a dedicated GPU?

Yes, but performance depends heavily on system architecture. On Apple Silicon Macs (M1/M2/M3/M4 with unified memory), CPU/GPU memory sharing allows Qwen 2.5 Coder 14B to generate code at usable speeds (15–30 tokens/sec) provided you have at least 16GB of unified RAM. On standard Intel/AMD x86 systems without a dedicated Nvidia GPU, running local models purely on CPU threads results in extremely slow generation speeds (1–3 tokens/sec), making real-time app creation impractical.

How does Qwen 2.5 Coder compare to Claude 3.5 Sonnet for building apps?

Claude 3.5 Sonnet remains superior at complex architectural reasoning, error resolution, and producing production-ready UI layouts on the first pass. However, qwen2.5-coder:32b reaches roughly 85–90% of Claude's capability on standardized coding benchmarks (HumanEval/MBPP) and local web generation tasks. For prototyping, internal tools, and rapid UI layout iteration, Qwen offer a completely free local alternative.

Why is Bolt.diy better than using standard ChatGPT or Ollama CLI?

Standard chat interfaces only output markdown code blocks that you must manually copy, paste, create directories for, and test locally. Bolt.diy provides a complete, browser-based IDE integrated with a WebContainer virtual engine. It automatically writes files directly to a virtual workspace, installs dependencies, runs dev servers, and displays a live, interactive preview pane alongside the chat interface in real time.

How much VRAM do I need to run a 32K context window smoothly?

To run qwen2.5-coder:14b at a 32,768 context window size with comfortable headroom, you need at least 16GB of VRAM (such as an Nvidia RTX 4080 / 4090 or a 32GB Apple Silicon Mac). To run qwen2.5-coder:32b at a 32K context window, you will need a minimum of 24GB–32GB of dedicated VRAM to prevent memory offloading to system RAM, which degrades inference speed.