afterbuild/ops
ERR-810/stack trace
ERR-810
Bolt.new Auth Not Working After Deploy? The Auth Recovery Playbook (2026)

Bolt.new Auth Not Working After Deploy? The Auth Recovery Playbook (2026)

Last updated 15 April 2026 · 10 min read · By Hyder Shah
Direct answer

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

Start here

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

  1. 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.

  2. 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.com if needed
  3. 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.

  4. 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.onAuthStateChange to react to TOKEN_REFRESHED events. Re-run queries or update the user state when it fires.

  5. 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 /login when user === 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.
Bolt.new user, Trustpilot

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.

SymptomLayer that's brokenStep
supabase.auth is undefined; 401 on every callEnv vars missing in productionStep 1
Login redirects to localhost:3000Site URL wrongStep 2
Login succeeds, next page reload shows logged outCookies/session storageStep 3
Logged in, but queries return empty arraysRLS policies missingStep 4
Random 401s after idle timeSession refresh not implementedStep 5
Protected routes accessible without loginMiddleware missingStep 6

Related errors we fix

Still stuck with Bolt.new Auth Not Working After Deploy?

Emergency triage · $299 · 48h turnaround
We restore service and write the root-cause report.

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
start the triage →

Bolt.new Auth Not Working After Deploy questions

Why does my Bolt.new login work in preview but fail in production?+
Bolt's WebContainer auto-wires Supabase credentials and auth callbacks. Production does not. Six layers can fail silently: env vars, Site URL, cookies, RLS, session refresh, and middleware. Debug each in order by opening DevTools and watching the Network tab during a login attempt — the first failed request tells you which layer is broken.
How do I fix 'redirect to localhost' after a Bolt.new deploy?+
Three surfaces still say localhost: Supabase Authentication → URL Configuration (Site URL + Redirect URLs), Google Cloud Console (Authorized redirect URIs on your OAuth client), and any hardcoded redirectTo in your app code. Update all three to your production domain, redeploy, and test in an incognito window to bypass cached OAuth state.
Why does my Bolt.new app log users out randomly?+
Supabase JWTs expire in 1 hour. If you create the Supabase client inside a React component, you spawn a new instance per render and break autoRefreshToken. Fix: create the client once in a module singleton, use autoRefreshToken: true and persistSession: true, and listen for TOKEN_REFRESHED via onAuthStateChange.
Is Bolt.new auth secure enough to launch?+
Only if RLS is enabled on every table, service role keys are never exposed client-side, and protected routes have middleware. Auth is the top category of AI-generated vulnerabilities — our 2026 vibe-coding research summarizes the industry data. Run a 48-hour security audit before taking payments — the cost of a breach is always higher than the cost of a review.
How much does it cost to fix broken Bolt.new authentication?+
Fixed-price Integration Fix for auth is $799 with a 3-day turnaround and covers all six layers, OAuth, RLS policies, and session handling. Emergency Triage is $299 if you just need the single broken layer found and fixed. Upwork freelancers charge $50-$150/hour with typical 5-15 hour estimates depending on how many layers are broken.
Can I add email+password login to a Bolt.new Supabase app?+
Yes. Supabase supports it out of the box via signUp and signInWithPassword. Bolt scaffolds often skip email confirmation; enable it in Supabase Authentication → Providers → Email → Confirm email. Also configure the email template to use your production domain in the confirmation link — the template defaults to localhost if Site URL isn't set.
Next step

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.

About the author

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.

Sources