bolt new login tot nach Launch — Button reagiert nicht

Dein bolt new login wirkte im Editor fertig — und auf der Live-Seite liefert der Button nach dem Launch nichts.

In Bolt.new hast du Anmelden geklickt, Supabase lieferte eine Session, die App routete zum Dashboard. Du deployedest oder verbandest Hosting. Derselbe Button auf der öffentlichen URL navigiert nicht — oder Auth endet wieder auf dem Login-Screen. Nutzer halten das Produkt für kaputt. Meist erreichten Vorschau-Auth-URLs und Umgebungskeys nie den Host, der Produktions-Traffic ausliefert.

Bolt not working after launch clustert oft zuerst um Login, weil Auth der erste Schritt mit externen Diensten ist. Datenbank und Stripe scheitern als Nächstes aus demselben Grund. Dieser Artikel fokussiert Login. Dieselben Handoff-Lücken stehen in der lovable deploy Checkliste — auch wenn du in Bolt statt Lovable gebaut hast.

Der Login-Button reagiert nicht

Das meistgemeldete bolt new login Symptom nach Launch.

• Anmelden klicken — keine Navigation, kein Popup, kein Toast
• Konsole: supabaseUrl is required oder undefined Env-Namen
• Network-Tab still — Client rief signInWithOAuth nie auf
• Button-Handler hängt noch an Bolt-only Variable
• Third-Party-Cookies blockiert — selten auf Custom Domains

DevTools auf der Live-URL öffnen, nicht in der Bolt-Vorschau. Fehlende VITE_SUPABASE_URL oder VITE_SUPABASE_ANON_KEY in der Host-Umgebung ist Top-Ursache. Bolt injizierte sie für die Vorschau. Netlify, Vercel oder statischer Host-Build nicht.

Vergleich mit lovable login — gleiches Empty-Env-Muster, andere Editor-Hülle. Fix bleibt: Keys in Production-Env, redeployen, Supabase-URLs korrigieren.

Bolt not working after launch — Auth-Schleifen

Feuert der Button, hängt Login aber nie — Redirect-Hölle.

Magic Link zurück zum Login

Mail kommt. Link öffnet die Seite. Session bleibt nicht. Site URL in Supabase zeigt noch auf localhost oder Bolt-Vorschau-Host.

Google OAuth dreht sich

Google bestätigt. Browser leitet. Du landest wieder beim Login. Autorisierte Redirect-URIs in Google Cloud passen nicht zum Supabase-Callback für deine Live-Domain.

Passwort-Reset öffnet localhost

Reset-Mail verlinkt http://localhost:5173. Nutzer auf dem Handy erreichen deinen Dev-Rechner nicht.

Spiegelbild zu supabase auth Vorschau-vs-Live. Bolt aktualisiert Supabase nicht automatisch, wenn sich dein öffentlicher Hostname ändert.

Warum Bolt Auth auf die Vorschau zeigte

Bolt erzeugt gegen die sichtbare Umgebung — Bolt-Vorschau-Origin. Supabase-Client erbt sie. redirectTo-Beispiele nutzen localhost, weil Supabase so defaultet. Der Agent optimiert grüne Vorschau, nicht deine spätere Netlify-Subdomain.

Git verbinden kopiert keine Supabase URL Configuration. Hosting verbinden kopiert keine Bolt-Integration-Secrets ohne Abschrift. Launch-Tag ist das erste Mal, dass das Live-Bundle Production-Env liest — und Supabase Traffic von einer Origin sieht, die du nie whitelisted hast.

bolt new login Schritt für Schritt fixen

1. Launch und Live-Origin kopieren. Mit https://. Kein trailing slash, außer Router verlangt es.
2. Verknüpftes Supabase-Projekt öffnen — derselbe Ref wie in Bolt-Vorschau.
3. Authentication → URL Configuration. Site URL auf Live-Origin.
4. Redirect URLs ergänzen. Live, Bolt-Vorschau, localhost falls du lokal devst.
5. Hosting Env-Vars. Supabase URL und Anon-Key mit Production-Scope. Redeploy.
6. Google Provider. Google Cloud Redirect-URIs an https://<ref>.supabase.co/auth/v1/callback.
7. Code nach hardcoded localhost in redirectTo — ersetzen durch window.location.origin oder env-gesteuerte Origin.
8. Redeploy nach Code- und Env-Änderungen.
9. Privates Fenster auf Live-URL — E-Mail- und Social-Login je einmal testen.

Frische Magic Links nach URL-Änderungen. Alte Mails zielen noch auf alte Hosts.

Scheitert Login nach URLs und Env-Vars, Supabase Auth-Logs mit deiner Live-Domain Zeichen für Zeichen vergleichen. Ein trailing slash oder http statt https in der Site URL allein kann den Button am Leben lassen, während Sessions nie haften.

Checkliste vor Launch

• Supabase Site URL entspricht exakt der Live-Origin
• Redirect URLs: Live, Vorschau, lokale Dev-Origins
• Production-Host hat Supabase URL und Anon-Key — nicht nur Bolt-Vorschau
• Redeploy nach Env-Änderungen
• Kein localhost in Production-Auth-Mails oder OAuth-Redirects
• Google Redirect-URIs inkl. Supabase-Callback für aktives Projekt
• Auth-Logs: redirect_uri passt zur Live-Domain
• Anmeldung auf Live-URL in sauberer Browser-Session getestet

Vorschau-Login beweist die UI. Live-Login beweist URL Configuration und Env-Vars auf dem Host.

FAQ

Warum funktioniert bolt new login in der Vorschau, nach Launch nicht?

Bolt-Vorschau läuft auf einem Hostnamen, den Supabase kennt. Production- oder Netlify-URL steht erst in Site URL und Redirect URLs, wenn du sie einträgst. Der Client liest evtl. Env-Vars, die nur in Bolt existieren.

Was wenn der bolt new login Button gar nicht reagiert?

Browser-Konsole auf fehlende Supabase-Keys, blockierte Popups oder ungültige redirectTo-Werte prüfen. Leere Env auf dem Host ist nach Launch häufigste Ursache — Handler bricht ab, bevor Auth öffnet.

Worin unterscheidet sich bolt new login von lovable login?

Gleiche Supabase URL Configuration und Env-Lücken, anderer Export-Pfad. Bolt übergibt an Git oder Host, den du manuell verbindest. Live Redirect URLs und Production-Keys setzt du selbst.