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

  1. Supabase → Authentication → URL Configuration.
  2. Set Site URL to your production domain (with https://).
  3. Add every deploy URL to Redirect URLs: production, custom domain, plus https://*.vercel.app or https://*-yourteam.vercel.app for previews.
  4. In OAuth provider consoles (Google, GitHub, etc.), add https://<project-ref>.supabase.co/auth/v1/callback as an authorized redirect URI.
  5. For SSR, pass an explicit redirect URL from request headers — never use window.location server-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.

Related guides