Teil von Vibe Code Rescue

Ihre Lovable-App, von der Vorschau in die Produktion.

Lovable schreibt ein React-Frontend auf Supabase. Die Lücken liegen dort, wo eine Vorschau nie hinschaut: wer welche Zeilen lesen kann, welche Keys den Browser erreichen, was der Server prüft.

  • Unter 24 Stunden für das kostenlose schriftliche Audit
  • Jede Policy gelesen, Tabelle für Tabelle
  • Tag eins für einen offengelegten Service-Role-Key
  • Ab $10k für die Stabilisierung

Wie bringen Sie eine Lovable-App in die Produktion?

Behandeln Sie die Supabase-Datenbank als Sicherheitsgrenze, denn in einer Lovable-App ist sie das. Der Browser spricht direkt mit Supabase, also braucht jede Tabelle Row-Level Security mit den richtigen Policies, und im Bundle darf kein Service-Role-Key liegen. Dann Migrationen für das Schema und Tests für die Edge Functions. Bushido beginnt mit einem kostenlosen schriftlichen Audit in unter 24 Stunden.

Für wen

Sie brauchen das, wenn

  • Nutzer können die Daten der anderen sehen, oder Sie können nicht beweisen, dass sie es nicht können.
  • Ein Service-Role-Key im JavaScript, das der Browser herunterlädt.
  • Admin-Ansichten, in der Oberfläche versteckt, aber in der Datenbank offen.
  • Keine Migration, die zum Live-Schema passt.

Inklusive

Was Sie bekommen

  • Jede Supabase-Policy gelesen, Tabelle für Tabelle.
  • Offengelegte Keys rotiert und in Edge-Function-Secrets verschoben.
  • Berechtigungsprüfungen in der Datenbank und in den Edge Functions, nicht nur in React.
  • Das Schema in versionierten Migrationen und ein separates Staging-Projekt.
  • Tests für die Edge Functions, die mit Geld oder personenbezogenen Daten arbeiten.

Zeitplan

So läuft Lovable in die Produktion

  1. Unter 24 Stunden

    Das Audit

    Wir lesen das Repository und das Supabase-Projekt und behandeln jeden Key, der je in Git committet wurde, als offengelegt.

  2. Tage

    Die Daten absichern

    Row-Level Security auf jeder Tabelle mit Nutzerdaten, ausgeliefert mit ihren Policies, damit die App nicht plötzlich leer ist.

  3. Wochen

    Migrationen und Tests

    Migrationen für Staging und Produktion und Tests für die Edge Functions, die Geld annehmen.

  4. Bei der Übergabe

    Regeln fürs Prompten

    Eine Pipeline, die jeden Merge prüft, und Regeln dafür, was gepromptet wird und was ein Entwickler prüft.

Preis

Was Lovable in die Produktion kostet

Erster Schritt
Ein kostenloses schriftliches Audit der App und ihres Supabase-Projekts, in unter 24 Stunden
Danach
Stabilisierung ab $10k; eine vollständige Rettung $20k bis $50k

Wenn ein Neubau außerhalb von Lovable günstiger ist als die Reparatur, sagt das Audit es zuerst.

Ergebnisse

Produkte, die wir ausgeliefert haben.

誠実

“They are honest and they give us ideas about how to improve our entire system.”

Petr P. CEO, Shovel seijitsu, Ehrlichkeit Zur Fallstudie Shovel →

Fragen

Häufige Fragen zu Lovable in die Produktion.

Warum eine eigene Seite für Lovable?

Lovable-Apps teilen einen Stack und dieselben Fehlerquellen. Lovable hat 60 Millionen Projekte überschritten, und 4 von 5 der Menschen, die darauf bauen, haben keinen technischen Hintergrund.

Ist eine Lovable-App standardmäßig unsicher?

Nicht von Haus aus, aber ihre Sicherheit steckt in den Supabase-Policies, wo ein Prompt selten hinschaut. CVE-2025-48757 hat die Lücke festgehalten: 170 von 1.645 Lovable-Showcase-Apps ließen jeden die Nutzerdaten lesen. Lovable hat gesagt, dass Apps mit sensiblen Daten weiterhin externe Sicherheitsexperten brauchen.

Ist der Supabase-Key in unserem Frontend ein Problem?

Der Anon-Key ist dafür gedacht, öffentlich zu sein. Der Service-Role-Key umgeht die Row-Level Security; ist er im Bundle, rotieren wir ihn und verschieben ihn am ersten Tag in ein Edge-Function-Secret.

Können wir nach der Rettung in Lovable weiterbauen?

Oft ja: Ansichten, Texte und Layout bleiben in Lovable; Policies, Migrationen und Edge Functions nicht. Ein Prompt, der eine Korrektur rückgängig macht, fällt durch eine Prüfung.

Müssen wir Supabase verlassen?

Meist nicht; es ist Postgres und kann eine App in Produktion tragen. Es braucht Policies auf jeder Tabelle, Migrationen im Repository und ein Backup, das jemand schon einmal wiederhergestellt hat.

Ein Weg nach vorn.

Dreißig Minuten mit einem Builder, nicht mit einem Verkäufer, um herauszufinden, ob wir das richtige Team dafür sind. Wenn nicht, sagen wir es.