Open Lovable im Check: 28.000 Sterne, aber nicht wirklich lokal

Was ist Open Lovable?

Open Lovable ist ein Open-Source-Projekt des Firecrawl-Teams. Du gibst eine öffentlich erreichbare URL ein, die Anwendung lässt die Seite scrapen und erzeugt daraus eine editierbare React-Anwendung. Das README am geprüften Commit bewirbt das Projekt mit dem Versprechen, React-Apps „instantly“ zu erzeugen. Eine konkrete Zeitangabe oder unabhängige Leistungsprüfung liefert es nicht.

Der Name legt einen direkten Vergleich mit Lovable.dev nahe. Technisch verfolgen beide Produkte aber unterschiedliche Hauptaufgaben: Open Lovable rekonstruiert eine bereits vorhandene Oberfläche. Lovable.dev erzeugt neue Anwendungen aus Prompts und bietet dafür weitere Plattformfunktionen. Wer einen allgemeinen Einstieg sucht, findet ihn in meinem Guide zu Vibe Coding mit Lovable.

Die Kerndaten zeigen ein ungewöhnliches Verhältnis zwischen Aufmerksamkeit und Produktreife:

Sterne und Forks messen Aufmerksamkeit. Sie belegen weder aktive Nutzung noch stabile Wartung oder Sicherheit.

Wie funktioniert Open Lovable technisch?

Open Lovable ist vor allem eine Orchestrierungsschicht. Die Anwendung verbindet Scraping, LLM-Codegenerierung und eine externe Sandbox zu einem durchgängigen URL-zu-React-Workflow.

Wie läuft eine Klon-Sitzung ab?

1. Du übergibst eine Ziel-URL und einen Änderungswunsch.
2. Die erweiterte Scraping-Route sendet die URL an `https://api.firecrawl.dev/v1/scrape` und fordert unter anderem Markdown, HTML und einen Screenshot an.
3. Die Anwendung bereitet diese Daten als Kontext für ein Sprachmodell auf. Der Provider-Manager unterstützt OpenAI, Anthropic, Google und Groq sowie optional das Vercel AI Gateway. Base-URL-Overrides sind im Code vorhanden.
4. Das Modell erzeugt oder verändert React- und Vite-Dateien.
5. Die Sandbox Factory startet eine Laufzeit bei E2B oder Vercel und schreibt die Dateien dorthin.
6. Modelloutput kann Paketnamen an einen automatischen Installationspfad übergeben: `apply-ai-code` parst Paketangaben und `install-packages` installiert sie über den aktiven Sandbox-Provider. Zusätzlich existiert eine Import-Erkennungsroute, deren Legacy-Globalzustand im aktuellen v2-Pfad jedoch inkonsistent ist.
7. Vite startet innerhalb der Sandbox. Die laufende Vorschau erscheint im Browser, Folgeprompts können einzelne Dateien verändern.
8. Der ZIP-Endpunkt versucht, das Projekt ohne `node_modules`, Build-Verzeichnisse und Logs zu exportieren.

Das ist ein Agent-Harness im Kleinen: Nicht nur das Modell entscheidet über das Ergebnis, sondern die gesamte Kette aus Kontextaufbereitung, Werkzeugen, Laufzeit und Fehlerbehandlung. Warum diese Ebene oft wichtiger als der Modellname ist, beschreibe ich im Artikel Warum der Agent-Harness das Modell frisst.

Welche Laufzeitlimits setzt das Projekt?

Die Open-Lovable-Konfiguration setzt für Vercel Sandbox eine Laufzeit von 15 Minuten mit Node.js 22 und Port 3000. Für E2B sind dort 30 Minuten und Vite-Port 5173 eingetragen. Das sind Projektwerte, nicht die allgemeinen Höchstgrenzen der Anbieter. E2B dokumentiert je nach Tarif und Lifecycle-Konfiguration andere Möglichkeiten.

Auch beim Standardprovider gibt es einen Widerspruch. Das README beschreibt Vercel als Standard für `SANDBOX_PROVIDER`. Der Fallback im Code lautet dagegen `e2b`, wenn weder Parameter noch Umgebungsvariable gesetzt sind.

Wie installierst du Open Lovable?

Das README dokumentiert diesen grundlegenden Ablauf:

git clone https://github.com/firecrawl/open-lovable.git
cd open-lovable
pnpm install

Danach legst du eine `.env.local` an, trägst die benötigten Schlüssel ein und startest den Entwicklungsserver:

pnpm dev

Für einen realen Durchlauf brauchst du mindestens Firecrawl, einen Modellanbieter oder kompatiblen Modellendpunkt und einen Sandbox-Provider. Je nach Auswahl kommen `FIRECRAWL_API_KEY`, ein Modellschlüssel sowie `E2B_API_KEY` oder Vercel-Zugangsdaten zum Einsatz. Morph ist nur für den optionalen Fast-Apply-Pfad relevant.

Das ist keine kostenlose lokale Installation im engeren Sinn. Die Betriebskosten hängen vom Firecrawl-Tarif, der Modellwahl, dem Tokenverbrauch, der Sandbox-Laufzeit und optional Morph ab. Eine seriöse Pauschale lässt sich daraus nicht berechnen.

Transparenz: Für diesen Artikel wurden Repository, Konfiguration, öffentliche Issues und die dokumentierten Befehle geprüft. Eine vollständige Klon-Sitzung mit bezahlten API- und Sandbox-Diensten wurde nicht ausgeführt.

Ist Open Lovable wirklich Self-Hosted?

Ja, aber nur auf einer Ebene. Du kannst die Next.js-Webanwendung unter der MIT-Lizenz selbst betreiben. Der dokumentierte Scraping-Pfad und die Codeausführung laufen jedoch über externe Dienste. Für die Modellinferenz sind mehrere externe Anbieter vorgesehen, wobei der Code auch Base-URL-Overrides enthält.

Firecrawl besitzt ein separates Open-Source-Projekt und kann grundsätzlich selbst gehostet werden. Open Lovable ist im untersuchten Stand aber fest auf `api.firecrawl.dev` ausgerichtet. Eine lokale Firecrawl-Instanz ist nicht automatisch integriert.

Ähnlich sieht es bei dedizierten Integrationen für lokale Modelle aus. Pull Request #157 schlägt Unterstützung für Ollama, vLLM und LM Studio vor. Der PR war am 23. Juli 2026 offen und nicht in `main` gemergt. Du darfst diese Integration deshalb nicht als reguläres Feature des Projekts einplanen. Die vorhandenen Base-URL-Overrides sind davon getrennt zu betrachten.

Das präzise Urteil lautet: Open Lovable ist Open Source, aber nicht vollständig lokal. Die Webanwendung ist selbst hostbar. Der dokumentierte Scraping-Pfad und die Codeausführung bleiben im geprüften Stand an externe Dienste gebunden; bei der Modellinferenz existieren neben den dokumentierten Cloud-Anbietern technische Base-URL-Overrides, aber keine dedizierte lokale Modellintegration.

Was zeigt der Code über Projektqualität und Wartung?

Die GitHub-Momentaufnahme ist deutlich: Am 23. Juli 2026 standen 28.062 Sterne und 5.330 Forks insgesamt 100 offenen Issues und 44 offenen Pull Requests gegenüber. Der letzte Main-Commit stammt vom 19. November 2025. Veröffentlichte Releases gab es zu diesem Zeitpunkt nicht.

Das beweist nicht, dass jede Funktion defekt oder das Projekt aufgegeben ist. Es belegt aber keinen formalen, planbaren Releasepfad. Für ein Produktivsystem solltest du deshalb Wartung und Sicherheitsfixes nicht ohne eigenen Fork vom Upstream abhängig machen. Über die generelle Reaktionsgeschwindigkeit der Maintainer erlaubt diese Momentaufnahme kein belastbares Urteil.

Warum ist der Gesamt-Testbefehl kaputt?

Die `package.json` definiert `test:all` als Kette aus `test:integration`, `test:api` und `test:code`. Das referenzierte Skript `test:integration` fehlt im aktuellen Hauptbranch. Auch die von `test:api` und `test:code` referenzierten Dateien `tests/api-endpoints.test.js` und `tests/code-execution.test.js` sind im Repository nicht vorhanden.

Der Recherchelauf vom 23. Juli 2026 auf Basis dieses Paketstands endete bei `npm run test:all` mit Exit-Code 1 und `Missing script: „test:integration“`. Das belegt eng gefasst: Der dokumentierte Gesamt-Testbefehl ist im aktuellen Hauptbranch nicht ausführbar. Es beweist nicht, dass sämtliche Laufzeitlogik fehlerhaft ist.

Wo kann der Exportzustand brechen?

Der v2-Pfad zur Sandbox-Erstellung speichert den Provider in `global.activeSandboxProvider`. Die ZIP-Route erwartet dagegen `global.activeSandbox`. Diese Inkonsistenz kann Fehlermeldungen wie `No active sandbox` plausibel erklären. Sie ist ein Codebefund, aber kein Beweis für die Ursache jedes gemeldeten Exportfehlers.

Welche Sicherheitsrisiken hat Open Lovable?

Open Lovable verarbeitet fremde Webseiten, Modelloutput, Cloud-Schlüssel und ausführbaren Code in einer Pipeline. Dadurch entsteht eine größere Angriffsfläche als bei einem reinen Frontend-Generator.

Der Command-Endpunkt bedeutet nicht automatisch Remote Code Execution auf deinem Host. Der Befehl läuft beim gewählten Provider in der aktiven Sandbox. Kritisch bleiben trotzdem Missbrauch, Kosten, Datenzugriff innerhalb der Sandbox und unerwünschte Änderungen.

Issue #208 ist ein Warnsignal für den Umgang mit Schlüsseln. Der Autor berichtet von einer exponierten `.env.local` und anschließendem Missbrauch. Der Thread belegt jedoch nicht, dass Open Lovable die Datei selbst veröffentlicht hat. Daraus lässt sich ein hohes operatives Risiko ableiten, aber keine bestätigte Projektlücke.

Eine konkrete SSRF-Schwachstelle ist ebenfalls nicht belegt. Ein Community-Ticket über fehlerhafte URLs oder `Bad Request` reicht dafür nicht aus. Das realistischere Architekturthema ist Indirect Prompt Injection: Inhalte einer fremden Zielseite gelangen in den Modellkontext und können die Codegenerierung beeinflussen. Ohne dokumentierten Exploit bleibt auch das eine Risikoklasse, kein nachgewiesener Angriff auf Open Lovable.

Wer generierte Agenten-Inhalte systematisch prüfen will, findet mit NVIDIA SkillSpector ein verwandtes Beispiel für statische Analyse und Supply-Chain-Kontrolle.

Was kann Open Lovable nicht klonen?

Eine visuelle Rekonstruktion ist kein vollständiger Produktklon. Open Lovable erhält öffentlich sichtbare Inhalte, einen Screenshot und daraus abgeleitete Strukturinformationen. Nicht sichtbar sind private Systeme hinter der Oberfläche.

Für eine Landingpage kann das erzeugte Gerüst als Ausgangspunkt dienen. Bei einem dynamischen SaaS-Produkt erhältst du eher ein visuelles Mockup als eine funktionsgleiche Anwendung. Auch eine ähnliche Oberfläche verschafft dir keine Nutzungsrechte an fremden Texten, Bildern, Marken oder Fonts.

Wie schneidet Open Lovable im Vergleich zu Lovable.dev und Dyad ab?

Eine Rangliste wäre irreführend, weil die drei Werkzeuge unterschiedliche Kernaufgaben haben.

Open Lovable ersetzt Lovable.dev also nicht einfach kostenlos. Es löst ein engeres Problem und verlagert mehrere Kostenstellen auf eigene API-Konten. Dyad ist als Vergleich relevant, wenn lokale Ausführung wichtiger ist als URL-basiertes Cloning. Preise und einzelne Integrationen ändern sich dynamisch und gehören deshalb vor einer Toolentscheidung direkt in den jeweiligen Produktdokumentationen geprüft.

Für wen eignet sich Open Lovable?

Open Lovable passt, wenn du seine Grenzen bewusst akzeptierst:

• Du brauchst einen automatisiert erzeugten UI-Ausgangspunkt aus einer öffentlich erreichbaren Landingpage.
• Du willst React- oder Tailwind-Mockups in einer isolierten Umgebung untersuchen.
• Du möchtest lernen, wie Scraping, LLM-Codegenerierung und Sandbox-Orchestrierung zusammenspielen.
• Du kannst API-Budgets begrenzen und den generierten Code selbst prüfen.
• Du bist bereit, für einen längeren Einsatz einen eigenen Fork zu warten.

Nicht passend ist das Projekt für eine exakte Reproduktion dynamischer SaaS-Produkte, vertrauliche oder regulierte Workloads und unveränderte öffentliche Deployments. Ebenso ungeeignet ist es, wenn du stabile Releases, einen funktionierenden Upstream-Testprozess oder eine komplett lokale Datenverarbeitung voraussetzt.

FAQ: Häufig gestellte Fragen zu Open Lovable

Fazit

Open Lovable ist ein verständliches Referenzprojekt für URL-zu-React-Orchestrierung und kann als Ausgangspunkt für kontrollierte UI-Mockups dienen. Ob es gegenüber einem manuellen Aufbau tatsächlich Zeit spart, wurde in diesem Recherchelauf nicht gemessen. Die 28.062 Sterne vom 23. Juli 2026 überdecken externe Kernpfade, eine fehlende lokale Sandbox, einen gebrochenen Gesamt-Testbefehl und relevante Sicherheitsaufgaben. Für produktive oder öffentlich erreichbare Instanzen sind ein eigener Wartungs-Fork, Authentifizierung, Paketkontrolle, Egress-Regeln, Secret-Management und Kostenlimits erforderlich. Den größeren Kontext liefern mein Lovable-Guide, der Überblick zur industriellen Entwicklung von Vibe Coding und die Analyse zum Agent-Harness.

Quellen:

• Open Lovable Repository, abgerufen am 23. Juli 2026
• README am geprüften Commit `69bd93b`
• `package.json` am geprüften Commit
• Open-Lovable-Konfiguration
• Sandbox Factory
• v2-Sandbox-Erstellung
• Firecrawl-Scraping-Route
• LLM-Provider-Manager
• Generierungsseite
• Code-Anwendung und Paketparser
• Paketinstallation
• Import-Erkennung
• Command-Route
• ZIP-Route
• Issue #208 zu exponierten Schlüsseln
• Pull Request #157 für lokale Modelle
• Vercel Sandbox Dokumentation
• E2B Sandbox Lifecycle
• Firecrawl Open Source vs. Cloud
• Lovable-Dokumentation
• Dyad-Dokumentation