Matt Turley, Continuum. Updated November 8, 2026.
Supabase login fails for a short list of reasons, and the most common is a Site URL or redirect list that still points at localhost. Check that setting before anything else, then email confirmation and the session cookie, and leave your database rules alone.
Sign in works on your laptop. On the live site the user logs in, then lands on a localhost address, or bounces back to the login page in a loop. Supabase keeps its own Site URL and its own list of allowed redirect addresses, and a new project starts with localhost in both.
In the Supabase dashboard, open Authentication, then URL Configuration. Put your real domain in Site URL and add the live callback address to the redirect list. Preview links on Vercel or Netlify are different addresses, so add a pattern for them too. If you use Google or GitHub sign in, the provider has a third list that must match exactly. That case has its own page, OAuth callback not working.
Supabase asks new users to confirm their email by default. If the confirmation message never arrives, nobody can log in, and from the outside it looks like auth is broken. The built in email sender is meant for testing. It is rate limited and sends only to a short list of addresses, so real customers can wait forever for a message that was never sent.
Connect a real email provider in the project settings before launch. If you only need the app to work today, you can switch confirmation off, but know that anyone can then sign up with any address. The causes of a missing message are covered in sign up email not arriving.
In a Next.js app, the session lives in a cookie, and the server has to read it and refresh it on each request. AI builders often wire up the browser client only. The user signs in, then a server page renders as if nobody were there, or a refresh logs them out.
Supabase publishes a package for this, called @supabase/ssr, and recommends that server code ask for the user with getUser instead of trusting the cookie alone. Check that your middleware refreshes the session and that it does not run on files that should stay public. A redirect rule that sends every signed out visitor to login, including the login page itself, makes the loop people describe.
Production has its own environment variables. If the live site still carries the keys from a test project, or none at all, users who signed up in one project cannot log in to the other. Open the live site, look at the network requests, and confirm the Supabase address matches the project you are editing in the dashboard.
The public anon key belongs in the browser. The service role key never does, because it skips every access rule you wrote.
This one is not an auth problem at all. Row level security, the rules that say who can read which row, returns an empty list instead of an error when a rule says no. The user is logged in correctly and the screen shows nothing, so people assume login is broken.
The tempting fix is to turn row level security off so the data appears. Do not. In our scan of 500 live apps built with AI tools, 177 used Supabase, and 31 of those, 17.5%, had at least one table that a stranger could read with no login. Read the full scan for how we counted. The right fix is a rule that lets the signed in user see their own rows, which the page on Supabase row level security off walks through.
If you have gone through these and login still fails, the cause is usually spread over the dashboard and the code at once, and it is quicker to have it read by someone who has seen it before. A written read of your codebase is $299 as a Ship Check. If the fix turns out to be larger, Ship Fix runs $4,000 to $15,000, agreed before work starts. If you also want your database rules checked, see the Supabase security review.
Tell me what the user sees and where. You get a straight answer on whether it is a setting or a code fix.