Bolt.new Auth Not Working After Deploy? The Auth Recovery Playbook (2026)
Bolt.new Auth Not Working After Deploy? The Auth Recovery Playbook (2026)
Bolt.new auth has six layers that can each fail silently: env vars, Site URL, cookies, RLS, session refresh, and middleware. Multiple Bolt.new users on X/Twitter and Trustpilot describe burning tokens on cascading auth bugs without ever shipping a working login flow. Check the layers in order. Stop at the first that fails.
Quick fix for Bolt.new Auth Not Working After Deploy
Layer 1 — Env vars present in production
Open DevTools → Network. Attempt login. If the request to supabase.co never fires, check your production host env. You need VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY set with production values. Not preview values. Redeploy after changing.
Deeper fixes when the quick fix fails
- 02
Layer 2 — Site URL and redirect URLs set
In Supabase → Authentication → URL Configuration:
- Site URL:
https://yourapp.com - Redirect URLs:
https://yourapp.com/**,https://yourapp.com/auth/callback
For Google OAuth: Google Cloud Console → Credentials → add production domain to Authorized redirect URIs. Without this, OAuth sends users to localhost and 404s.
- Site URL:
- 03
Layer 3 — Session cookies persisting across reloads
After a successful login, hard-refresh. If you’re logged out, your session isn’t persisting. Check:
- Supabase client is created with
{ auth: { persistSession: true, autoRefreshToken: true } } - You’re not calling
createClient()in every render — it must be a singleton - Cross-subdomain cookies: set cookie domain to
.yourapp.comif needed
- Supabase client is created with
- 04
Layer 4 — Row-Level Security policies allow authenticated reads
If login succeeds but every query returns
[], you’re authenticated but RLS is blocking reads. In Supabase → Authentication → Policies, for each table add minimum:create policy "Users see own rows" on public.your_table for select using (auth.uid() = user_id);
Warning: don’t fix the empty-data bug by disabling RLS. That’s the vulnerability pattern captured by the widely-reported 2026 Lovable/Supabase RLS disclosure.
- 05
Layer 5 — Token refresh on expiry
Supabase JWTs expire in 1 hour. If your app silently logs out after idle time, the refresh flow is missing. With
autoRefreshToken: true, refresh is automatic — but only if your client is a singleton and the app tab stays open.Add
supabase.auth.onAuthStateChangeto react toTOKEN_REFRESHEDevents. Re-run queries or update the user state when it fires. - 06
Layer 6 — Route protection middleware
Protected routes need a middleware or wrapper that checks
supabase.auth.getUser()before rendering. On the server, this is a Netlify function or Next.js middleware. On the client, a<RequireAuth>wrapper that redirects to/loginwhenuser === null.Test: open an incognito window, paste the protected URL directly. You should land on
/login, not the protected page.
Why AI-built apps hit Bolt.new Auth Not Working After Deploy
Auth is where AI-generated code fails most often because it crosses three boundaries — the browser, your backend, and a third-party identity provider (Supabase, Clerk, Firebase, Google). The AI can see one boundary at a time, never all three together, and Bolt’s sandbox masks misconfigurations that real browsers surface immediately.
Auth is the most concentrated category of AI-generated vulnerabilities we see in practice — our 2026 research roundup collates the Veracode data alongside the credit-spiral and RLS patterns. Getting this right matters both for functionality and for not getting hacked.
“Every time, I just throw my money away.”
Diagnose Bolt.new Auth Not Working After Deploy by failure mode
Open the deployed app in an incognito window. Try to sign up. Watch the Network tab in DevTools. Match the first failed request to the table.
| Symptom | Layer that's broken | Step |
|---|---|---|
| supabase.auth is undefined; 401 on every call | Env vars missing in production | Step 1 |
| Login redirects to localhost:3000 | Site URL wrong | Step 2 |
| Login succeeds, next page reload shows logged out | Cookies/session storage | Step 3 |
| Logged in, but queries return empty arrays | RLS policies missing | Step 4 |
| Random 401s after idle time | Session refresh not implemented | Step 5 |
| Protected routes accessible without login | Middleware missing | Step 6 |
Related errors we fix
Still stuck with Bolt.new Auth Not Working After Deploy?
Auth is where token spirals start. Fixed price, ships in 3 days:
- →You've burned credits trying to fix login
- →Users report being logged out randomly
- →Login works for you but not for users in incognito
- →OAuth is redirecting to localhost
Bolt.new Auth Not Working After Deploy questions
Why does my Bolt.new login work in preview but fail in production?+
How do I fix 'redirect to localhost' after a Bolt.new deploy?+
Why does my Bolt.new app log users out randomly?+
Is Bolt.new auth secure enough to launch?+
How much does it cost to fix broken Bolt.new authentication?+
Can I add email+password login to a Bolt.new Supabase app?+
Ship the fix. Keep the fix.
Emergency Triage restores service in 48 hours. Break the Fix Loop rebuilds CI so this error cannot ship again.
Hyder Shah leads Afterbuild Labs, shipping production rescues for apps built in Lovable, Bolt.new, Cursor, Replit, v0, and Base44. our rescue methodology.
Bolt.new Auth Not Working After Deploy experts
If this problem keeps coming back, you probably need ongoing expertise in the underlying stack.