LovableSupabase

How to Fix Lovable Authentication Breaking in Production

Auth works locally in your Lovable app but breaks the moment users hit the deployed site. Why this happens and how to fix it.

TL;DR

Lovable auth breaks in production for one of four reasons: the redirect URL is not whitelisted in Supabase Auth settings, cookies are blocked by SameSite or Secure flags, the wrong Supabase URL is in production env, or email confirmation is enabled but no SMTP is configured.

What is actually happening

Lovable scaffolds Supabase Auth with sensible defaults that work in the editor. In production, the auth flow has to round-trip through Supabase's hosted auth service and back to your domain. Any mismatch in URLs, cookies, or settings breaks the entire flow even though every individual piece looks correct.

The fix, in order

Try these in sequence. Most apps are fixed by the first or second step.

  1. 1

    Whitelist your production URL in Supabase Auth

    In the Supabase dashboard, go to Authentication then URL Configuration. Add your production domain to both the Site URL field and the Redirect URLs allow-list. Format: https://yourapp.lovable.app or your custom domain. Without this, Supabase rejects the redirect after login and the user lands on a blank page.

  2. 2

    Check that production env vars match the right Supabase project

    In Lovable project settings, go to Environment Variables. Confirm NEXT_PUBLIC_SUPABASE_URL and NEXT_PUBLIC_SUPABASE_ANON_KEY are set for Production and point to the same Supabase project as your data. Lovable sometimes spins up a second project during recovery and accidentally points half the env vars at it.

  3. 3

    Configure SMTP if email confirmation is enabled

    Supabase ships with a default SMTP that throttles to 4 emails per hour and is not for production. In the Supabase dashboard, go to Authentication then Email Templates. If email confirmation is on (which is the default), set up a real SMTP provider like Resend or Postmark under Project Settings then Auth then SMTP. Without it, signups silently never receive confirmation emails.

  4. 4

    Verify cookie settings in your auth helper

    If you are using @supabase/ssr or @supabase/auth-helpers, the cookie config matters. In production, cookies must have Secure: true and SameSite: 'lax' to round-trip. Lovable usually sets these correctly but a regenerated auth file may have lost them. Search your codebase for 'cookieOptions' or 'createServerClient' and confirm the settings.

  5. 5

    Test with an incognito window using a fresh email

    Browser cookies and localStorage from earlier failed attempts can persist and make the issue look worse than it is. Open an incognito window, sign up with a new email, and watch the network tab. The failing request will be obvious.

When to stop debugging and get help

If you have walked through all five steps with no improvement, the auth flow likely has a deeper issue, often a custom callback handler that was generated incorrectly, or RLS policies blocking the user record creation. These need real code review.

Stuck after trying these?

We do a $100 Quick Audit that pinpoints exactly what is wrong, why, and what it will take to fix. No sales call gating, no fluff.

Start a $100 Audit

Related fixes

Not sure exactly what is broken? Run a free scan and get a diagnosis in under 2 minutes.