A login that works inside Lovable preview and fails only after you publish is telling you something useful: the authentication code may be fine, while the production environment is not describing the same application.
That distinction matters because rewriting the sign-in component is often the wrong first move.
For a Lovable app using Supabase Auth, production login crosses several boundaries: your live domain, the Supabase project, the OAuth provider if you use Google or GitHub, the callback route, and the browser session that must exist when the user returns. One mismatch can make a successful provider login look like an application failure.
TL;DR: debug the redirect chain before the UI
When preview works but production does not, check this order:
- Confirm the live app is using the intended Supabase project.
- Set Supabase Site URL to the official production domain.
- Add the exact production return paths your app uses to Supabase Redirect URLs.
- If you use social login, verify the provider’s callback configuration separately.
- Confirm the app’s
redirectTovalue resolves to the production origin, not preview or localhost. - Test the entire flow in a clean browser session and verify a session actually exists after the redirect.
Do not change all six layers at once. You want to know which boundary failed.
Understand the two redirects people often confuse
A social-login flow can involve two different destinations.
First, the external provider such as Google sends the authentication result to Supabase’s provider callback. Then Supabase sends the user back to your application.
Those are not interchangeable URLs.
For hosted Supabase projects, provider documentation exposes a callback shaped like:
https://<project-ref>.supabase.co/auth/v1/callback
Your application return URL is different. It may be something like:
https://example.com/auth/callback
or simply your production origin, depending on how the app handles the session.
This is why copying your website URL into every field can make the configuration worse.
1. Verify which Supabase project production is actually using
Before editing redirect settings, confirm the live build points to the intended Supabase project.
A preview can work perfectly while a production build uses an old project reference, stale environment value or different public key. In that case, changing URL settings in the project you are looking at will never fix the live app.
Inspect the production configuration and browser network requests. The Supabase hostname should match the project you expect.
Do not expose privileged server credentials while checking this. Browser code should use the public client credential intended for client-side use, not a service-role or secret key.
2. Set Site URL to the real production domain
Supabase documents Site URL as the default redirect destination when your code does not provide redirectTo.
For a production application, this should normally be the official live URL, including HTTPS.
If it still points to localhost, a preview hostname or an old domain, email confirmations, password resets or OAuth flows can send users somewhere that no longer represents the application.
This becomes especially common after connecting a custom domain: the interface moved, but the authentication configuration did not.
3. Allow the return URL your code actually requests
Setting Site URL is not enough when your code supplies redirectTo.
Supabase requires the requested redirect destination to match its configured Redirect URLs. Its current documentation supports wildcards for previews and development, but recommends exact redirect paths for production.
So if your app sends users to:
https://example.com/auth/callback
make sure that exact production path is allowed.
Avoid solving a production problem by allowing an unnecessarily broad wildcard. Preview environments are dynamic; your permanent production domain usually is not.
4. Check what Lovable generated for redirectTo
Now inspect the sign-in call itself.
A common pattern derives the return URL from window.location.origin. That can be useful because preview returns to preview and production returns to production. A hard-coded preview hostname or localhost value, however, can survive into the deployed build.
The important question is not whether redirectTo exists. It is whether the value at runtime matches a URL Supabase allows.
This is also why auth bugs can appear only after a domain migration. The code did not change; the origin did.
5. For Google or GitHub login, verify the provider separately
If email/password works but Google login fails, narrow the problem before touching the rest of auth.
The OAuth provider needs the callback expected by Supabase. Supabase’s social-login documentation exposes the provider callback from the project’s Authentication provider settings and uses the project’s /auth/v1/callback endpoint for hosted flows.
Then Supabase handles the return to your application according to its own Site URL, Redirect URLs and the redirectTo supplied by your client.
Think of it as a chain:
app → provider → Supabase callback → app return URL → established session
Debug the first broken transition, not the last screen you happen to see.
6. Test whether the session survives the return
A redirect reaching /dashboard is not proof that authentication is healthy.
After the user returns, verify that the application can read the authenticated session and load data that requires that identity. Test in an incognito window so an old preview session does not hide the problem.
A useful production test is:
- begin signed out on the canonical domain;
- sign in through the real provider;
- confirm the browser returns to the intended production URL;
- confirm the application recognizes the authenticated user;
- refresh the page;
- open a protected route directly;
- sign out and confirm protected access disappears.
That checks the journey rather than merely checking that a button redirected somewhere.
Do not disable security to make the symptom disappear
Authentication and authorization are different layers.
If login succeeds but the dashboard has no data, inspect the authenticated user, network response and Row Level Security policies. Do not disable RLS as a permanent debugging shortcut.
Likewise, do not place a privileged Supabase key in browser code because a production query is being rejected. A configuration problem should not be repaired by weakening the trust boundary.
Preview success is evidence, not production proof
AI builders make it easy to judge a feature by what happens inside the preview. Production introduces the boundaries the preview can hide: real domains, external provider settings, deployed environment values, email links, cookies, webhooks and permission rules.
That is why my AI-built app production checklist treats production verification as a separate stage from feature completion.
The same principle applies beyond authentication. If an AI-built MVP is 80% complete but the remaining 20% is production configuration, permissions, payments or deployment, rebuilding the visible interface is usually not the highest-value move.
When to stop debugging and get a production review
If you have confirmed the Supabase project, Site URL, redirect allowlist, provider callback and runtime redirectTo, but authentication still fails only in production, inspect the flow as a system rather than adding more prompts.
That means checking the deployed build, network exchange, callback handling, session persistence and protected-data request together.
If you want help taking an AI-built product through that production boundary, see my MVP development service or contact me.
