Lovable not working nach Publish — weißer Bildschirm statt Vorschau

Lovable not working nach Publish heißt meist: Vorschau war grün, die Live-URL zeigt weißen Bildschirm, endlosen Spinner oder eine Hülle ohne Daten.

Du hast im Editor gebaut. Routen liefen. Buttons reagierten. Du hast publisht und den Link geteilt. Andere sehen nichts. Du auch im privaten Fenster. Dasselbe Projekt läuft in der Vorschau weiter. Production und Vorschau sind nicht dieselbe Runtime — und die Lücke wirkt als Stille statt als freundliche Fehlermeldung.

Was du siehst, wenn lovable not working Production trifft

Symptome clustern sich. Erkenne dein Muster, bevor du den falschen Fix jagst.

• Weiße oder leere Seite. HTML lädt. Das Root-Div bleibt leer. Konsole zeigt JavaScript-Fehler oder fehlgeschlagenen Chunk.
• Spinner ohne Ende. Auth- oder Daten-Fetch hängt, weil Env-Vars auf dem Live-Host undefined sind.
• Login in Vorschau, tot live. Anmeldung hängt in Schleife oder tut nichts nach Publish. Auth-URLs zeigen oft noch auf localhost.
• API-Routen mit 500. Server-Handler crashen, weil process.env-Keys Production nie erreicht haben.
• Teil-UI. Navbar rendert. Hauptinhalt leer, weil Supabase Berechtigungsfehler zurückgibt, die die Vorschau nie hatte.
• Custom Domain nur per HTTP. Browser blockiert Mixed Content oder Skripte, wenn SSL noch nicht bereit ist.

Jedes Symptom wirkt wie „die App ist kaputt“. Meist fehlen Einstellungen, die der Editor nie abgefragt hat. Der lovable deploy-Hub listet die fünf Production-Bereiche, die zusammen scheitern.

Warum die Vorschau läuft und lovable not working live zeigt

Lovable optimiert die Build-Schleife im Editor. Die Vorschau läuft auf Infrastruktur, die die Plattform kontrolliert. Integrations-Keys für Supabase, Stripe und OAuth existieren oft nur in diesem Kontext. Die KI verdrahtet signInWithOAuth, Fetch-Calls und Client-Keys gegen Hosts, die dort schon funktionieren.

Publish kopiert dein Frontend auf eine Live-URL — oft *.lovable.app oder ein verbundenes Vercel-Projekt. Dieser Host erbt nicht jedes Secret aus dem Chat-Panel. Redirect-URLs in Supabase listen noch localhost. Stripe-Webhooks zeigen noch auf einen Tunnel, den du geschlossen hast. RLS kann in der Vorschau aus sein, weil du mit Service Role oder Demo-Session getestet hast.

Build-Fehler unterscheiden sich ebenfalls. Die Vorschau kann ein Dev-Bundle servieren, das fehlende optionale Imports toleriert. Production-Minifizierung legt tote Code-Pfade offen. Ein falscher Import-Pfad crasht den ganzen React-Tree. Nutzer sehen weiß. Das Deploy-Log zeigt die echte Zeilennummer.

Das heißt nicht, Lovable habe deinen Code „verloren“. Es heißt: Last-Mile-Production-Config war nie auf den Hostname ausgerichtet, den Nutzer wirklich öffnen.

Foren zu lovable not working nennen selten eine einzelne kaputte Komponente. Sie nennen Publish-Tag: leere Env, Auth auf localhost, Chunk-404. Das ist eine Checkliste — nicht sieben getrennte Rätsel.

Lovable not working Schritt für Schritt beheben

In dieser Reihenfolge arbeiten. Überspringen kostet einen weiteren Publish-Zyklus.

1. Live-URL im privaten Fenster öffnen. Gecachte Sessions und alte Service Worker umgehen. Exakte URL mit https:// notieren.
2. Browser DevTools → Konsole. Ersten roten Fehler kopieren. Häufig: undefined is not an object bei Supabase-URL, Failed to fetch auf API-Routen, ChunkLoadError nach Deploy-Mismatch.
3. Hosting-Deploy-Log prüfen. In Lovable oder verbundenem Vercel die letzte Production-Deployment öffnen. Build muss grün sein. Warnungen zu fehlenden Env-Vars lesen.
4. Jede Env-Var nach Production kopieren. Namen exakt treffen: VITE_SUPABASE_URL, VITE_SUPABASE_ANON_KEY, Stripe-Keys, Webhook-Secrets. Nach Speichern redeployen.
5. Supabase Site URL und Redirect URLs aktualisieren. Site URL auf Live-Origin setzen. Vorschau, Live und localhost zu Redirect URLs hinzufügen. Siehe lovable login.
6. Prüfen, ob JS-Chunks laden. Network-Tab: kein 404 auf assets/*.js. Falscher Base-Path oder alter Cache verursacht leere Seiten nach Redeploy.
7. Auth und einen Datenschreibvorgang testen. Frisch anmelden. Zeile einfügen. Wenn Vorschau lief und Live scheitert: Supabase-Projekt-IDs vergleichen — zwei verschiedene Projekte sind ein stiller Killer.
8. Erneut aus Lovable publishen. Nach Dashboard- und Env-Fixes nochmal publishen, damit das Bundle zum aktuellen Code passt.

Zeigt die Konsole Stripe- oder Webhook-Fehler: Live-Endpoint registrieren, bevor du nochmal testest. Bei RLS-Verletzungen: Policies aktivieren, bevor du die UI beschuldigst.

Checkliste, bevor du lovable not working als gefixt wertest

• Live-URL lädt ohne weißen Bildschirm im privaten Fenster
• Konsole hat keine uncaught Errors beim ersten Paint
• Jeder process.env / import.meta.env-Name existiert im Production-Hosting
• Supabase Site URL passt zum Live-Origin
• Redirect URLs enthalten Live und Vorschau
• Auth schließt ab ohne Rückkehr zum Login
• Mindestens ein echter Insert oder Read funktioniert unter Anon-Key + RLS
• Custom Domain zeigt gültiges HTTPS, falls genutzt

Wenn mehrere Punkte falsch waren: URLs und Env zusammen fixen. Teilfixes lassen lovable not working an einem anderen Button hängen.

FAQ

Warum ist lovable not working nach Publish, obwohl die Vorschau lief?

Die Vorschau läuft auf Lovable-Infrastruktur mit Keys und URLs, die der Editor schon injiziert hat. Production nutzt einen anderen Origin, Build-Output und Env-Vars, die du manuell setzen musst. Fehlende Secrets oder falsche Auth-URLs zeigen sich oft als leere Seite statt klarer Fehlermeldung.

Wie debugge ich einen weißen Bildschirm nach Lovable-Publish?

Live-URL im privaten Fenster öffnen, Browser-Konsole auf rote Fehler prüfen, Deploy-Log des Hostings lesen. Nach undefined Env-Vars, fehlgeschlagenen Imports und 404 auf JS-Chunks suchen. Env in Production fixen, neu deployen, Hard-Refresh.

Reicht Republish allein, wenn lovable not working ist?

Republish holt Code-Änderungen, aber nicht fehlende Supabase Site URL, Stripe-Webhooks oder Vercel-Production-Env. Diese Einstellungen musst du erst an die Live-Domain anpassen, dann erneut publishen.