Bolt new login dead after launch — button does nothing

Your bolt new login flow looked done in the editor, then the live site gave you a button that does nothing after launch.

Inside Bolt.new you clicked sign in, Supabase returned a session, and the app routed to the dashboard. You deployed or connected hosting. The same button on the public URL does not navigate, or auth completes and dumps you back on the login screen. Users assume the product is broken. Usually preview auth URLs and environment keys never reached the host that serves production traffic.

Bolt not working after launch often clusters around login first because auth is the first action that touches external services. Database and Stripe fail next for the same reason: settings that were true in preview were never copied to production. This article focuses on login. The same handoff gaps appear in the broader lovable deploy checklist even when you built in Bolt instead of Lovable.

The login button does nothing

This is the most reported bolt new login symptom after launch.

• Click sign in — no navigation, no popup, no toast
• Console shows supabaseUrl is required or undefined env names
• Network tab silent because the client never called signInWithOAuth
• Button handler still gated on a Bolt-only variable
• Third-party cookies blocked — rare on custom domains, common in embedded previews

Open DevTools on the live URL, not on Bolt preview. Missing VITE_SUPABASE_URL or VITE_SUPABASE_ANON_KEY in the host environment is the top cause. Bolt injected them for preview. Your Netlify, Vercel, or static host build did not.

Compare with lovable login — same empty-env pattern, different editor shell. The fix is still: copy keys to production env, redeploy, then fix Supabase URLs.

Bolt not working after launch — auth loops

When the button does fire but login never sticks, you are in redirect hell.

Magic link returns to login

Email arrives. Link opens your site. Session never persists. Site URL in Supabase still points at localhost or a Bolt preview host.

Google OAuth spins

Google approves. Browser redirects. You land on login again. Authorized redirect URIs in Google Cloud do not match the Supabase callback for your live domain.

Password reset opens localhost

Reset email links to http://localhost:5173. Users on phones cannot reach your dev machine. They abandon.

These mirror supabase auth preview-vs-live mismatches. Bolt does not auto-update Supabase when your public hostname changes.

Why Bolt pointed auth at preview

Bolt generates against the environment visible during chat. That is the Bolt preview origin. Supabase client setup inherits it. redirectTo examples use localhost because Supabase defaults do. The agent optimizes for green preview, not your future Netlify subdomain.

Connecting Git does not copy Supabase URL Configuration. Connecting hosting does not copy Bolt integration secrets unless you transcribe them. Launch day is the first time the live bundle reads production env — and the first time Supabase sees traffic from an origin you never whitelisted.

Fix bolt new login step by step

1. Launch and copy the live origin. Include https://. No trailing slash unless your router requires it.
2. Open the linked Supabase project — the same ref Bolt used in preview.
3. Authentication → URL Configuration. Set Site URL to your live origin.
4. Add Redirect URLs. Include live URL, Bolt preview URL, and localhost if you still dev locally.
5. Hosting env vars. Add Supabase URL and anon key with Production scope. Redeploy.
6. Google provider. Match Google Cloud redirect URIs to https://<ref>.supabase.co/auth/v1/callback.
7. Search code for hardcoded localhost in redirectTo and replace with window.location.origin or env-driven origin.
8. Redeploy after code and env changes.
9. Test in a private window on the live URL with email and social login once each.

Send fresh magic links after URL changes. Old emails still target old hosts.

If login still fails after URLs and env vars align, compare Supabase Auth logs with your live domain character by character. A trailing slash or http instead of https in Site URL alone can leave the button alive while sessions never stick.

Launch day is the first time real users hit auth without Bolt holding their hand. Treat URL Configuration and host env vars as part of ship, not a polish task for later.

Pre-launch checklist

• Supabase Site URL matches live origin exactly
• Redirect URLs include live, preview, and local dev origins you use
• Production host has Supabase URL and anon key — not only Bolt preview
• Redeploy completed after env var changes
• No localhost left in production auth emails or OAuth redirects
• Google authorized redirect URIs include Supabase callback for active project
• Auth logs show redirect_uri matching live domain
• Tested sign-in on live URL in a clean browser session

Preview login proves the UI. Live login proves URL Configuration and env vars on the host.

FAQ

Why does bolt new login work in preview but fail after launch?

Bolt preview runs on a hostname Supabase may already trust. Your production or Netlify URL is not in Site URL or Redirect URLs until you add it. The client may also read env vars that exist only inside Bolt, not on the host.

What if the bolt new login button does nothing at all?

Check the browser console for missing Supabase keys, blocked popups, or invalid redirectTo values. Empty env on the host is the most common cause after launch — the handler exits before opening auth.

How is bolt new login different from lovable login fixes?

Same Supabase URL Configuration and env var gaps, different export path. Bolt hands off to Git or a host you connect manually. You still must set live redirect URLs and production keys yourself.