Lovable deploy — fünf Einstellungen, die der Editor nie abfragt

Dein lovable deploy wirkte fertig, sobald die Vorschau grün wurde — dann wurde Production zu fünf getrennten Bugs unter einer URL.

Publish kopiert dein Frontend auf einen Live-Host. Auth zeigt noch auf localhost. Stripe hört noch auf einen Tunnel, den du gestern geschlossen hast. Supabase akzeptiert noch Reads von jedem mit dem Anon-Key. Env-Vars von deinem Laptop erreichten Production nie. Die Custom Domain zeigt eine Zertifikatswarnung. Jeder Fehler wirkt neu. Es sind dieselben fünf Einstellungen, die der Editor nie bestätigen ließ.

Was du direkt nach lovable deploy siehst

Login hängt in einer Schleife oder tut nichts. Ein Kunde zahlt, deine Datenbank bleibt leer. Speichern verschwindet auf der Live-Seite — oder jeder kann Zeilen über die API lesen. Server-Routen werfen Fehler, weil process.env undefined ist. Eine Custom Domain lädt mit Nicht sicher oder scheitert komplett.

Der Editor optimiert auf „hier zum Laufen bringen“. Live-Traffic braucht URLs, Secrets, Webhooks, Policies und TLS, die du außerhalb des Chat-Panels konfigurierst.

Auth Site URL und Redirect URLs

Supabase sendet Magic Links, Passwort-Resets und OAuth-Callbacks an deine Site URL und Redirect URLs. Beim Build ist das fast immer localhost oder der Lovable-Vorschau-Origin.

Nach Publish hängt Sign-in in Schleifen, Magic Links öffnen localhost, Sessions bleiben nicht. Die KI verdrahtete Auth gegen die Vorschau. Nichts aktualisiert sich beim Publish auf yourapp.lovable.app oder eine Custom Domain, bis du Supabase bearbeitest.

1. Kopiere deinen Live-Origin nach dem Publish, inklusive https://.
2. Öffne das verknüpfte Supabase-Projekt. Vorschau und Production müssen dasselbe Projekt nutzen.
3. Setze Site URL unter Authentication → URL Configuration.
4. Füge Redirect URLs für Live, Vorschau und localhost hinzu, wenn du lokal testest.
5. Aktualisiere OAuth-Provider, damit Google- oder GitHub-Callbacks zu Supabase passen.
6. Republish und teste in einem privaten Fenster mit frischem Magic Link.

Der vollständige Loop-Fix steht im Guide lovable login.

Stripe-Webhook-Endpoint in Production

Checkout klappt, dein Backend bleibt taub. Stripe zeigt bezahlt. Deine Datenbank sagt noch free, weil kein Live-Endpoint checkout.session.completed oder invoice.paid empfängt.

Lokale Entwicklung nutzt stripe listen-Tunnel, die sterben, wenn du das Terminal schließt. Die KI liefert eine Erfolgsseite, die deinen Server nie aufruft. Stripe POSTet nur an URLs, die du registrierst. Localhost-Registrierungen folgen dir nicht in Production.

1. Deploy die Handler-Route zuerst auf deiner Live-Domain.
2. Wechsle zu Live-Stripe-Keys und einem Live-Signing-Secret.
3. Registriere den Live-Webhook in Stripe Dashboard → Entwickler → Webhooks.
4. Abonniere die richtigen Events für Checkout und Abos.
5. Füge whsec_ in Production-Env ein, nie in Client-Code.
6. Führe eine echte Testzahlung durch und bestätige Erfolg im Zustellungsprotokoll.

Der Artikel stripe webhook beschreibt den Paid-but-silent-Walkthrough.

Supabase RLS und Row-Level-Policies

RLS ist auf neuen Tabellen standardmäßig aus. Der Anon-Key landet im Frontend. Ohne Policies kann jeder, der Client-Code liest, Zeilen abfragen, die er nie sehen dürfte.

Nach Publish schlagen Speichervorgänge mit Berechtigungsfehlern fehl, wenn RLS an ist, aber Policies fehlen. Oder Daten wirken ok, während die REST-API offen bleibt. Die KI legt Tabellen und Demo-Zeilen an. Sie überspringt ENABLE ROW LEVEL SECURITY, weil die Vorschau deine Session oder die Service Role nutzte.

Auth-URL-Fehler und RLS-Fehler stapeln sich. Der Artikel supabase auth deckt Site-URL-Setup ab. Hier geht es darum, wer welche Zeilen lesen und schreiben darf.

1. Liste Tabellen mit Nutzerdaten — Profile, Bestellungen, Nachrichten.
2. Aktiviere RLS auf jeder sensiblen Tabelle.
3. Füge Policies hinzu, z. B. auth.uid() = user_id für Select und Insert.
4. Teste mit dem Anon-Key, nicht der Service Role.
5. Bestätige Live-Inserts unter diesen Policies.

Umgebungsvariablen in Production

Die Vorschau liest Secrets, die der Editor kennt. Production liest, was dein Host injiziert. Fehlende Variablen geben undefined an Supabase, Stripe und API-Routen weiter.

Stripe wirft Invalid-Key-Fehler. Supabase startet nicht. Server Actions crashen, während die UI noch rendert. Die KI kopiert .env.example-Muster für die Vorschau. Sie kann Werte nicht in deinen Host pushen.

1. Durchsuche den Code nach jedem process.env– und import.meta.env-Namen.
2. Halte Secrets serverseitig. Nur öffentliche Prefixes gehören ins Browser-Bundle.
3. Trage jeden Namen in den Production-Env-Einstellungen deines Hosts ein.
4. Redeploy nach Änderungen — die meisten Hosts backen Env beim Build ein.
5. Smoke-Test: Login, ein Speichern, eine Zahlung.

Custom Domain und SSL als Launch-Blocker

Du zeigst DNS auf eine neue Domain und erwartest ein Schloss. Stattdessen kommen Zertifikatsfehler, Parkseiten oder Redirect-Schleifen. Das Produkt läuft auf der Default-Subdomain, während der Launch an dem Hostnamen hängt, den du gekauft hast.

Custom Domains brauchen korrektes DNS, Propagationszeit und TLS für den exakten Hostnamen, den Nutzer tippen. Gemischte http://-Assets auf einer https://-Seite erzeugen Warnungen, selbst wenn das Zertifikat gültig ist.

1. Domain beim Host hinzufügen und DNS-Ziele exakt kopieren.
2. Registrar-Einträge aktualisieren — CNAME für www, ALIAS oder A für Apex.
3. Auf DNS und Zertifikatsausstellung warten, bevor du Links teilst.
4. HTTP auf HTTPS umleiten und hardcodierte unsichere Asset-URLs fixen.
5. Supabase- und Stripe-URLs auf die finale Domain setzen, nicht den temporären Vorschau-Host.

Checkliste, bevor du lovable deploy für erledigt hältst

• Auth: Site URL und Redirect URLs passen zur Live-URL. OAuth und Magic Links funktionieren im privaten Fenster.
• Zahlungen: Live-Webhook registriert, Signing Secret in Env, Testzahlung aktualisiert die Datenbank.
• Datenbank: RLS aktiv mit Policies, getestet über den Anon-Key.
• Env: Jede benötigte Variable auf dem Host, Redeploy erledigt.
• Domain: Hostname löst auf, Zertifikat aktiv, HTTPS funktioniert, Callbacks nutzen die finale Domain.

Sind alle fünf Schalter an, beschreiben Vorschau und Production dasselbe Produkt.

FAQ

Warum funktioniert meine Lovable-App in der Vorschau, bricht aber nach dem Publish?

Die Vorschau läuft auf Hosts und Keys, die die KI schon verdrahtet hat. Production nutzt eine andere URL, Live-API-Keys, Webhooks und Supabase-Einstellungen, die du manuell setzen musst. Bis diese fünf Bereiche zu deiner Live-Domain passen, scheitern Auth, Zahlungen und DB-Schreibvorgänge still.

Welche fünf Einstellungen soll ich vor einem lovable deploy prüfen?

Supabase Site URL und Redirect URLs setzen, einen Live-Stripe-Webhook-Endpoint registrieren, Supabase-RLS-Policies aktivieren, jede Umgebungsvariable in Production kopieren und bestätigen, dass deine Custom Domain gültiges SSL hat. Überspringst du eine, trifft der Nutzer auf einen anderen Fehler unter derselben URL.

Setzt Lovable Production-Umgebungsvariablen automatisch?

Nein. Lovable kann Keys für die Vorschau injizieren und Supabase oder Stripe im Editor verbinden. Veröffentlichte Builds lesen aus der Production-Env deines Hosting-Anbieters. Secrets, die nur in lokalen .env-Dateien oder der Vorschau existieren, erreichen das Live-Bundle nicht, bis du sie dort hinzufügst.