Login loop, or your signup email points at localhost

Auth worked fine while you were building in Lovable, Bolt, or v0. Then you deployed to your real domain and one of these started: login succeeds and instantly bounces you back to the login page; the "confirm your email" link opens localhost:3000 and dies; or Google sign in returns you to the wrong site. Nothing is wrong with your auth code. Your Supabase project still thinks the app lives at its old address.

Why deploying breaks auth

Supabase auth does not trust the page that asks for a redirect. It only ever sends users, confirmation links, and OAuth callbacks to URLs on an allowlist stored in your Supabase project settings. While you were building, the AI tool set that allowlist to its own preview URL or localhost. Your deployed domain is not on the list, so Supabase falls back to the old Site URL. The tool that generated your app cannot see this setting, which is why asking it to fix the login loop goes in circles: the bug is not in the code it can edit.

The five minute fix

1. Open your Supabase dashboard, pick your project, then Authentication, then URL Configuration.
2. Set Site URL to your real deployed address, for example https://yourapp.vercel.app or your custom domain. Exact protocol and host, no trailing path needed.
3. Add your deployed address to Redirect URLs. If you still develop locally, also keep http://localhost:3000 (or whatever port you use) in the list. Wildcards like https://*-yourteam.vercel.app/** are allowed if you use Vercel preview deploys.
4. If you use Google or GitHub sign in, also check that provider's console: the OAuth callback must be your Supabase project callback (https://YOURPROJECT.supabase.co/auth/v1/callback), which does not change per deploy, so it is usually fine. The redirect problem is almost always on the Supabase side.
5. Send yourself a fresh signup email and click it. Links in old emails still point at the old URL, so test with a new one.

If it still loops after the URLs are right

• The session never persists. Watch devtools, Application tab, Local Storage. If the sb-...-auth-token entry appears on login and vanishes on redirect, the code is creating more than one Supabase client, or a misused onAuthStateChange handler is signing you out. One shared client instance, created once, fixes most of these.
• The route guard runs before the session loads. AI builders love a guard that redirects to /login whenever user is null. On a hard page load the session takes a moment to restore, so the guard fires first and you loop. The guard has to wait for the auth state to finish loading before deciding.
• Missing env vars on the deploy. If the deployed site cannot reach Supabase at all (check the Network tab for failing requests to supabase.co), your hosting platform is missing VITE_SUPABASE_URL and the anon key. Preview environments do not export their env vars with your code.

Still stuck?