Partly fixable yourself. Settings in Supabase, Lovable, or Clerk, under two hours.
What you see. Login works on the builder's preview address, but on yourdomain.com users get an error or bounce back to the sign-in page.
Why it happens
Auth providers trust a fixed list of addresses, and your new domain is not on it. With Supabase, the Site URL and Redirect URLs under Authentication → URL Configuration decide where users return after email links and social sign-in, and Supabase recommends an exact redirect URL for production. Lovable adds a custom domain to the auth redirect URLs automatically when you use its built-in backend and the domain becomes Live, but if you connected your own Supabase project you must add it yourself. Google sign-in with your own credentials also needs the new redirect URL in Google Cloud Console.
Clerk is stricter. The development instance's keys do not serve a real domain. You create a production instance, swap to pk_live_ and sk_live_ keys, add Clerk's DNS records, supply your own OAuth credentials, and deploy certificates. Clerk notes DNS can take up to 48 hours. Each missed step shows up as a login that fails only on the custom domain.
Fix it yourself
- Open the failing login in a private window and read the error. A Google redirect_uri_mismatch, a Supabase link that lands on localhost, and a Clerk key error each point to a different list.
- Supabase: open Authentication → URL Configuration, set Site URL to
https://yourdomain.com, and add it to Redirect URLs. Keep the preview address too. - Lovable built-in backend: wait until the domain shows Live under Settings → Domains, then confirm More → Users → Settings → Advanced lists the domain.
- Clerk: create a production instance in the dashboard, put the
pk_live_andsk_live_keys in your host's environment variables, add the DNS records from the Domains page, add your own Google credentials, and click Deploy certificates. - Google sign-in: add the new callback to Authorized redirect URIs in Google Cloud Console (see redirect_uri_mismatch).
- Redeploy or republish, then test again in a private window.
When to get an engineer
Stop when the lists are right and it still fails, or when the app uses several providers and you cannot tell which one errors. Tell the engineer the preview address, the live domain, the auth provider, and a screenshot of the error. A one-off check at $49–$800 or a single fix at €99–$990 usually settles it in 1–2 days. If other features also break only on the live domain, read works in preview, breaks on the live site first.
Top-rated companies for Supabase apps
Ranked by our score: published prices, scope of work, AI tools named, timing and a low-risk first step. How we score.
- 1Redlab10.0/10Best for: A full rescue by one team that keeps buildingFree first step · from $490
- 2Vibe Code Rescue (Lev Arakelyan)9.0/10Best for: A one-off check and a cleanupFrom $299
- 3LazyCodeLab9.0/10Best for: A one-off check and a cleanupFrom $399
Check these
Sign-up confirmation and password reset work end to end
Use a real inbox. Check that the link arrives, points to your live domain, and works once.
Signing out really ends the session
Sign out, press Back, and refresh. You should not see private pages or data.
Secrets live in the host's environment settings
Keys belong in environment variables on the server, not in the repository or in front-end code.
Questions
Why did it work on the preview URL?
The builder registered its own preview address with the auth provider when it set up sign-in. Your domain came later and nobody added it. Each provider keeps its own list.
Can I keep using Clerk development keys on my live domain?
No. Clerk's development instance uses shared social login credentials and keys that are not meant for production. Create a production instance and use its live keys.
Sources: Supabase: Redirect URLs; Lovable: Custom domain; Clerk: Deploy to production.
