Login broke after I added my custom domain (Supabase redirect URLs)

Short answer: your login provider still thinks your app lives at the old address. In Supabase, go to Authentication → URL Configuration, set the Site URL to your new domain and add it to Redirect URLs (for example https://yourdomain.com/**). If your app asks to send people somewhere that isn't on that list, Supabase quietly sends them to the Site URL instead, which is often the old preview link or localhost.

Signs this is your problem

The confirmation or password-reset email opens the preview link, localhost, or a page that says the link is invalid.
Google sign-in finishes, then lands on the old address.
Everything works on the preview link but not on your real domain, or the reverse.

Fix it in Supabase

Open your project, then Authentication → URL Configuration.
Set Site URL to the address customers use, like https://yourdomain.com. This is the default place people are sent after confirming their email.
Under Redirect URLs, add every address your app sends people back to. Wildcards are allowed, so https://yourdomain.com/** covers every page. Add https://www.yourdomain.com/** too if people can reach the www version.
Keep your preview link in the list if you still test there, and remove addresses you no longer use.
If you edited the email templates, check the links in them. A template that builds its link from the Site URL follows step 2, so set that first.

Then check your app's code

AI builders often write the old address straight into the code, for example as the emailRedirectTo or redirectTo option when signing up, resetting a password or signing in with Google. Search your project for the preview domain and for localhost. A safer pattern is to build the address from wherever the app is running:

emailRedirectTo: window.location.origin + "/auth/callback"

Prompt idea for your builder: "Find every hardcoded preview URL or localhost in the auth code and replace it with window.location.origin, so sign-up, password reset and OAuth redirects work on my custom domain."

www and non-www are different sites

To a browser, yourdomain.com and www.yourdomain.com are different places, and a login on one isn't shared with the other. Pick one, redirect the other to it in your host's domain settings, and make sure the Site URL uses the one you picked.

Google and other sign-in providers

With Supabase handling Google sign-in, the redirect address in your Google Cloud settings is your Supabase project's callback (https://<your-project>.supabase.co/auth/v1/callback), and it doesn't change when you add a custom domain. Where people land afterwards is controlled by the Supabase settings above.

Using Firebase or Clerk instead?

Firebase: open Authentication → Settings → Authorized domains and add your custom domain. Sign-in from a domain that isn't listed is refused.
Clerk: development and production are separate instances. Going live on your own domain means setting up the production instance with your domain and its DNS records, and using the production keys.

Test like a new customer

Open a private window on your real domain and go through it all: sign up with an email you haven't used, click the confirmation link, log out, log back in, and reset your password. A private window matters: your normal browser is probably still logged in, which hides the problem.

Check your live app in under a minute

AppFirstAid's free check looks at your live site from the outside: leaked keys, files left in public, safety settings, and whether your sign-up, login and checkout pages open. No signup. Journey tests that sign up, log in and try checkout like a real customer are coming soon (email us to hear when).

Run the free check

Settings move around as these tools update. If a menu name has changed, look for the same words nearby. Spotted something out of date? Tell us.