Supabase · Deployment guide
Why Supabase auth redirects to localhost in production
Short answer
Supabase auth uses your project's Site URL as the default redirect. If it's still localhost or a preview URL, production users land in the wrong place after sign-in. Fix Site URL and add every domain to the allow-list.
Symptoms
- After signing in on production, browser ends up on http://localhost:3000.
- Magic-link / email-confirmation links contain a localhost URL.
- OAuth redirect URI mismatch errors from Google / GitHub.
- PR previews work for new users, fail for existing ones.
Common causes
- Site URL in Supabase Authentication settings is still localhost.
- Production domain not added to Redirect URLs allow-list.
- Code passes <code>emailRedirectTo: window.location.origin</code> during SSR (origin is undefined).
- Preview deploys (vercel.app, netlify.app) not whitelisted with a wildcard.
- OAuth provider's authorized redirect URI doesn't include /auth/v1/callback for production.
How DeployDoc checks this
- Compares Supabase Site URL against your deployed domains.
- Lists missing redirect URLs (production, custom domain, preview wildcards).
- Detects SSR-unsafe <code>window.location</code> references in auth code paths.
- Verifies OAuth provider redirect URIs match Supabase's /auth/v1/callback.
Fix it manually
- Supabase → Authentication → URL Configuration.
- Set Site URL to your production domain (with https://).
- Add every deploy URL to Redirect URLs: production, custom domain, plus
https://*.vercel.apporhttps://*-yourteam.vercel.appfor previews. - In OAuth provider consoles (Google, GitHub, etc.), add
https://<project-ref>.supabase.co/auth/v1/callbackas an authorized redirect URI. - For SSR, pass an explicit redirect URL from request headers — never use
window.locationserver-side.
When to run a DeployDoc diagnosis
The first time you deploy a Supabase app to a custom domain, or any time auth starts redirecting to the wrong host.