Lovable-Alternativen fallen in zwei Kategorien. Sie beantworten unterschiedliche Fragen. Wenn du ein Produkt startest, wählst du einen Workflow und entscheidest, wer nach dem ersten erfolgreichen Durchlauf das Backend betreibt. Wenn du bereits eine funktionierende Lovable-App nutzt, ist deine erste Aufgabe ein Bestandsverzeichnis: Lovables eigene Dokumentation besagt, dass der Anwendungsquellcode dir gehört und dass das Verschieben eine Bereitstellungsänderung statt eines Neuprogrammierens ist. Die harte Arbeit liegt anderswo. Die Daten und Services erfordern die eigentliche Arbeit. Nachfolgend fünf Teile in dieser Reihenfolge: eine Tabelle für Neubauten, die aktuellen Portabilitätsfakten, eine Framework-Prüfung, eine Tabelle für bestehende Apps und eine Checkliste für die Produktakzeptanz.
Zwei Leser, zwei unterschiedliche Entscheidungen
Vergleiche bei einem Neubau, wie jedes Tool zu deinem Workflow passt und was du wartst, sobald die Demo läuft. Die Demo ist der einfache Teil. Der Builder spielt eine geringere Rolle als die Frage, wer in sechs Monaten die Datenbank, die Deployment-Pipeline und das Login-System betreibt.
Bei einer bereits funktionierenden App solltest du sie nicht in einem anderen Tool neu aufbauen. Beginne mit dem Bestandsverzeichnis. Identifiziere, worauf sie angewiesen ist: wo der Code lebt, wo das Frontend läuft, welches Backend die Daten speichert und welche KI-Features und Connectors zur Laufzeit durch Lovable laufen.
Und hier kommt der Teil, den viele überspringen. Lovable zu nutzen ist eine völlig gültige Option. Lovables Ownership-Leitfaden bezeichnet sein verwaltetes Setup als Empfehlung für die meisten Apps und rät, Komponenten nur zu verschieben, wenn du auf eine echte Einschränkung stößt, etwa eine Datenlokalisierungsvorgabe, nicht unterstützte Netzwerke oder eine Richtlinie, die selbstverwaltetes Hosting erfordert. Sollte nichts davon zutreffen und niemand in deinem Team will zusätzliche Operationen übernehmen, ist ein Umzug ein Aufwand ohne Gewinn.
Neubau: die Entscheidungstabelle
Diese Tabelle stellt mein Urteil dar. Ich habe sie aus der eigenen Dokumentation jedes Anbieters gezogen, soweit verfügbar. Sie ist keine Rangliste und erhebt keinen Anspruch darauf, welches Tool bessere Apps erzeugt.
| Option | Workflow, für den es geeignet ist | Source- und Repository-Modell | Backend- und Deployment-Verantwortung | Proof-of-Fit-Aufgabe |
|---|---|---|---|---|
| Lovable | Chat-gesteuerte Builds, bei denen eine Plattform Bearbeitung, Hosting und Backend handhabt | Code verwaltet in Lovable; Git-Synchronisierung zu GitHub, GitLab oder Bitbucket in allen Plänen | Lovable kann Hosting und das integrierte Backend betreiben; du übernimmst Operationen nur für Teile, die du verschiebst | Erstelle den Flow, synchronisiere zu Git, dann klone und starte es lokal |
| v0 | Prompt-zu-App-Arbeit, die in Überprüfung und Bereitstellung endet | Echter Code; v0 dokumentiert Bereitstellung oder Öffnung eines Pull Requests zur Überprüfung | One-Click-Deployment auf Vercel-gestützter Infrastruktur; Backend verbindet sich über Integrationen | Stelle den Flow bereit, dann ändere ihn durch einen Pull Request |
| Bolt | Browser-basiertes Erstellen, bei dem du deine eigene Git-Historie möchtest | Bolt dokumentiert eine Git-Integration; bestätige den Roundtrip in einem Test-Repository | Bolt Cloud umfasst Hosting, eine integrierte Datenbank, Authentifizierung, Speicher und Serverfunktionen | Erstelle den Flow mit persistenten Daten und Anmeldung, veröffentliche ihn und überprüfe den Git-Workflow |
| Replit | Erstellen und Hosten in einem Cloud-Workspace | Das Projekt existiert im Replit-Workspace; überprüfe seine aktuellen Git-Optionen | Replit dokumentiert das Veröffentlichen über Deployments; bestätige, welcher Typ Server-Code ausführt | Veröffentliche den Flow, stelle ihn erneut bereit und überprüfe, dass die Daten bestehen bleiben |
| Eigenes Repository mit von Entwicklern gesteuertem Tooling | Teams mit Ingenieuren, Code-Review und einer bestehenden Pipeline | Dein eigenes Repository, beliebiger Editor oder Coding-Agent | Du führst CI/CD, Hosting, Datenbank und Authentifizierung aus | Erstelle einen Starter, baue den Flow auf und versende ihn über deine Pipeline |
Die letzte Zeile beschreibt einen Workflow, kein einsatzbereites Produkt. Du stellst die Teile selbst zusammen. Du wählst einen Stack, einen Host und einen Agent oder Editor aus und überkommst dann alle aufgelisteten Operationsaufgaben. Falls du Frameworks für diesen Weg vergleichst, behandeln Astro vs Next.js und die Next.js- und Supabase-Seite die Standard-Einstiegspunkte.
Die Proof-Aufgabe hat für jeden Kandidaten die gleiche Form. Halte sie klein, mache sie aber real. Erstelle einen realistischen User-Flow mit persistenten Daten, Authentifizierung und einem Live-Deployment. Ein erzeugter Screenshot beweist nichts. Ein Konto registrieren, einen Datensatz persistieren, sich abmelden, sich wieder anmelden und diesen Datensatz erneut ansehen beweist viel.
Was Lovable dir tatsächlich mitgeben lässt
Die aktuellen Portabilitätsfakten stammen aus Lovables Deployment-Anleitung und Ownership-Anleitung:
- Git-Synchronisation ist in allen Plänen verfügbar (GitHub, GitLab, Bitbucket). Download der Codebasis, eine einmalige .zip-Snapshot, ist in kostenpflichtigen Plänen verfügbar.
- Beide Wege geben dir den Anwendungs-Quellcode, einschließlich Konfiguration und Datenbank-Migrationsdateien. Keiner umfasst die Datensätze in deiner Datenbank oder die Dateien im Speicher.
- Datenbankzeilen und Speicherdateien erfordern separate Exporte, und du überprüfst sie am Ziel, bevor du das Original stilllegst.
- Du kannst Lovable als Entwicklungswerkzeug behalten, während ein anderer Host die Produktion bereitstellt. Verbinde das Repository über Git-Synchronisation und lass den anderen Host davon bereitstellen.
Die GitHub-Integration hat erwähnenswerte Einschränkungen. Einige sind operativ unangenehm. Lovable bearbeitet und synchronisiert nur einen Branch gleichzeitig. Git-Synchronisation stellt immer ein neues Repository bereit und kann ein Projekt nicht an ein bestehendes anhängen, und das Wiederherstellen der Verbindung nach einer Unterbrechung erzeugt ein weiteres neues Repository. Das Repository ist standardmäßig privat. Das Löschen stoppt die Synchronisation.
Der Code ist dann nicht gesperrt. Das ist nützlich, aber nicht die ganze Migration. Das Speichern des Quellcodes in deinem Repository eliminiert die Runtime-Abhängigkeiten von Lovable nicht. Behalte diese Unterscheidung für die Tabelle zu bestehenden Apps im Auge.
Prüfe das Framework, bevor du einen Host wählst
Lovables Dokumentation besagt, dass neue Apps, die ab dem 13. Mai 2026 erstellt werden, TanStack Start verwenden, das Server-Code ausführt. Ältere Apps sind anders. Sie basieren auf React plus Vite und erstellen statische Dateien. Die Supabase-Integrationsdokumentation gibt den 22. Juni 2026 für Enterprise-Pläne bei einer verwandten Funktion an, nämlich integrierte Zahlungen mit deinem eigenen Supabase-Projekt. Wende daher keine pauschale Erstellungsdatum-Regel auf jedes Konto an.
Überprüfe dein tatsächliches Projekt. Öffne package.json in der Code-Registerkarte. Ein TanStack-Start-Projekt listet @tanstack/react-start unter seinen Abhängigkeiten auf. Ein älteres React-und-Vite-Projekt nicht.
Die Hosting-Folgen unterscheiden sich:
- TanStack Start: Der Host muss den Server-Teil ausführen: Server-Side Rendering, Server-Funktionen und API-Routen. Ein Host, der nur statische Dateien erhält, führt diese Funktionen nicht aus. Object Storage oder ein CDN allein reichen nicht. Lovable verweist auf eine Plattform, die
Nitroerkennt, einen Container oder deinen eigenen Server. Überprüfe auch, dasspackage.jsonnitro listet, denn ohne es verpackt der Build die App nicht für einen Host außerhalb von Lovable. - Ältere React und Vite: Stellen die statische Ausgabe in
dist/auf einem statischen Host, CDN oder Web-Server wie Nginx bereit, mit einem Fallback aufindex.html, damit Client-seitige Routen funktionieren.
Eine weitere Falle: Variablen mit dem Präfix VITE_ werden beim Build eingebunden, nicht zur Laufzeit gelesen. Das überrascht Teams. Bei Verwendung des integrierten Backends weist dich Lovable an, VITE_SUPABASE_URL und VITE_SUPABASE_PUBLISHABLE_KEY vor dem Ausführen von npm run build zu setzen.
Ich habe Deployment-Rezepte für jeden Provider hier weggelassen. Das ist bewusste Scope-Kontrolle. Lovables Anleitung beschreibt die aktuellen Schritte, und für ein Server-gerenderte Projekt schreibt sie Überprüfungen vor, wie das Laden einer Server-gerenderten Seite und das Ausführen einer Server-Funktion vor dem Umleiten des Traffics.
Bestehende App: vier Pfade im Vergleich
| Pfad | Was bleibt | Was wechselt | Immer noch von Lovable abgerechnet oder betrieben | Arbeit zur Überprüfung | Operativer Eigentümer |
|---|---|---|---|---|---|
| Behalte das vollständig verwaltete Setup | Alles | Nichts | Hosting, integriertes Backend, KI-Funktionen und Konnektoren; Cloud-Nutzung wird aus Workspace-Credits gezogen | Dass es deine Compliance- und Release-Anforderungen erfüllt | Lovable betreibt die Infrastruktur; du besitzt das Produkt |
| Nur Frontend-Hosting verschieben | Integriertes Backend, KI-Funktionen, Konnektoren; Lovable kann das Bearbeitungs-Tool bleiben | Frontend-Build und -Bereitstellung | Backend, KI und Connectors laufen weiter über Lovable | Host-Umgebungsvariablen, Server-Secrets, Sign-in-Weiterleitungs-URLs, Build-Zeit-VITE_-Werte, Server-Features auf TanStack Start | Du für die Frontend-Pipeline und Logs; Lovable für das Backend |
| Das eingebaute Backend in ein eigenes Supabase-Projekt verschieben | Code in Git-Sync; Frontend kann bleiben oder verschoben werden | Datenbank, Authentifizierung, Storage und Functions zu verwaltetem oder selbst gehostem Supabase | KI-Features und Connectors können weiterhin über Lovable laufen | Datenwiederherstellung, Auth, Storage, Zugriffrichtlinien, Edge Functions, Secrets | Du im Supabase-Dashboard und unter deiner Supabase-Abrechnung |
| Lovable vollständig verlassen | Quellcode | Frontend, Backend, Daten plus Ersatz für KI- und Connector-Aufrufe | Nichts, sobald Ersatzlösungen an Ort und Stelle sind und akzeptiert wurden | Die gesamte Checkliste unten | Du für alles |
Zwei Dinge in dieser Tabelle lassen sich leicht falsch machen.
Erstens ist die Migration eines Backends kein Umschalter. Lovable gibt an, dass es ein Projekt nicht in einem Schritt vom eingebauten Backend zu Supabase übertragen kann, noch den Prozess rückgängig machen. Die dokumentierte Route ist manueller. Sie erfordert, das Schema von Hand neu zu erstellen und Daten zu verschieben: vom aktiven Backend exportieren, das neue verbinden und Lovable anweisen, das Schema zu rekonstruieren.
Zweitens sind die unterstützten Ziele verwaltes Supabase und selbst gehostetes Supabase. Das Verschieben der PostgreSQL-Datenbank allein hinterlässt zu viel: Authentifizierung, Storage, Echtzeit-Features und Edge Functions. Der Wechsel zu reinem PostgreSQL oder einem anderen Anbieter erfordert, diese Äquivalente selbst zu bauen, ein Pfad, den Lovable nicht unterstützt. Das ist echte Ingenieursarbeit, keine direkte Migration. Wenn du diesen Weg gehst, ist die Übersicht über serverlose Datenbanken ein sinnvoller Ort zum Vergleich von Zielen.
Das Verlassen des eingebauten Backends entfernt auch native Tools. Du verlierst die In-Editor-Ansichten für Datenbank, Benutzer, Storage, Secrets, Jobs und Logs, tägliche Backups mit Punkt-und-Klick-Wiederherstellung und Lovable-konfigurierte Auth wie verwalteter Google-Sign-in. Das Betreiben deines eigenen Supabase-Projekts erfordert ein eigenes Supabase-Abonnement und direkte Infrastrukturverwaltung.
Und nirgends in den Quellen steht, dass ein anderer Builder ein vollständiges Lovable-Backend importiert. Gehe davon aus, dass es nicht passiert.
Die Produktions-Akzeptanzmeldung
Beginne mit einer Bestandsaufnahme. Für das eigentliche Projekt stelle eine Liste zusammen mit:
- Daten und Schema (die Migrationsdateien befinden sich unter
supabase/migrations/) - Auth-Benutzer und -Anbieter
- Storage-Dateien und Zugriffrichtlinien
- Echtzeit-Abonnements
- Edge Functions oder Server-Funktionen
- Geheimnisse
- Geplante Jobs und Webhooks
- KI-Zugriff und App-Konnektoren
Arbeite dies dann in dieser Reihenfolge durch:
- Klone das Repository und führe den Code lokal aus. Das zeigt, was installiert wird, wovon es abhängt und was es aus der Umgebung liest.
- Identifiziere das Framework und die Runtime (siehe die obige
package.json-Prüfung). - Stelle den Datenexport in einem Staging-Projekt wieder her, nicht in der Produktion.
- Lade Speicherdateien von Mehr → Speicher herunter und lade sie in den Staging-Speicher.
- Teste Anmeldung, Anmeldung und OAuth-Umleitungen, und überprüfe die Kontokontinuität. Lovables Dokumentation zum Datenexport sagt, dass die Wiederherstellung in einem Supabase-Projekt die Passwörter der Benutzer beibehält, und dass sich alle, die zum Zeitpunkt des Wechsels angemeldet sind, erneut anmelden müssen. Nimm es nicht an, sondern validiere es, und folge Supabase's aktuellem Leitfaden zur Benutzermigration. Siehe auch die Authentifizierungsseite.
- Teste Dateizugriff und Berechtigungen mit echten Konten verschiedener Rollen.
- Überprüfe Row Level Security. Jede Tabelle braucht Richtlinien, die einschränken, wer jede Zeile lesen und schreiben kann, und Lovable sagt, dass du diese selbst im Supabase-Dashboard überprüfst.
- Führe einen kritischen bezahlten oder statusändernden Ablauf im Testmodus aus, ohne echte Kunden zu belasten.
- Vergleiche Datensatzzahlen und öffne repräsentative Dateien aus dem Speicher.
- Überprüfe Protokolle, Sicherungen, Wiederherstellung und einen Rollback-Pfad.
- Ersetze alles, das über Lovable lief: KI-Zugriff, Konnektoren, geplante Jobs.
- Erst dann die ursprünglichen Dienste entfernen.
Schritt 12 rechtfertigt eine Warnung. Nimm es ernst. Das Löschen der Lovable-Datenbank löscht deinen Export zusammen mit deinen Dateien, also lade und überprüfe sie vorher. Füge niemals Anmeldedaten in Tickets, Chats oder das Repository ein, während du dies bearbeitest.
Eine weitere Falle: Wenn zwei Lovable-Projekte ein einzelnes Supabase-Projekt teilen, überschreiben sie die Geheimnisse des anderen, einschließlich LOVABLE_API_KEY, was alle Funktionen, die darauf angewiesen sind, bricht.
Bleiben, hybrid gehen oder weggehen
Die meisten echten Entscheidungen landen dazwischen.
- Eine Anforderung für eine andere Bereitstellungspipeline braucht möglicherweise nur einen Frontend-Wechsel.
- Ein Bedarf für eine Datenbank in deinem eigenen Konto braucht möglicherweise die Backend-Migration und nichts mehr.
- Unzufriedenheit mit der Bearbeitungserfahrung könnte nur bedeuten, dass im exportierten Repository mit deinem eigenen Editor arbeitet, während Lovable über Git-Synchronisierung verbunden bleibt.
Weisen Sie einen Wartungseigentümer zu und erfassen Sie jede verbleibende Runtime-Abhängigkeit, bevor Sie einen Service kündigen. Halten Sie das Dokument prägnant. Es muss angeben, wer bereitgestellt, wer Sicherungen wiederherstellt, wer Geheimnisse rotiert, und welche Features noch Lovable aufrufen. Wenn Sie keinen Eigentümer benennen können, bleiben Sie vorerst, wo Sie sind.
Wenn Sie eine zweite Meinung zu dieser Übergabe möchten, senden Sie das Repository, eine Deployment-Map und den User Flow, der technische Überwachung erfordert, an das agentengesteuerte Engineering-Team zur Bewertung von Eigentümergrenzen und verbleibender Arbeit. Seien Sie präzise bei der Anfrage. Dies ist eine Bewertung, keine garantierte Sofortlösung.
FAQ
Kann ich den Lovable Editor und Agent selbst hosten?
Nein. Lovable gibt an, dass der Editor und der KI-Agent als verwalteter Service betrieben werden und nicht selbst gehostet oder in einer Customer-VPC bereitgestellt werden können. Die Anwendungen, die Sie damit erstellen, können jedoch überall gehostet werden.
Trägt ein Wechsel zu einem anderen Builder mein Backend mit?
Nichts in den Quellen deutet darauf hin. Planen Sie separate Arbeiten ein. Exportieren Sie Ihre Daten und Dateien, übertragen Sie die Codebase über Git oder einen Download, und konfigurieren Sie Authentifizierung, Geheimnisse und unterstützende Services erneut am Zielort.
Reicht der .zip-Download aus, wenn ich einen kostenlosen Plan habe?
Lovables direkter Codebase .zip-Download ist in kostenpflichtigen Plänen verfügbar. Git Sync ist etwas anderes. Da Git Sync über alle Ebenen hinweg verfügbar ist, testen Sie zunächst diese Route.
Die primäre Einschränkung ist klar: Der exportierte Code gehört Ihnen, aber die Datensätze der Datenbank, Speicherdateien, Auth-Konfiguration und von Lovable verwaltete KI und Connectors erfordern separate Migrationen, von denen keine automatisch erfolgen. Machen Sie die Bestandsaufnahme, bevor Sie umschalten. Überprüfen Sie Ihre package.json, erfassen Sie jede Abhängigkeit und testen Sie die Migration in einer Staging-Umgebung, bevor Sie etwas kündigen.