Meine Lovable-App läuft – wie bringe ich sie sicher in den Betrieb?

Lovable macht es leicht, aus einer Idee in kurzer Zeit eine Web-App zu bauen. Meist entsteht ein React-Frontend; Daten und Anmeldung laufen häufig über Supabase. Das Ergebnis funktioniert – im Browser, mit echten Daten, oft schon mit echten Nutzern.

Was dabei leicht untergeht: „Läuft“ heißt noch nicht „betrieben“. Spätestens wenn Kunden, Kolleginnen oder Umsatz an der App hängen, braucht es mehr als einen funktionierenden Prototyp.

1. Klären, wem die App gehört

Die erste Frage ist keine technische: Wem gehören Code, Datenbank und Domain? Wenn die Person geht, die alles „gepromptet“ hat, darf die App nicht mitgehen.

• Verbindet das Projekt mit einem GitHub-Repository, das eurem Unternehmen gehört – nicht dem privaten Account einer einzelnen Person.
• Legt das Supabase-Projekt in einer Organisation des Unternehmens an und gebt mindestens zwei Personen Admin-Rechte.
• Registriert Domain und Zahlungsmittel auf das Unternehmen.

2. Zugriffsregeln prüfen

In Supabase entscheidet Row Level Security (RLS), wer welche Datensätze lesen und ändern darf. Der öffentliche Schlüssel (anon key) steht zwangsläufig im Frontend – jeder kann ihn im Browser sehen. Ohne passende Regeln erlaubt er mehr, als ihr denkt.

• Ist RLS für jede Tabelle aktiviert?
• Gibt es für jede Tabelle Policies, die zu eurem Rechtekonzept passen?
• Testet mit einem zweiten Nutzerkonto: Sieht es Daten, die es nicht sehen darf?
• Der service_role-Schlüssel umgeht alle Regeln. Er gehört nie ins Frontend.

3. Geheime Schlüssel aus dem Frontend holen

API-Schlüssel für OpenAI, Stripe oder Mail-Dienste haben im Frontend nichts verloren: Alles, was im Browser landet, kann jeder auslesen. Geheime Schlüssel gehören in Server-Funktionen – etwa Supabase Edge Functions – und dort in die hinterlegten Secrets.

Ist ein Schlüssel schon im Code oder im Git-Verlauf gelandet, hilft Löschen allein nicht. Wie ihr richtig vorgeht, steht im Ratgeber Wie entferne ich Passwörter und API-Schlüssel aus dem Git-Verlauf?

4. Backups prüfen – und den Restore üben

• Seht im Supabase-Dashboard nach, ob und wie oft gesichert wird und wie lange Sicherungen aufbewahrt werden. Point-in-Time-Recovery gibt es je nach Tarif als Zusatz.
• Legt zusätzlich einen eigenen, regelmäßigen Export an einem zweiten Ort an, zum Beispiel einen Datenbank-Dump.
• Vergesst die Dateien nicht: Uploads im Storage stecken nicht im Datenbank-Dump.
• Spielt eine Sicherung einmal in ein Testprojekt zurück. Ein Backup, das nie zurückgespielt wurde, ist eine Hoffnung, kein Plan.

5. Fehler sichtbar machen

Ohne Überwachung erfahrt ihr von Ausfällen durch eure Nutzer. Das muss nicht sein:

• Ein Uptime-Check von außen ruft die App regelmäßig auf und schlägt Alarm, wenn sie nicht antwortet.
• Fehler-Tracking im Frontend, etwa mit Sentry, zeigt euch Abstürze, bevor jemand anruft.
• Die Logs eurer Server-Funktionen gehören regelmäßig in den Blick.

6. Änderungen kontrolliert ausrollen

Mit KI ist die nächste Änderung nur einen Prompt entfernt – und landet schnell direkt im Live-System.

• Trennt Test und Produktion: ein eigenes Supabase-Projekt für Tests, Änderungen zuerst dort prüfen.
• Versioniert Datenbankänderungen als Migrationen im Repository, statt sie nur im Dashboard zu klicken.
• Richtet eine automatische Prüfstrecke ein, die jede Änderung testet, bevor sie live geht. Mehr dazu: Was ist CI/CD und warum brauche ich das beim Vibe Coding?

7. Domain, Datenschutz und Zuständigkeit

• Betreibt die App unter eurer eigenen Domain mit HTTPS.
• Klärt, wo die Daten liegen. Bei Supabase wählt ihr die Region beim Anlegen des Projekts, etwa Frankfurt.
• Schließt mit allen Anbietern, die personenbezogene Daten verarbeiten, eine Vereinbarung zur Auftragsverarbeitung (AVV) ab und passt eure Datenschutzerklärung an.
• Legt fest, wer zuständig ist, wenn etwas ausfällt – mit Namen, nicht mit „irgendwer aus dem Team“.

Die Checkliste zum Abhaken

• Code liegt in einem Repository des Unternehmens
• Supabase-Projekt in einer Firmen-Organisation, mindestens zwei Admins
• RLS auf allen Tabellen aktiv und mit einem zweiten Konto getestet
• Keine geheimen Schlüssel im Frontend
• Backup geprüft, Restore einmal geübt, Storage mitgesichert
• Uptime-Check und Fehler-Tracking aktiv
• Testumgebung getrennt, Migrationen im Repository
• Verantwortliche Person benannt