Lovable-Alternative selbst gehostet: Dyad, bolt.diy und OpenHands auf Ihrer RTX PRO GPU

Vom Prompt zur App auf der eigenen Workstation

Eine selbst gehostete Lovable-Alternative, die lokal ohne Cloud läuft, ist ein Open-Source-KI-App-Builder wie Dyad, verbunden mit einem offenen Modell in Ollama auf einer Workstation mit einer NVIDIA RTX PRO Blackwell. Sie beschreiben die App in normaler Sprache, der Builder schreibt den Code und zeigt eine Live-Vorschau, und Prompts wie Code werden auf diesem Rechner verarbeitet. Nach unserer Regel für Nutzer je Karte ist die kleinste Karte, die ein leistungsfähiges 27B-Coding-Modell mit dem nötigen Kontext aufnimmt, die RTX PRO 4500 Blackwell mit 32 GB.

Die Dokumentation von Lovable, gelesen am 30. Oktober 2026, beschreibt das Angebot als „a full-stack AI development platform for building, iterating on, and deploying web applications“, deren Apps „frontend, backend, database, authentication, and integrations, all backed by editable code“ enthalten. Projekte liegen in Workspaces, Apps werden unter einer Live-URL veröffentlicht, der Code lässt sich mit GitHub, GitLab oder Bitbucket synchronisieren, und EU-Inferenz für Modellanfragen ist als Governance-Funktion aufgeführt. Zum Betrieb von Lovable auf eigener Hardware sagt die Dokumentation nichts. Mit einem lokalen Builder läuft das Modell auf Ihrer Workstation, und Prompts und Quellcode werden dort verarbeitet; dafür stellen Sie selbst bereit, was Lovable mitliefert: Hosting, Datenbank und Anmeldung für die fertige App.

Dieser Artikel vergleicht die offenen Werkzeuge, das Modell, das jedes braucht, und die Karte, auf der es läuft. Wie nah die lokalen Modelle an Claude herankommen, behandelt unser Artikel Reicht ein lokales Modell fürs Vibe Coding?, die Hardware-Pakete im Detail unser Leitfaden zur Vibe-Coding-Workstation.

Dyad, bolt.diy, OpenHands und open-lovable im Vergleich

Vier offene Projekte tauchen auf, wenn Unternehmen eine Lovable- oder Bolt-Alternative suchen, die lokal läuft. Sie unterscheiden sich darin, wie sie laufen, in der Lizenz und darin, wie weit sie ohne Cloud-Dienst auskommen.

GitHub-Repository und Release-Seiten der Projekte, die Lizenzseite von WebContainers, Dyads Blogbeitrag vom 4. Februar 2026 zu lokalem KI-Coding und der OpenHands-Leitfaden zu lokalen LLMs, alle gelesen am 30. Oktober 2026.

Dyad beschreibt sich in seiner README als „a local, open-source AI app builder“, „like Lovable, v0, or Bolt, but running right on your machine“. Es läuft unter Mac und Windows, und das Release vom September 2026 enthält zusätzlich Linux-Pakete (.deb, .rpm und AppImage). Code außerhalb des Ordners src/pro steht unter Apache 2.0, Code darin unter der Functional Source License 1.1. Dyads eigener Leitfaden zum lokalen Coding vom 4. Februar 2026 erklärt die Einrichtung: Dyad findet Ollama auf localhost:11434 selbst, nutzt ein gesetztes OLLAMA_HOST, braucht keinen API-Schlüssel und erreicht LM Studio auf localhost:1234. Derselbe Leitfaden nennt für die besten lokalen Ergebnisse noch Qwen 2.5 Coder 14B und 32B und warnt, „Smaller models (under 7B parameters) often struggle to follow structured output formats“. Die Release Notes vom September 2026 ergänzen das Anlegen eines Supabase-Projekts über einen Datenbank-Connector.

bolt.diy ist das Open-Source-Projekt von StackBlitz Labs, abgeleitet von Bolt.new, um „Prompt, run, edit, and deploy full-stack web applications using any LLM you want“. Es nennt mehr als 22 Modellanbieter, darunter Ollama und LM Studio über OLLAMA_BASE_URL und LMSTUDIO_BASE_URL, und lässt sich mit pnpm (Node.js 22.12.0 oder neuer), mit Docker oder als Electron-Desktop-App für Windows, macOS und Linux installieren. Die README hält fest, dass die laufende Arbeit Fehlerbehebungen, Aktualisierungen von Abhängigkeiten und Zuverlässigkeit betrifft und keine neuen Funktionen geplant sind. Die erzeugte App läuft in WebContainers, der Node.js-Umgebung im Browser, die die README nennt, und die README weist darauf hin, dass die WebContainers-API „has specific commercial licensing terms for enterprise deployment“. Die Lizenzseite von StackBlitz zu WebContainers, gelesen am 30. Oktober 2026, wird deutlicher: „Licensing is required for production usage of the API in a commercial, for-profit setting“, während „Prototypes or POCs do not require a commercial license“. Ein Unternehmen, das seine produktiven Werkzeuge über bolt.diy betreibt, braucht also diese Lizenz, und deshalb liefern wir bolt.diy nicht vorinstalliert aus. Ob die Laufzeitumgebung externe Server kontaktiert, sagt die README ebenfalls nicht; prüfen Sie es einmal mit gesperrtem ausgehendem Verkehr der Workstation.

OpenHands nennt sich „the self-hosted developer control center for coding agents and automations“. Es ist ein Agent, der Dateien bearbeitet und Befehle in einer Docker-Sandbox ausführt, näher an einem selbstständig arbeitenden Entwickler als an der Vorschau-Schleife von Lovable. Sein Leitfaden zu lokalen LLMs empfiehlt Qwen3.6-35B-A3B, das „is optimized for agentic coding“, verlangt für quantisierte Varianten eine GPU mit mindestens 24 GB und einen Kontext von mindestens 22.000 Token, für bessere Leistung 32.768, und zeigt Beispiele für vLLM und SGLang, die zwei GPUs voraussetzen.

open-lovable von Firecrawl soll „Chat with AI to build React apps instantly“ ermöglichen. Die README verlangt einen Firecrawl-API-Schlüssel, einen API-Schlüssel für Gemini, Anthropic, OpenAI oder Groq sowie ein Konto bei Vercel Sandbox oder E2B, und sie dokumentiert weder ein lokales Modell noch eine lokale Sandbox. So wie dokumentiert, läuft es nicht ohne Cloud-Dienste.

Wer ohne Entwicklerkenntnisse interne Werkzeuge baut, kommt mit der Desktop-App von Dyad am schnellsten ans Ziel. bolt.diy eignet sich für einen Test oder einen Machbarkeitsnachweis, für die die Lizenzseite von StackBlitz keine Lizenz verlangt; setzt ein Team es im Arbeitsalltag für Kunden oder Beschäftigte ein, verlangt sie eine WebContainers-Lizenz, und das Projekt erhält nur noch Korrekturen, keine neuen Funktionen. OpenHands übernimmt längere Aufgaben, die ein Terminal brauchen. Terminal-Agenten wie Claude Code oder OpenCode mit lokalem Modell behandelt unser Leitfaden Claude Code mit lokalem Modell, und was geschieht, wenn Cursor auf einen lokalen Server zeigt, unser Artikel Cursor mit lokalem Modell.

Welches lokale Modell funktionierende Apps baut

Jeder Schritt eines Builders oder Agenten ist ein Modellaufruf, der die bisherige Aufgabe mitträgt: die Anweisungen, die gelesenen Dateien, die Fehlerausgaben und die früheren Schritte, wie unser Leitfaden zum Coding-Assistenten beschreibt. Das braucht einen langen Kontext. Ollamas Ankündigung von ollama launch vom 23. Januar 2026 verlangt für Coding-Tools „at least 64000 tokens“, und der OpenHands-Leitfaden warnt, dass 4.096 Token für seinen Systemprompt zu klein sind und der Agent damit nicht richtig arbeitet; Ollamas eigene Vorgabe liegt nur unter 24 GiB GPU-Speicher bei 4K, darüber bei 32K oder 256K, setzen Sie den Kontext deshalb ausdrücklich.

Downloadgrößen der Tags q4_K_M und q8_0 in Ollamas Bibliothek und Lizenzen aus den Modellkarten auf Hugging Face, gelesen am 30. Oktober 2026; gpt-oss-20b aus unserem Leitfaden zum Coding-Assistenten.

Qwen3.8-27B ist das neueste dieser Modelle und erreicht nach Qwens eigener Tabelle 61,7 Punkte im SWE-bench Pro gegenüber 53,5 für Qwen3.6-27B sowie 73,0 gegenüber 63,4 im Terminal Bench 2.1. Für Frontend-Arbeit kommt QwenWebBench, Qwens interner Benchmark für Frontend-Generierung, einem App-Builder am nächsten: Die Karte von Qwen3.6 nennt 1.487 für das 27B- und 1.397 für das 35B-A3B-Modell. Das sind Herstellerangaben. Qwen3.6-35B-A3B, ein Mixture-of-Experts-Modell (MoE), rechnet je Token nur rund 3B seiner 35B Parameter und antwortet nach unserer Rechnung um ein Mehrfaches schneller als ein dichtes Modell, was zu schnellen Änderungen an einem Layout passt. Qwen3.8-27B denkt standardmäßig mit der höchsten Stufe von reasoning_effort, sodass jede Änderung mit einer Denkphase beginnt; die Modellkarte nennt die Stufen medium und low für schnellere Antworten. GLM-4.7-Flash, ein weiterer Vorschlag von Ollama für Coding-Tools, braucht nach Ollamas Angabe „~23 GB VRAM“ bei 64.000 Token Kontext.

Sie können die Workstation allein bestellen, die Einrichtung von Ollama, Qwen3.8-27B und Dyad oder OpenHands allein oder beides zusammen: die Workstation mit allem fertig installiert und eingerichtet; schreiben Sie uns, wir schlagen Ihnen die beste Lösung für Ihre Aufgaben und Ihr Budget vor.

Welche RTX PRO für eine Person oder ein Studio

Der Speicher bestimmt die Stufe. Unsere Regel für Nutzer je Karte nimmt 90 Prozent des Speichers, den der Treiber meldet, und zieht je Karte 3 GiB ab, wie unser Leitfaden Wie viele Nutzer schafft eine RTX PRO 6000? erklärt. Neben den Gewichten braucht jede offene Sitzung ihren Key-Value-Cache, den Speicher, in dem das Modell den gelesenen Kontext hält. Qwen3.8-27B führt diesen Cache in 16 seiner 64 Schichten: nach unserer Rechnung aus der config.json 64 KiB je Token in 16 Bit, also 8 GiB für 128K Token, dazu rund 0,14 GiB fester Zustand je Sitzung. Qwen3.6-35B-A3B braucht 20 KiB je Token, 1,3 GiB je Sitzung von 64K. Wir rechnen mit dem 16-Bit-Cache, den Ollama standardmäßig nutzt; ein FP8-Cache, wie ihn vLLM anbietet, halbiert die Werte je Token.

Unsere Schätzungen nach der Regel für Nutzer je Karte (0,9 × vom Treiber gemeldeter Speicher − 3 GiB je Karte), Gewichte aus den Ollama-Tags oben in GiB umgerechnet, Ollamas Standard-Cache in 16 Bit; keine Messungen. Treiberspeicher von RTX PRO 4500 und 5000 aus den 95,6 GiB einer 96-GB-Karte skaliert. Die RTX PRO 6000 Workstation Edition (600 W) hat dieselben 96 GB und ergibt dieselben Werte wie die Max-Q (300 W).

Eine Sitzung ist ein Agenten-Gespräch, das im Speicher gehalten wird. Wer gerade arbeitet, belegt eine; ein zweites Builder-Fenster oder eine Hintergrundaufgabe belegt eine weitere. Auf der RTX PRO 4500 lässt Qwen3.8-27B in 4 Bit 8,9 GiB frei, eine Sitzung von 128K oder zwei von 64K; Qwen3.6-35B-A3B in 4 Bit lässt 3,3 GiB frei, zwei Sitzungen von 64K. Eine RTX PRO 4000 mit 24 GB behält nach derselben Regel 18,5 GiB: neben Qwen3.8-27B in 4 Bit bleiben 1,7 GiB, weniger als eine Sitzung von 64K, und GLM-4.7-Flash übersteigt sie mit 23 GB nach Ollamas Angabe. Auf 24 GB ist gpt-oss-20b mit drei Sitzungen von 64K die realistische Wahl, wie unsere Seite zu 30B-Modellen auf 24-GB-Karten für die MoE-Modelle zeigt.

Die RTX PRO 5000 mit 48 GB hält Qwen3.8-27B in 8 Bit mit einer Sitzung von 128K, die Version mit 72 GB mit vier. Eine RTX PRO 6000 Max-Q oder Workstation Edition betreibt das Modell in 16 Bit oder Qwen3-Coder-Next in FP8 (80,4 GB) mit fünf Sitzungen von 64K. Zwei RTX PRO 6000 Max-Q mit je 300 W geben einem kleinen Studio eine Modellkopie je Karte. NVIDIA nennt bis zu vier Max-Q je Workstation; drei oder vier gehören nur in ein Gehäuse, das dafür gebaut ist, mit starkem, gerichtetem Luftstrom, und zwei Workstation Editions mit 600 W sind für diese Edition das realistische Maximum.

Für eine einzelne Anfrage maß StorageReview in einem Test vom 14. Oktober 2026 Qwen3.8-27B im NVFP4-Format von NVIDIA mit vLLM auf jeder Karte, auf der es lief, von der RTX PRO 4500 Blackwell Server Edition bis zur RTX PRO 6000 Workstation Edition, mit 17 bis 22 Token pro Sekunde, wie unser Leitfaden zur Vibe-Coding-Workstation berichtet. Nach unserer Rechnung aus der von NVIDIA angegebenen Speicherbandbreite kommt das Modell in 8 Bit, das je Token etwa 28 GB Gewichte liest, auf einer RTX PRO 6000 Workstation Edition auf höchstens etwa 63 Token pro Sekunde; reale Werte liegen darunter, und Agenten-Kontexte sind weit länger als ein kurzer Test-Prompt.

Dyad oder OpenHands mit Ollama einrichten

Der Software-Stack ist überschaubar. Die Schritte folgen den Leitfäden der Projekte, Stand Oktober 2026.

1. Installieren Sie Ollama 0.35.0 oder neuer; ältere Versionen sind von CVE-2026-103663 betroffen, wie unser Leitfaden zum Coding-Assistenten festhält. Ollama steht unter MIT-Lizenz und wird Stand Oktober 2026 aktiv weiterentwickelt. Setzen Sie OLLAMA_NO_CLOUD=1, das laut Ollamas FAQ die Cloud-Modelle und die Websuche entfernt, damit Prompts und Code auf der Workstation bleiben.
2. Setzen Sie die Kontextlänge in den Einstellungen von Ollama oder mit OLLAMA_CONTEXT_LENGTH auf mindestens 64.000 Token; nutzen Sie 128K, wo die Tabelle oben Platz lässt. Für mehr als eine Sitzung zugleich erhöhen Sie außerdem OLLAMA_NUM_PARALLEL, denn standardmäßig beantwortet Ollama je Modell eine Anfrage nach der anderen.
3. Laden Sie das Modell, zum Beispiel mit ollama pull qwen3.8:27b (der Standard-Tag mit 18 GB) oder qwen3.6:35b-a3b.
4. Installieren Sie den Builder: die Desktop-App von Dyad, die Ollama selbst erkennt, oder OpenHands, dessen Leitfaden zu lokalen LLMs die Einrichtung mit Ollama zeigt. bolt.diy liest OLLAMA_BASE_URL für einen Test; der Einsatz im Arbeitsalltag eines Unternehmens braucht vorher die WebContainers-Lizenz.
5. Lassen Sie den Modellserver auf der Workstation. Ollama lauscht standardmäßig auf 127.0.0.1, sein Container-Image setzt aber OLLAMA_HOST=0.0.0.0, und die OpenHands-Beispiele binden an 0.0.0.0, damit dessen Container den Server erreicht. Sperren Sie diesen Port in der Firewall, wie unser Leitfaden zum Absichern eines GPU-Servers beschreibt.
6. Prüfen Sie, was jedes Werkzeug standardmäßig nach außen sendet; unser Artikel zur Telemetrie in selbst gehosteten KI-Tools behandelt die Serverseite.

Wo die fertige App läuft

Ein lokaler Builder erzeugt Quellcode und eine Vorschau; wo die fertige App läuft, ist eine eigene Entscheidung. bolt.diy bietet die Bereitstellung per Klick auf Netlify, Vercel und GitHub Pages, alles Cloud-Dienste, und Dyad verbindet Apps über seine dokumentierten Integrationen mit Supabase oder Neon. Für ein internes Werkzeug mit Kunden- oder Mitarbeiterdaten läuft die App meist auf einem Server im eigenen Netz mit eigener Anmeldung, und die Datenbank bleibt ebenfalls dort. Was vor dem Livegang zu prüfen ist, zeigt unsere Sicherheits-Checkliste für Vibe-Coding-Apps. Unser Leitfaden Interne Tools mit KI bauen, ohne Entwickler beschreibt diesen Weg für Büro- und Betriebsteams, und unser Leitfaden zu lokaler KI und DSGVO erklärt, was eigenes Hosting klärt und was Ihre Pflicht bleibt.

Bauen mehrere Personen gleichzeitig, können die Builder auf den einzelnen PCs bleiben, während das Modell auf einen gemeinsamen Rechner im Netz wechselt, der dann eine Zugriffskontrolle braucht. Für 20 bis 100 Entwickler mit Agenten ist ein Rack-Server der bessere Ort für das Modell, wie unser Leitfaden zum Server für Coding-Agenten zeigt; den Schritt vom einzelnen PC zum Firmenserver beschreibt Von Ollama auf dem PC zum KI-Server im Unternehmen.

Senden Sie uns ein paar Zeilen zu den Apps, die Sie bauen wollen, und wir schlagen die Konfiguration vor, die zu Ihrem Team und Budget passt.

FAQ