Lovable Cloud zu Supabase migrieren: Backend und App übernehmen

Ihre Lovable-App soll auf ein eigenes Supabase-Backend und in einen nachvollziehbaren Betrieb wechseln? WZ-IT übernimmt die Lovable- und Supabase-Migration von der Bestandsaufnahme bis zum Cutover.

Eine Migration von Lovable Cloud zu Supabase betrifft mehr als das Verschieben einer PostgreSQL-Datenbank. Eine produktive Lovable-Anwendung kann Authentifizierung, Storage, Realtime, Edge Functions, Secrets, externe APIs und Row Level Security verwenden. Hinzu kommen Frontend-Build, Hosting, Domain, E-Mail-Versand und Deployment.

Der kontrollierte Weg trennt deshalb drei Fragen:

1. Wem gehören Code, Daten und Zugänge?
2. Welche Komponenten sollen wohin wechseln?
3. Wer übernimmt danach Verfügbarkeit, Updates, Backups und Sicherheit?

Was kann bei Lovable unabhängig betrieben werden?

Lovable beschreibt in seiner Dokumentation mehrere getrennte Betriebsmodelle:

• Frontend extern betreiben, Backend in Lovable Cloud belassen
• Frontend extern betreiben und Backend zu Supabase Cloud verschieben
• Frontend und Supabase auf eigener Infrastruktur betreiben
• Lovable weiter für Entwicklung und Vorschauen verwenden, Produktion aber separat ausliefern

Das ist wichtig, weil eine Migration nicht zwangsläufig als Big Bang erfolgen muss. Häufig ist es sinnvoll, zuerst den Code über GitHub und einen reproduzierbaren Frontend-Deploy zu sichern. Das Backend kann anschließend in einem eigenen Wartungsfenster folgen.

Vor der Migration: Eigentum und Exportfähigkeit prüfen

Die offizielle Lovable-Anleitung setzt für externe Bereitstellungen eine Verbindung zu GitHub voraus. Für die Migrationsplanung werden darüber hinaus folgende Punkte geprüft:

Fehlt einer dieser Bausteine, wird vor dem Cutover ein alternativer Export-, Rekonstruktions- oder Übergangsweg festgelegt.

Das passende Zielmodell wählen

Ein eigenes Supabase-Projekt kann auf der Supabase Cloud, als Managed Service oder auf kundeneigener Infrastruktur laufen. Diese Varianten unterscheiden sich bei Betriebsverantwortung und Plattformfunktionen.

Supabase Cloud reduziert den eigenen Infrastrukturaufwand und bietet verwaltete Plattformfunktionen. Self-Hosted Supabase schafft mehr Kontrolle über Betriebsort, Netzwerk und Integrationen, verlangt aber eigene Backups, Monitoring, Updates und Incident-Reaktion. Ein Managed Betrieb verbindet eigene oder dedizierte Infrastruktur mit übernommener Betriebsverantwortung.

Die Auswahl sollte sich an benötigten Funktionen, Datenvolumen, Wiederherstellungszielen, Netzwerkzugriffen und dem verfügbaren Betriebsteam orientieren.

Schema, Daten und RLS gemeinsam übernehmen

Lovable-Projekte legen Datenbankänderungen typischerweise als SQL-Migrationen im Repository ab. Diese Dateien sind die Grundlage, aber nicht automatisch der vollständige Ist-Zustand. Vor dem Import werden daher verglichen:

• Migrationen im Repository
• tatsächlich vorhandene Tabellen und Spalten
• Datenbankfunktionen und Trigger
• aktivierte Extensions
• Grants und RLS-Policies
• Storage-Policies
• geplante oder manuell vorgenommene Änderungen

Das Schema wird zuerst in einer leeren Zielumgebung reproduziert. Danach folgen Datenimport und fachliche Konsistenzprüfungen. RLS wird nicht nur auf vorhandene Policies geprüft: Auch Tabellen ohne aktivierte RLS, zu breite Grants und Zugriffe über Views oder Functions gehören in den Test.

Auth-Nutzer und aktive Sessions

Bei der Auth-Migration zählen nicht nur Datensätze in der Nutzertabelle. Zu erfassen sind:

• E-Mail-/Passwort-Konten
• OAuth- und Social-Login-Provider
• verknüpfte Identitäten
• Rollen und Metadaten
• E-Mail-Templates und SMTP
• Redirect- und Callback-URLs
• Passwort-Reset und Einladungen
• Token- und Session-Verhalten

Wenn sich JWT-Secrets oder Schlüssel ändern, können vorhandene Sessions ungültig werden. Das ist kein Grund gegen die Migration, muss aber in Kommunikation, Cutover und Testplan berücksichtigt werden.

Lovable dokumentiert für den regulären Wechsel zu einem eigenen Supabase-Projekt eine nur teilweise Übernahme der Nutzerkonten: Passwörter werden über diesen Weg nicht exportiert. Der Standardplan enthält daher Passwort-Reset, erneute Anmeldung und eine klare Nutzerkommunikation. Falls im konkreten Projekt ein weitergehender Exportweg verfügbar ist, wird er vorab technisch und sicherheitsbezogen geprüft, aber nicht vorausgesetzt.

Storage ist nicht Teil des Datenbank-Dumps

Supabase speichert Metadaten zu Storage-Objekten in PostgreSQL, die eigentlichen Dateien aber separat. Eine reine Datenbanksicherung reicht daher nicht.

Für jeden Bucket werden Objektanzahl, Größe, Pfad, Content Type und Zugriffsmodell erfasst. Nach der Übertragung werden Dateien über Stichproben oder Prüfsummen validiert. Öffentliche URLs, signierte Links und frontendseitig gespeicherte Pfade müssen gegen das neue Ziel getestet werden.

Edge Functions, Secrets und externe Dienste

Functions können Zahlungsanbieter, E-Mails, KI-APIs, Webhooks oder interne Systeme ansprechen. Die Migration umfasst deshalb:

• Funktionsquellcode und Deployment
• serverseitige Umgebungsvariablen
• Rotation übertragener Secrets
• neue Callback- und Webhook-URLs
• CORS und erlaubte Ursprünge
• Zeitlimits, Logs und Fehlerbehandlung
• planmäßige Jobs oder externe Trigger

Nicht jede Function muss unverändert übernommen werden. Manche Logik ist als PostgreSQL-Funktion, Workflow oder separater Service belastbarer.

Frontend auf das neue Supabase umstellen

Lovable-Anwendungen verwenden typischerweise eine Supabase-URL und einen öffentlichen Schlüssel als Build-Variablen. Da Vite-Variablen beim Build eingebettet werden, erfordert der Backend-Wechsel einen neuen Build und Deploy.

Zusätzlich werden geprüft:

• Client-Initialisierung
• serverseitige Secrets
• OAuth-Redirects
• Domain und CORS
• Realtime-Verbindungen
• Datei-URLs
• API- und Function-Aufrufe
• Fehlerzustände bei abgelaufenen Sessions

Der Quellcode kann weiterhin mit Lovable bearbeitet werden, sofern Git-Synchronisierung und Produktionsworkflow klar getrennt sind.

Produktionsreife vor dem Cutover

Ein technisch erreichbares System ist noch kein produktionsreifes System. Vor der Umschaltung sollten mindestens folgende Nachweise vorliegen:

• reproduzierbarer Frontend- und Backend-Deploy
• getestete Anmeldung für alle relevanten Provider
• positive und negative RLS-Tests
• vollständige Storage-Stichproben
• Funktions- und Webhook-Tests
• Backup von Datenbank und Dateien
• dokumentierter Restore-Test oder Restore-Verfahren
• Monitoring für Verfügbarkeit, Ressourcen und Fehler
• benannte Verantwortlichkeit und Eskalationsweg

Für KI-generierte oder schnell gewachsene Anwendungen ist ein zusätzlicher Production Readiness Audit sinnvoll.

Cutover ohne vermeidbare Datenlücke

Der Wechsel benötigt eine klar definierte Schreibgrenze. Nach dem letzten Quell-Export dürfen neue Datensätze nicht unbemerkt nur im Altsystem entstehen. Je nach Anwendung wird ein kurzes Wartungsfenster, ein finaler Delta-Abgleich oder ein Parallelbetrieb verwendet.

Nach der Umschaltung werden kritische Nutzerwege direkt geprüft. Das Altsystem bleibt während des vereinbarten Rückfallfensters unverändert verfügbar und wird erst nach fachlicher Abnahme kontrolliert stillgelegt.

Quellen

• Lovable: außerhalb von Lovable bereitstellen und hosten
• Supabase: Plattform zu Self-Hosted wiederherstellen
• Supabase: Self-Hosting
• Supabase: Row Level Security