DEV Community

Sora2 Hub Team
Sora2 Hub Team

Posted on Originally published at massvai.com

Next.js + Supabase Auth Cookies: 6 Checks That Stop Silent Logouts

AI-scaffolded Next.js apps often work on localhost and then log users out on the first production visit. The UI looks fine. The session is gone. Nine times out of ten the bug is cookie config, middleware refresh, or a Preview/Production env mismatch — not "Supabase is down."

Use this checklist before you point real users at the deploy.

1. Match cookie domain to the real host

If the app lives on app.example.com, the auth cookie domain has to cover that host. A cookie set for localhost or a bare apex while users hit a subdomain looks like a random logout after deploy.

Check:

  • Production host vs cookie Domain
  • Whether you need a leading-dot parent domain for subdomains
  • That Preview deployments are not accidentally writing Production cookie settings

2. Use Secure + SameSite correctly

Production must set Secure cookies over HTTPS. Prefer SameSite=Lax for standard server-rendered auth flows unless you truly need cross-site POSTs.

Common failure mode: local HTTP without Secure works; Production HTTPS with a Lax/Strict mismatch on a cross-site return path drops the session after OAuth.

3. Keep middleware and the browser client on the same project

Preview and Production should each point at the intended Supabase project. Mixing keys across environments creates "logged in on Preview, empty on Production" bugs that look like flaky auth.

Checklist:

  • NEXT_PUBLIC_SUPABASE_URL and anon key match the project you expect per environment
  • Service role key never ships to the browser
  • Middleware uses the cookie-aware server client, not a second ad-hoc client

4. Refresh the session in middleware, not only on page load

If middleware never refreshes the session cookie, long-lived tabs expire and the next navigation looks like a hard logout. Refresh on the edge (middleware / proxy) so every document request has a chance to rotate tokens before the page renders.

Skipping this is the most common "it worked yesterday" report after someone left a tab open overnight.

5. Allowlist redirect URLs in Supabase Auth

Add every Preview URL pattern you use plus the production domain. Missing entries break magic links and OAuth return paths. Vercel Preview URLs change; either use a wildcard pattern your plan allows or a stable Preview domain.

Also verify the Site URL in Supabase Auth settings matches Production, not an old staging host.

6. Test two browsers after a password change

Change the password once, then confirm other sessions invalidate the way you expect. Surprises here are security bugs, not UX quirks. Repeat with an OAuth-linked account if you offer social login.

Bonus: middleware allowlist for public routes

While you are in the auth path, confirm marketing pages, /login, /auth/callback, and health checks are not forced through a session gate that redirects loops. AI scaffolds often protect / too aggressively.

Quick pre-ship script

  1. Incognito → sign in on Production URL
  2. Hard refresh and navigate three authenticated routes
  3. Open the same account in a second browser → change password → confirm first session behavior
  4. Trigger a magic link from a Preview URL you actually use
  5. Watch the Network tab for Set-Cookie on the document response after middleware

If all five pass, silent logouts are unlikely to be cookie-related.


Building full-stack Next.js + Supabase apps with an AI builder? Massvai scaffolds deploy-ready structure so you spend time on checks like these instead of rewriting the same auth boilerplate.

Top comments (0)