Self-hosted Lovable alternative: Dyad, bolt.diy and OpenHands on your own RTX PRO GPU

Prompt to app on your own workstation

A self-hosted Lovable alternative that runs locally is an open-source app builder such as Dyad, connected to an open model in Ollama on a workstation with an NVIDIA RTX PRO Blackwell card. You describe the app in plain language, the builder writes the code and shows a live preview, and the prompts and the code are processed on that machine. By our users-per-card rule, the smallest card that holds a capable 27B coding model with the context these tools need is the 32 GB RTX PRO 4500 Blackwell.

Lovable's documentation, read on 30 October 2026, describes it as "a full-stack AI development platform for building, iterating on, and deploying web applications", whose apps include "frontend, backend, database, authentication, and integrations, all backed by editable code". Projects live in workspaces, apps are published to a live URL, the code can be synced to GitHub, GitLab or Bitbucket, and EU inference for AI model requests is listed as a governance feature. The documentation says nothing about running Lovable on your own hardware. With a local builder, the model runs on your workstation and the prompts and source code are processed there; in exchange you provide what Lovable bundles: hosting, a database and sign-in for the finished app.

This page compares the open tools, the model each one needs and the card that runs it. How close the local models come to Claude is the subject of our article on whether a local model is good enough for vibe coding, and the hardware kits are set out in full in our guide to the vibe coding workstation.

Dyad, bolt.diy, OpenHands and open-lovable compared

Four open projects come up when people search for a Lovable or Bolt alternative that runs locally. They differ in how they run, in licence and in how far they work without a cloud service.

GitHub repository and release pages of each project, the WebContainers licensing page, Dyad's blog post of 4 February 2026 on local AI coding and the OpenHands guide to local LLMs, all read on 30 October 2026.

Dyad describes itself in its README as "a local, open-source AI app builder", "like Lovable, v0, or Bolt, but running right on your machine". It runs on Mac and Windows, and its September 2026 release also ships Linux packages (.deb, .rpm and AppImage). Code outside the src/pro folder is under Apache 2.0, code inside it under the Functional Source License 1.1. Dyad's own guide to local coding, published on 4 February 2026, explains the local setup: Dyad finds Ollama on localhost:11434 by itself, uses a custom OLLAMA_HOST if one is set, needs no API key, and reaches LM Studio on localhost:1234. The same guide still names Qwen 2.5 Coder 14B and 32B for the best local results and warns that "Smaller models (under 7B parameters) often struggle to follow structured output formats". Its September 2026 release notes add the creation of a Supabase project from a database connector.

bolt.diy is the open-source project of StackBlitz Labs, forked from Bolt.new, to "Prompt, run, edit, and deploy full-stack web applications using any LLM you want". It lists more than 22 model providers, among them Ollama and LM Studio through OLLAMA_BASE_URL and LMSTUDIO_BASE_URL, and installs with pnpm (Node.js 22.12.0 or later), with Docker, or as an Electron desktop app for Windows, macOS and Linux. Its README states that ongoing work covers bug fixes, dependency updates and reliability, and that no new features are planned. The generated app runs in WebContainers, the Node.js environment inside the browser that the README names, and the README notes that the WebContainers API "has specific commercial licensing terms for enterprise deployment". StackBlitz's WebContainers licensing page, read on 30 October 2026, is plainer: "Licensing is required for production usage of the API in a commercial, for-profit setting", while "Prototypes or POCs do not require a commercial license". A company that runs its working tools through bolt.diy therefore needs that licence, and for this reason we do not deliver bolt.diy preinstalled. The README does not say whether the runtime contacts outside servers either; check it once with the workstation's outbound traffic blocked.

OpenHands calls itself "the self-hosted developer control center for coding agents and automations". It is an agent that edits files and runs commands in a Docker sandbox, closer to an autonomous developer than to Lovable's preview loop. Its guide to local LLMs recommends Qwen3.6-35B-A3B, which it says "is optimized for agentic coding", asks for a GPU with at least 24 GB for quantised variants and a context of at least 22,000 tokens, 32,768 for better performance, and gives vLLM and SGLang examples that assume two GPUs.

open-lovable from Firecrawl lets you "Chat with AI to build React apps instantly". Its README requires a Firecrawl API key, an API key for Gemini, Anthropic, OpenAI or Groq, and a Vercel Sandbox or E2B account, and it documents no local model and no local sandbox. As documented, it does not run without cloud services.

For a non-developer who builds internal tools, Dyad's desktop app is the shortest path. bolt.diy suits a trial or a proof of concept, which StackBlitz's licensing page exempts; once a team uses it in daily work for customers or employees, the page requires a WebContainers licence, and the project receives fixes but no new features. OpenHands handles longer tasks that need a terminal. Terminal agents such as Claude Code or OpenCode with a local model are covered in our guide to Claude Code with a local model, and what happens when Cursor is pointed at a local server in our article on Cursor with a local model.

Which local model builds working apps

Each step of a builder or agent is a model call that carries the task so far: the instructions, the files read, the error output and the earlier steps, as our coding-assistant guide describes. That needs a long context. Ollama's announcement of ollama launch (23 January 2026) asks for "at least 64000 tokens" for coding tools, and the OpenHands guide warns that 4,096 tokens are too small for its system prompt and that the agent will not behave correctly with them; Ollama's own default is 4K only below 24 GiB of GPU memory and 32K or 256K above, so set the context explicitly.

Download sizes of the q4_K_M and q8_0 tags in Ollama's library and licences from the Hugging Face model cards, read on 30 October 2026; gpt-oss-20b from our coding-assistant guide.

Qwen3.8-27B is the newest of these and, by Qwen's own table, scores 61.7 on SWE-bench Pro against 53.5 for Qwen3.6-27B, and 73.0 against 63.4 on Terminal Bench 2.1. For front-end work, the closest benchmark to an app builder is QwenWebBench, Qwen's internal front-end generation benchmark: the Qwen3.6 card gives 1,487 for the 27B and 1,397 for the 35B-A3B. These are vendor figures. Qwen3.6-35B-A3B, a mixture-of-experts (MoE) model, computes only about 3B of its 35B parameters per token and, by our arithmetic, answers several times faster than a dense model, which suits quick iterations on a layout. Qwen3.8-27B thinks by default, at its highest reasoning effort, so each change starts with a reasoning phase; the model card offers medium and low effort for faster answers. GLM-4.7-Flash, another of Ollama's suggestions for coding tools, needs "~23 GB VRAM" at 64,000 tokens of context by Ollama's figure.

You can order the workstation alone, the setup of Ollama, Qwen3.8-27B and Dyad or OpenHands alone, or both together: the workstation delivered with everything installed and configured; write to us and we suggest the best solution for your tasks and budget.

Which RTX PRO card for one maker or a studio

Memory sets the tier. Our users-per-card rule takes 90 per cent of the memory the driver reports and subtracts 3 GiB per card, as our guide to how many users one RTX PRO 6000 serves explains. Beside the weights, each open session needs its key-value cache, the memory where the model keeps the context it has read. Qwen3.8-27B keeps that cache in 16 of its 64 layers: by our arithmetic from its config.json, 64 KiB per token in 16-bit, so 8 GiB for 128K tokens, plus about 0.14 GiB of fixed state per session. Qwen3.6-35B-A3B needs 20 KiB per token, 1.3 GiB per 64K session. We size with Ollama's default 16-bit cache; an FP8 cache, as vLLM offers it, halves the per-token figures.

Our estimates by the users-per-card rule (0.9 × driver-visible memory − 3 GiB per card), weights from the Ollama tags above converted to GiB, Ollama's default 16-bit cache; not measurements. RTX PRO 4500 and 5000 driver memory scaled from the 95.6 GiB of a 96 GB card. The RTX PRO 6000 Workstation Edition (600 W) has the same 96 GB and gives the same counts as the Max-Q (300 W).

One session is one agent conversation held in memory. A maker who is working holds one; a second builder window or a background task holds another. On the RTX PRO 4500, Qwen3.8-27B at 4-bit leaves 8.9 GiB, one session of 128K or two of 64K; Qwen3.6-35B-A3B at 4-bit leaves 3.3 GiB, two sessions of 64K. A 24 GB RTX PRO 4000 keeps 18.5 GiB by the same rule: 1.7 GiB beside Qwen3.8-27B at 4-bit, less than one 64K session, and GLM-4.7-Flash's 23 GB by Ollama's figure exceeds it. On 24 GB, gpt-oss-20b with three sessions of 64K is the realistic choice, as our page on 30B models on 24 GB cards shows for the MoE models.

The 48 GB RTX PRO 5000 holds Qwen3.8-27B at 8-bit with one 128K session; the 72 GB version holds four. One RTX PRO 6000 Max-Q or Workstation Edition runs the model in 16-bit, or Qwen3-Coder-Next in FP8 (80.4 GB) with five sessions of 64K. Two RTX PRO 6000 Max-Q cards, 300 W each, give a small studio one model copy per card. NVIDIA states up to four Max-Q per workstation; three or four belong only in a chassis built for them with strong directed airflow, and two Workstation Editions at 600 W are the realistic maximum for that edition.

For one request, StorageReview's review of 14 October 2026 measured Qwen3.8-27B in NVIDIA's NVFP4 format with vLLM at 17 to 22 tokens per second on every card that ran it, from the RTX PRO 4500 Blackwell Server Edition to an RTX PRO 6000 Workstation Edition, as our guide to the vibe coding workstation reports. By our arithmetic from the memory bandwidth NVIDIA states, the 8-bit model, which reads about 28 GB of weights per token, tops out at about 63 tokens per second on an RTX PRO 6000 Workstation Edition; real speeds are lower, and agent contexts are far longer than a short test prompt.

Setting up Dyad or OpenHands with Ollama

The software stack is short. The steps below follow the projects' own guides as of October 2026.

1. Install Ollama 0.35.0 or later; earlier versions are affected by CVE-2026-103663, as our coding-assistant guide records. Ollama is MIT-licensed and actively developed as of October 2026. Set OLLAMA_NO_CLOUD=1, which removes Ollama's cloud models and web search, as its FAQ describes, so that prompts and code stay on the workstation.
2. Set the context length to at least 64,000 tokens in Ollama's settings or with OLLAMA_CONTEXT_LENGTH; use 128K where the table above leaves room. For more than one session at a time, also raise OLLAMA_NUM_PARALLEL, since Ollama answers one request per model at a time by default.
3. Pull the model, for example ollama pull qwen3.8:27b (the 18 GB default tag) or qwen3.6:35b-a3b.
4. Install the builder: Dyad's desktop app, which detects Ollama, or OpenHands, whose guide to local LLMs shows the Ollama setup. bolt.diy takes OLLAMA_BASE_URL for a trial; daily use in a company needs the WebContainers licence first.
5. Keep the model server on the workstation. Ollama listens on 127.0.0.1 by default, but its container image sets OLLAMA_HOST=0.0.0.0, and the OpenHands examples bind to 0.0.0.0 so that its container can reach the server. Block that port at the firewall, as our guide to securing a GPU server describes.
6. Check what each tool sends out by default; our article on telemetry in self-hosted AI tools covers the server side.

Where the finished app runs

A local builder produces source code and a preview, and the place where the finished app runs is a separate decision. bolt.diy offers one-click deployment to Netlify, Vercel and GitHub Pages, all of them cloud services, and Dyad links apps to Supabase or Neon through its documented integrations. For an internal tool with customer or staff data, the app usually runs on a server in your own network with your own sign-in, and the database stays there too. Before colleagues or customers use it, our security checks for vibe-coded apps list what to test. Our guide to building internal tools with AI, without developers covers that path for office and operations teams, and our guide to local AI and the GDPR explains what own hosting settles and what stays your duty.

When several people build at once, the builders can stay on each person's PC while the model moves to a shared machine on the network, which then needs access control. For 20 to 100 developers with agents, a rack server is the better home for the model, as our guide to a server for coding agents shows; the step from a single PC to a company server is described in from Ollama on a PC to a company AI server.

Send us a few lines on the apps you want to build and we suggest the configuration that fits your team and budget.

FAQ