Warum ich Lovable verlassen habe

Was es ist und warum es zählt

Lovable ist bequem. Der Grund, warum ich gegangen bin, ist ein anderer: In so einer Plattform liegt der Code bei ihnen, das Deployment läuft über sie, und die Preise legen sie fest. Mir ist ein Projekt lieber, das in einem Ordner liegt, der mir gehört.

Vor einem Jahr hatte diese Bequemlichkeit für mich Sinn, weil die anderen Werkzeuge schwierig waren. Heute bitte ich Claude Code um dieselben Dinge, um die ich Lovable bitten würde, ich schreibe wie in einem Chat, und am Ende gehört das Projekt mir: Ich nehme es mit, wohin ich will.

Das ist meine Entscheidung, keine Regel. Wenn du zufrieden bist, wo du bist, bleib: Diese Anleitung hilft dir trotzdem, denn eine eigene Kopie von allem schadet nie.

Der Punkt ist: Ein Projekt ist nicht nur der Code. Da sind die Daten, die Konten der Nutzer, die hochgeladenen Dateien, die Schlüssel, die Domain. Jedes Teil geht durch eine andere Tür hinaus, und vergisst du eins, merkst du es, wenn ein Nutzer nicht mehr reinkommt.

Eine Regel vor allem anderen: Lösch nichts, bis das Neue funktioniert.

1. Der Code auf deinem eigenen GitHub

Bei Lovable: Project settings → Git → GitHub. Du verbindest dein Konto und lässt das Repository anlegen: Lovable legt es privat an und hält es in beide Richtungen synchron, was du in Lovable änderst, geht zu GitHub und umgekehrt.

Bei Replit: Tools → Git. Hat das Projekt noch kein Repository, drückst du auf „Initialize Git Repository“. Dann verbindest du GitHub (beim ersten Mal bittet Replit dich, den Zugriff zu erlauben), machst einen Commit und pushst alle Dateien.

Dann klonst du das Repository auf deinen Computer, über den Button „Code“ auf der Seite des Repos bei GitHub. Ab jetzt ist es ein Ordner, der dir gehört.

2. Die Datenbank: Struktur und Daten

Der Code bringt die Struktur der Datenbank mit, nicht die Daten. Bei Lovable steckt die Struktur in den Migrations, SQL-Dateien, meist im Ordner supabase/migrations. Die Daten, also die echten Zeilen, exportierst du separat.

Ohne die Daten hast du eine leere App.

Bei Lovable Cloud steckt der Datenbankexport in den erweiterten Cloud-Einstellungen: More → Cloud → Overview → Advanced settings → Export data. Der Link kommt per E-Mail: Das ist ein Postgres-Backup-Archiv mit Struktur und Daten, und du stellst es mit pg_restore wieder her. Hochgeladene Dateien und Schlüssel sind nicht dabei: Die ziehst du von Hand um, wie ich weiter unten erkläre.

Bei Replit gibt es zwei Datenbanken. Die Entwicklungsdatenbank nutzt du, während du baust. Die Produktionsdatenbank nutzt die veröffentlichte App, und dort liegen die Daten deiner Nutzer: Die musst du exportieren.

Öffne das Werkzeug Database und wähl die Produktionsdatenbank. Im Tab My Data kannst du die Daten in eine Datei exportieren. Im Tab Settings steht der Connection String: Laut der Dokumentation von Replit kann sich jeder PostgreSQL-kompatible Client mit der Produktionsdatenbank verbinden, also auch pg_dump. Behandle ihn wie ein Passwort.

Du importierst ihn in ein eigenes Postgres oder Supabase, neu und leer.

3. Umgebungsvariablen und Schlüssel

Geheime Variablen kommen weder mit dem Code noch mit dem Datenbankexport heraus. Und bei Lovable lassen sich Secrets nicht wieder auslesen, nur ersetzen: Den Wert holst du dir bei dem Dienst, der ihn dir gegeben hat.

Bei Replit findest du sie unter Tools → Secrets, mit sichtbaren Werten. Ist die App veröffentlicht, prüf auch die Produktions-Secrets in den Einstellungen von Publishing: Sie können anders sein.

Mach eine Liste aller Schlüssel: Datenbank, APIs, Zahlungen, E-Mail. Leg sie in die .env auf dem Computer und in die Einstellungen des neuen Hostings, nie in den Code.

Wenn die neue App funktioniert, erneuer sie alle und widerrufe die alten: Sie sind durch eine andere Plattform gegangen, und du weißt nicht mehr, wo sie gelandet sind.

4. Nutzer, Dateien, Domain

Die Nutzer

Die Login-Konten reisen nicht mit den Tabellen: Verschiebst du nur die Daten, bleiben die Nutzer zurück.

Der vollständige Export von Lovable Cloud enthält sie dagegen, mit verschlüsselten Passwörtern. Stellst du ihn in einem Supabase-Projekt wieder her, behalten die Nutzer ihr Passwort; die Sitzungen nicht, also loggen sich alle neu ein.

Bei Replit siehst du unter Tools → Users & Auth, Tab Users, wer sich registriert hat. Mit Replit Auth melden sich die Nutzer mit einem Replit-Konto an. Ihre Zeilen in der Datenbank reisen mit den Daten, der Weg hinein nicht: Entscheide vorher über den neuen Login und darüber, wie die bisherigen Nutzer wieder reinkommen.

Kommst du auf einem anderen Weg und lassen sich die Passwörter nicht mitnehmen, bereite eine E-Mail „Passwort zurücksetzen“ vor, die du am Tag des Umzugs verschickst.

Die hochgeladenen Dateien

Fotos, Dokumente, Avatare: Sie sind nicht in der Datenbank und nicht im Code. Bei Lovable Cloud findest du sie unter More → Cloud → Storage. Lade sie herunter und lade sie in den neuen Speicher wieder hoch, in Buckets (die „Ordner“ des Speichers) mit denselben Namen.

Bei Replit liegen sie in App Storage: Tools → App Storage, wähl den Bucket im Menü oben links, und in der Ansicht Objects lädst du jede Datei über das Symbol daneben herunter.

Dann zähl die Dateien vorher und nachher.

Die Domain

Notier dir, wo die Domain registriert ist, und kopier ihre aktuellen DNS-Einträge, bevor du sie änderst. Bei Replit ist die verbundene Domain unter Publishing, Tab Domains. Hast du sie in der Plattform gekauft, prüf, wie man sie überträgt, bevor du irgendetwas schließt.

5. Öffne den Ordner mit Claude Code

Öffne das Terminal im Projektordner und starte Claude Code (cd in den Ordner, dann claude). Es liest die Dateien selbst. Ich gebe ihm diese Aufträge, in dieser Reihenfolge.

Lies das ganze Projekt und erklär mir, wie es aufgebaut ist: Framework, Datenbank, Login, externe Dienste. Mach mir eine Liste der Umgebungsvariablen, die es braucht.

Das ist die Karte. In Replit-Projekten findet die App die Datenbank meist über die Variable DATABASE_URL: Im neuen Setup muss sie auf deine zeigen.

Leg eine Datei .env.example mit allen Variablen an, ohne echte Werte, und füg .env zur .gitignore hinzu.

Die .env.example enthält nur die Namen. Die echten Werte liegen in der .env auf deinem Computer, und die .gitignore sagt Git, dass sie nie hochgeladen wird.

Bring es lokal zum Laufen. Wenn etwas von der alten Plattform abhängt, sag mir, was, und schlag mir vor, wie ich es ersetze.

Hier kommen die versteckten Dinge heraus: ein Login, der über die Plattform läuft, eine Adresse, die im Code steht. Wie viel Claude Code fragt, bevor es handelt, hängt vom Berechtigungsmodus ab, den du mit Shift+Tab wechselst. Wenn es fragt, lies, was es vorhat, bevor du Ja sagst.

Importier den Dump der Datenbank in eine lokale Datenbank und prüf, ob die Seiten die echten Daten zeigen.

Du brauchst Postgres auf dem Computer: Fehlt es, bitte Claude Code, dir bei der Installation zu helfen. Dann öffne die App: Siehst du deine Nutzer und deine Inhalte, sind die Daten da.

6. Veröffentliche dort, wo du die Kontrolle hast

Bereite das Deployment auf [Vercel / deinen Server] vor: Sag mir die Schritte, die Variablen, die ich setzen muss, und was ich im DNS ändern muss. Fass nichts an, bis ich ok sage.

Der letzte Satz zählt: Ich will zuerst den Plan lesen. Du kannst auch den Plan Mode nutzen (Shift+Tab oder /plan vor dem Prompt): Claude schreibt einen Plan und ändert die Dateien nicht, bis du ihn freigibst.

Bevor du die Domain umziehst, teste alles auf der Adresse, die dir das neue Hosting gibt: Login mit einem alten Konto, eine hochgeladene Datei, Zahlungen im Testmodus. Dann, erst wenn die neue Version funktioniert, in dieser Reihenfolge:

1. Du ziehst die Domain um und trägst die neue Adresse bei den Redirect-URLs ein, die dein Login erlaubt.
2. Du erneuerst die Schlüssel und widerrufst die alten.
3. Du schaltest die alte Version ab.

Häufige Fehler

• Bei Replit die Entwicklungsdatenbank exportieren. Die Daten der veröffentlichten App liegen in der Produktionsdatenbank: Exportier die.
• Die echten Werte in die .env.example schreiben. Dort stehen nur die Namen; die Werte liegen in der .env, die Git ignoriert.
• Vergessen, wie die Nutzer reinkommen. Entscheide vorher über den neuen Login und darüber, wie die schon registrierten Nutzer wieder reinkommen.
• Die alten Schlüssel ins Neue kopieren und es dabei belassen. Erneuer sie und widerrufe die alten.

Checkliste

• Code auf deinem eigenen GitHub, privat, auf den Computer geklont
• Struktur und Daten aus der Produktionsdatenbank exportiert
• Liste der Variablen und .env.example ohne echte Werte
• Nutzer, Dateien und DNS-Einträge gesichert
• App läuft lokal mit den echten Daten
• Login, Dateien und Zahlungen auf dem neuen Hosting getestet
• Domain umgezogen, Schlüssel erneuert, alte Version als Letztes abgeschaltet

Häufige Fragen