Error library · Sign-in sends people to the preview
After sign-in, users land on the preview URL or localhost
Someone signs in on your live app, or clicks the link in a confirmation email, and ends up on your builder’s preview address or on localhost.
Why it happens
Your sign-in provider keeps its own note of where to send people afterwards. In Supabase that is the Site URL and the list of redirect URLs. It was set while you were building, so it still points at the preview. The app’s code can ask for another address, but the provider only honours addresses on its list.
Check it in a minute
- Open your live app in a private window and sign in, or request a magic link.
- Look at the address bar once you are through.
- If it is not your live domain, this is it.
How to fix it
Give this to the AI that builds your app: Lovable, Bolt, Cursor, Claude Code or any other.
After signing in on my live app, people are sent to the preview address or to localhost instead of my live domain. My live domain is: [YOUR DOMAIN].
1. In the code, find every place that passes a redirect address to the sign-in provider (signInWithOAuth, signInWithOtp, signUp, resetPasswordForEmail and similar). Make each one use the current site's origin (window.location.origin), not a fixed preview or localhost address.
2. Tell me exactly what to set in the provider's dashboard. For Supabase: Authentication, URL Configuration, the Site URL (my live domain) and the Redirect URLs (my live domain, plus the preview address only if I still need it for testing).
3. If I use Google or another OAuth provider, tell me which authorised redirect address to add there as well.
Do not change how sign-in works otherwise. After the fix, signing in on the live domain must end on the live domain.What Vigilia sees of this
- Sign-in requests that fail on your live site: an expired link, a code the provider rejects. Each is raised with the request that failed.
What it can’t see: The redirect itself. When the address your app asks for is not on the provider’s list, Supabase does not fail: it sends the visitor to its Site URL instead. They are signed in, on the wrong site, and no error is thrown anywhere, so Vigilia does not see it. This one you find by signing in yourself after you publish.
Know before your users tell you
Vigilia watches your live app, explains what breaks in plain language, hands your AI the fix, and confirms it held with real visitors.