Supabase auth works in preview and fails live

Supabase auth looks perfect in preview, then users hit a blank screen, a redirect error, or land back on the login page after publish.

You click Google or GitHub, enter a password, or tap a magic link. In the Lovable editor, the flow finishes and the app loads. On your live URL, the same button stalls, shows redirect_uri_mismatch, or sends people to localhost. The session never sticks. Your database stays empty of signed-in users even though the UI code never changed.

This is not a random bug in your React components. Supabase validates every login against a whitelist of URLs. Preview uses one hostname. Production uses another. If the dashboard still points at development defaults, live traffic fails the check every time.

Why supabase auth works in preview but fails live

Lovable, Bolt, Replit, and similar tools run your app on a preview hostname while you build. Supabase often ships with http://localhost:3000 or the tool’s preview domain already listed. Auth succeeds there because the callback URL matches.

When you publish, the browser loads https://your-app.lovable.app or a custom domain. Supabase receives a callback from that hostname. If Site URL still says localhost, or redirect URLs omit the live path, Supabase blocks the exchange. The user sees an error page or gets bounced to login with no session cookie.

The AI assistant wired signInWithOAuth or email magic links correctly in code. It rarely opens the Supabase dashboard to add your production domain. Code cannot override URL configuration. That gap is why preview and live diverge.

Similar symptoms show up when Lovable login breaks after deploy. The fix lives in dashboard settings, not another prompt to rewrite the auth hook.

Set the Site URL to your production domain

Site URL tells Supabase which origin owns your app. Magic links, password recovery emails, and some OAuth fallbacks use it as the default return target. Leaving it on localhost means production users get links that point at your laptop.

Open your Supabase project. Go to Authentication → URL configuration. Find Site URL. Replace the localhost value with your live origin, including https:// and no trailing slash unless your app requires it.

Examples:

• https://your-app.lovable.app for the default Lovable hostname
• https://app.yourdomain.com after you attach a custom domain

Save the change. Site URL alone does not fix every OAuth flow, but wrong Site URL breaks email links and confuses debugging when callbacks look correct elsewhere.

Add redirect URLs for preview and production

Redirect URLs are the explicit list of paths Supabase may send users back to after sign-in. OAuth providers and PKCE flows compare the full callback URL against this list. A missing entry causes instant failure on live, even when Site URL is correct.

In the same URL configuration screen, scroll to Redirect URLs. Add every origin your app uses:

1. Your Lovable preview URL if you still test there
2. Your published *.lovable.app URL
3. Your custom domain, if configured
4. Wildcard only if you understand the security tradeoff; explicit URLs are safer

Include path variants your stack uses, such as /auth/callback or /, matching what the generated client passes to redirectTo. After adding URLs, click Save. Test login on production in a private window so old cookies do not mask the result.

Redirect URL mistakes are one of the five production settings editors skip. The Lovable deploy checklist groups them with env vars and webhooks so nothing ships half-configured.

Fix Google and GitHub provider callbacks

Social login adds a second whitelist outside Supabase. Google Cloud and GitHub each store authorized redirect URIs. Supabase sends users to the provider, then the provider must send them back to a Supabase callback URL you registered on both sides.

In Supabase, open Authentication → Providers. Enable Google or GitHub if the AI toggled them in code but left the dashboard off. Copy the callback URL Supabase shows for that provider. It looks like https://<project-ref>.supabase.co/auth/v1/callback.

For Google:

1. Open Google Cloud Console → APIs & Services → Credentials
2. Edit your OAuth 2.0 Client ID
3. Under Authorized redirect URIs, add the Supabase callback URL exactly
4. Save and wait a few minutes for propagation

For GitHub:

1. Open GitHub → Settings → Developer settings → OAuth Apps
2. Edit your app
3. Set Authorization callback URL to the same Supabase callback URL
4. Save

Back in Supabase, paste the client ID and secret from Google or GitHub into the provider form. Save again. A mismatch between provider console and Supabase produces redirect_uri_mismatch in the browser, not a helpful stack trace in your app.

Click-path fix in the Supabase dashboard

Run through this sequence once per environment change. Order matters when you are debugging a fresh publish.

1. Supabase project → Authentication → URL configuration
2. Set Site URL to your production origin
3. Add all preview and production URLs under Redirect URLs
4. Save URL configuration
5. Authentication → Providers → Google or GitHub
6. Copy the Supabase callback URL into Google Cloud or GitHub OAuth settings
7. Paste client ID and secret into Supabase → Save provider
8. Hard-refresh your live app and test sign-in in a private window

If magic links still fail, open the email link on the same device and confirm the link host matches Site URL. If OAuth still fails, compare the browser error URL parameter to your redirect list character for character.

Production checklist before you blame the code

• Site URL matches the domain users actually visit in production
• Redirect URLs include preview, default publish host, and custom domain
• Callback paths match redirectTo in your auth calls
• Google and GitHub authorized redirect URIs include the Supabase callback
• Provider enabled in Supabase with correct client ID and secret
• NEXT_PUBLIC_SUPABASE_URL and anon key in production env match the same Supabase project
• Tested in a private window after every dashboard change

When every box is checked, supabase auth behaves the same in preview and live. When one URL is wrong, no amount of AI-generated refactors fixes the session.

FAQ

Why does Supabase auth work in preview but fail after publish?

Preview runs on a URL Supabase already allows. Production uses a different hostname that is missing from Site URL or redirect URLs, so the callback is rejected.

What is the difference between Site URL and redirect URLs in Supabase?

Site URL is the default origin Supabase expects for your app. Redirect URLs are the exact callback paths OAuth and magic links may return to. Both must include production.

Do I need to update Google and GitHub when I add a custom domain?

Yes. Each provider stores its own authorized redirect URI. Add your production Supabase callback URL in Google Cloud Console and GitHub OAuth app settings.