Was mit Lovable passiert ist

Was es ist und warum es zählt

Im April 2026 hat The Register über die Meldung eines Sicherheitsforschers zu Lovable berichtet, und Lovable hat den Vorfall danach in seinem Blog erklärt: Zwischen Februar und April konnten wegen eines Problems im Backend Chats und Code öffentlicher Projekte von anderen Nutzern gesehen werden. Lovable sagt, private Projekte seien nicht betroffen gewesen und das Problem sei behoben. Wenn du dort ein Projekt hast, lies ihren Beitrag.

Ich habe nichts gegen Lovable. Die Geschichte hat mich nur daran erinnert, wie wichtig es ist zu wissen, wo dein Projekt lebt und wer seine Schlüssel hält. Lebt es in einer Plattform, ist die Sicherheit der Plattform deine Sicherheit. Lebt es in einem Ordner, der dir gehört, mit deinen eigenen Schlüsseln, sind die Fehler deine, und wenigstens kannst du sie beheben.

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.

Unten steht, wie du alles herausholst. Ich nehme die Menüs von Lovable, aber die Logik gilt für jede Plattform. Und es lohnt sich auch, wenn du bleibst: eine eigene Kopie zu haben ist gesunder Menschenverstand.

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

1. Der Code

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.

Die Synchronisierung folgt nur einem Branch, meist main. Solange sie aktiv ist, testest du auf einem eigenen Branch und fasst das Projekt in Lovable nicht an.

Wenn dein Tarif es hat, gibt es im selben Menü auch „Download codebase“: ein ZIP mit dem ganzen Code. Gut als Sicherungskopie, aber es aktualisiert sich nicht.

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

Der Code bringt die Struktur der Datenbank mit, nicht die Daten. Die Struktur steckt in den Migrations: SQL-Dateien, meist im Ordner supabase/migrations, die Tabellen, Spalten und Zugriffsregeln neu anlegen. Die Daten, also die echten Zeilen, exportierst du separat.

Für Schema und Daten nutzt du beim eingebauten Backend von Lovable (Lovable Cloud) den Datenbankexport aus den erweiterten Einstellungen: More → Cloud → Overview → Advanced settings → Export data. Der Link kommt per E-Mail. Das ist ein Postgres-Backup-Archiv, keine SQL-Datei zum Einfügen: Du stellst es mit pg_restore wieder her. Hast du dagegen den Connection String der Datenbank, nimmst du pg_dump. Bei Supabase findest du den String über den Button „Connect“ im Dashboard des Projekts, und die Anleitung dort nutzt den Befehl supabase db dump.

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

3. 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 den Passwörtern in verschlüsselter Form. Stellst du ihn in einem Supabase-Projekt wieder her, behalten die Nutzer ihr Passwort. Zwei Dinge kommen aber nicht mit: die Sitzungen, also müssen sich alle neu einloggen, und die Einstellungen der Anmeldemethoden, etwa „Mit Google anmelden“, die du auf dem neuen System neu einrichtest.

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.

4. Hochgeladene 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.

Dann zähl die Dateien vorher und nachher.

5. Die 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.

Mach eine Liste aller Schlüssel: Datenbank, APIs, Zahlungen, E-Mail. Leg sie in deine .env auf dem Computer und in die Einstellungen des neuen Hostings. Private Schlüssel gehören nie in den Code oder ins Git, und nie in eine Variable, die mit VITE_ beginnt: Die landen im Browser, also dort nur öffentliche Werte.

Dann erneuer sie: neue Schlüssel, alte widerrufen. Ein Schlüssel, der auf einer Plattform gültig bleibt, die du nicht mehr nutzt, ist eine offen gelassene Tür.

6. Domain und Login

Richte die Domain auf das neue Hosting aus, nach den Anleitungen deines Hosters. Die Adresse lovable.app bleibt bei Lovable und zeigt weiter die letzte Version, die du dort veröffentlicht hast.

Dann aktualisierst du die Redirect-URLs des Logins: Die neue Adresse muss zu den erlaubten Adressen deines Login-Systems hinzugefügt werden. Nutzt du „Mit Google anmelden“ oder Ähnliches, trag sie auch dort ein. Vergisst du das, geht der Login genau auf der neuen Domain kaputt.

Mit Claude Code, im Ordner

Ö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 dieses Projekt und mach mir eine Liste von allem, was von der Plattform abhängt, von der es kommt: Variablen, Dienste, URLs, Funktionen auf dem Server.

Das ist deine Karte. Funktionen auf dem Server sind die, die außerhalb des Browsers laufen: In Lovable-Projekten mit Supabase liegen sie meist in supabase/functions und müssen separat auf dem neuen Backend veröffentlicht werden.

Den nächsten ergänze ich selbst: Er gibt dir die Liste der Schlüssel aus Punkt 5, ohne dass du sie von Hand suchen musst.

Mach mir eine Liste aller Umgebungsvariablen, die das Projekt nutzt: wo sie gelesen werden, welche im Browser landen und welche geheim bleiben müssen. Schreib die Werte nicht hin.

Bring es lokal mit meiner neuen Datenbank zum Laufen und sag mir, was fehlt.

Hier tauchen die vergessenen Schlüssel und die leeren Tabellen auf. Claude Code fragt dich um Erlaubnis, bevor es Dateien ändert oder Befehle ausführt, je nach gewähltem Berechtigungsmodus: Lies, was es vorhat, bevor du Ja sagst.

Prüf, dass kein Schlüssel im Code oder in der Git-Historie steht.

Findet es einen in der Historie, reicht es nicht, die Datei zu löschen: Er bleibt in den alten Commits. Diesen Schlüssel erneuerst du, Punkt.

7. Veröffentlichen, testen, dann das Alte abschalten

Wenn lokal alles läuft, veröffentlichst du auf einem Hosting, das du selbst kontrollierst. Dann testest du die Dinge, die zuerst kaputtgehen:

1. Der Login: Melde dich mit einem Konto an, das es schon gab, und leg ein neues an.
2. Einen Datei-Upload, und dass sich die Datei wieder öffnen lässt.
3. Die Zahlungen, falls du welche hast, im Testmodus.

Erst dann schaltest du das Alte ab.

Häufige Fehler

• Das alte Projekt löschen, sobald du das Repository hast. Lass es laufen, bis Login, Dateien und Zahlungen auf dem neuen funktionieren.
• Glauben, das Repository sei das ganze Projekt. Der Code bringt die Struktur mit; Daten, Nutzer, Dateien und Secrets kommen jeweils einzeln heraus.
• Die Daten in eine schon benutzte Datenbank importieren. Fang mit einem neuen, leeren Postgres an.
• Die alten Schlüssel ins Neue kopieren und es dabei belassen. Erneuer sie und widerrufe die alten.
• Die Redirect-URLs vergessen. Trag die neue Domain bei den erlaubten Adressen des Logins ein, bevor du sie umziehst.

Checkliste

• Repository auf GitHub, privat, auf den Computer geklont
• Struktur und Daten in der neuen Datenbank, vor dem Import leer
• Login mit einem alten und einem neuen Konto getestet
• Dateien heruntergeladen, wieder hochgeladen und gezählt
• Schlüssel aufgelistet, erneuert, alte widerrufen
• Domain und Redirect-URLs aktualisiert
• Das Alte als Letztes abgeschaltet

Häufige Fragen