Guide Deploys
Login works in preview but breaks after deploy (Lovable/Bolt + Supabase)
Short answer
Sign-in worked in the preview. Then you put the app on your real domain and something broke. The confirm email opens localhost. The password reset link goes to the old preview address. Google sign-in ends on an error page or drops people back where they started. Often the app code is fine, and Supabase still thinks your app lives at the old address. Here's where to look, in the order we'd check.
1. Site URL and Redirect URLs in Supabase
In your Supabase dashboard, open Authentication → URL Configuration (direct link). There are two settings here, and they do different jobs.
- Site URL is the default place Supabase sends people after sign-in when your app code doesn't say where to go (that's the
redirectTooption). If it still sayshttp://localhost:3000or a preview address, that's where people end up. Set it to your live address, likehttps://yourapp.com. (Supabase: Redirect URLs) - Redirect URLs is an allow list. When your app does pass a
redirectToaddress, it has to match an entry on this list. Add your live domain here. (Supabase: Redirect URLs)
The allow list accepts wildcards. * matches anything except separators like / and ., and ** matches anything. So https://yourapp.com/** covers every page on your domain. Supabase's docs also show patterns for preview links on Netlify and Vercel, and suggest using exact addresses in production. (Supabase: Redirect URLs)
2. Confirm and reset emails link to the wrong place
The links in Supabase's auth emails are built from these same settings. The default templates use {{ .ConfirmationURL }}, the full confirmation link. Templates can also use {{ .SiteURL }}, which is simply your Site URL. (Supabase: Email templates)
So if your Site URL is still the preview address, any link built from it points there too. And if your app passes a redirectTo, that address has to be on your Redirect URLs list.
What to do:
- Fix the Site URL first (section 1).
- If you've edited your email templates, open them on the Email Templates page in your Supabase dashboard and check for any old address typed in by hand. Links built from
{{ .SiteURL }}or{{ .ConfirmationURL }}follow your settings. (Supabase: Email templates) - After the change, test with a fresh signup and reset email rather than an older one.
3. Google or GitHub sign-in fails on the live domain
OAuth sign-in has two separate lists, and people often update one and not the other.
- In the provider's console (Google Cloud for Google, GitHub's OAuth App settings for GitHub), the redirect or callback address is your Supabase callback, not your app's domain. It looks like
https://<project-ref>.supabase.co/auth/v1/callback. You'll find the exact one on the provider's page in your Supabase dashboard. For Google, it goes under Authorized redirect URIs, and your app's address goes under Authorized JavaScript origins. For GitHub, it goes in Authorization callback URL. (Supabase: Login with Google, Supabase: Login with GitHub) - In Supabase, your live domain goes in Redirect URLs (section 1). That's where Supabase sends people after the provider hands them back. (Supabase: Redirect URLs)
When you move to a new domain, the Supabase callback address stays the same. For Google, add the new domain to Authorized JavaScript origins.
4. A preview address hardcoded in the app
Sometimes the settings are right, and the app itself asks to go somewhere old. Look in your code for the sign-in call and its redirectTo (or emailRedirectTo for signup). If it has a preview address or localhost typed in, every login will try to go there.
Our suggestion: in a browser app, use the address the app is running on (window.location.origin) or your live domain, and make sure that address is on your Redirect URLs list. Supabase's own example uses a small getURL() helper that reads your site URL from an environment variable, so each environment gets the right address. (Supabase: Redirect URLs)
If your Lovable app uses the built-in backend (Lovable Cloud) instead of your own Supabase project, these settings are in Lovable under More → Users → Settings → Advanced. Lovable's docs say it sets the Site URL when you publish and adds a connected custom domain to Redirect URLs for you. If you connected your own Supabase project, you update them in Supabase yourself. (Lovable: Users and authentication)
Symptom to fix
| What you see | Check first |
|---|---|
Confirm or reset email opens localhost or a preview address | Site URL (section 1), then email templates (section 2) |
| After login, you land on the wrong site | redirectTo in your code, and that the live domain is in Redirect URLs |
| Google says the redirect URI doesn't match | Google's Authorized redirect URIs has the Supabase callback address (section 3) |
| GitHub login errors on return | GitHub's Authorization callback URL is the Supabase callback address |
| Works on your domain, fails on preview links | Add a wildcard pattern for preview links to Redirect URLs |
Still stuck?
Want to know if your live app is exposing keys? Our free instant check scans your homepage and its JavaScript for leaked keys and reviews your security headers. It can't see your database.
Want it fixed and deployed for you? Fix & Deploy ($249) is everything in the Security Fix plus the production deploy to one host (Vercel or Netlify, or Lovable or Replit hosting, depending on your builder): env vars, Supabase auth redirect URLs, custom domain with SSL, and a smoke test. See Fix & Deploy
FAQ
Why does my login work in preview but not after deploy?
Supabase still has your old address as the Site URL, or your live domain isn't in Redirect URLs. Update both under Authentication → URL Configuration.
Why does my Supabase confirmation email link to localhost?
The link is built from your Site URL or the redirectTo your app sends. Set the Site URL to your live domain and check your code for a hardcoded localhost.
What redirect URI do I put in Google Cloud for Supabase?
Your Supabase callback address, https://<project-ref>.supabase.co/auth/v1/callback, under Authorized redirect URIs. Your own domain goes under Authorized JavaScript origins and in Supabase's Redirect URLs.
Can I use wildcards in Supabase Redirect URLs?
Yes. * and ** are supported, which helps with preview links. Supabase suggests exact addresses for production.