Bolt.new + Supabase: 403 Forbidden, data not saving, or the wrong project connected

Bolt.new Moderate 30-60 minutes Last verified Jul 17, 2026

The fix A 403 from Supabase in a Bolt app is almost always Row Level Security: the generated policy does not match how the app actually queries. Compare each policy under Table Editor, Policies against your real queries, make sure the client uses the anon key (never service_role), and add your production domain to Supabase's auth URL Configuration to stop login loops.

Symptoms

The UI reports success but no rows appear in Supabase
The Network tab shows 403 Forbidden on requests to Supabase
Users log in on the production domain and bounce straight back to the login page
Connecting Supabase set up a brand-new project and tables instead of using your existing database

Why it happens

Generated RLS policies do not match the real queries

Bolt-generated Row Level Security policies can work in the preview but not match how the app actually queries in production, for example a policy that scopes rows to the authenticated user while the app selects all rows. Postgres blocks the query with 403.

The service_role key ended up client-side

Generated code sometimes uses the service_role key in the browser, which bypasses RLS during testing and then fails or leaks privileges in production.

Auth redirect URLs only cover the preview domain

Supabase auth redirect URLs configured only for the Bolt preview domain mean the deployed domain is not an allowed redirect target, which causes the login loop.

Bolt attached to the wrong Supabase project

Bolt's integration flow has a known tendency to provision a new Supabase project rather than attach to an existing one, and connections fail when the Bolt database was never claimed in Supabase.

How to fix it

Confirm RLS is the blocker, then fix the policyIn Supabase, open Table Editor, select the table, then Policies, and compare each RLS policy against the queries your app actually runs; a policy scoped to the authenticated user will 403 a query that selects all rows. To confirm, temporarily set an allow-all policy on a test table; if the 403 disappears, RLS is the cause. Revert the test policy, then have Bolt output corrected policy SQL that matches the real queries.
Check which key the client usesVerify that any code shipped to the browser uses the anon key (VITE_SUPABASE_ANON_KEY) and never the service_role key. Service_role in the client bypasses RLS during testing, which hides policy bugs, and then fails or leaks privileges in production.
Fix the login loop in URL ConfigurationIn Supabase, go to Authentication, then URL Configuration, and add the production domain: https://yourdomain.com and https://yourdomain.com/**. Also make the app await full session resolution before checking auth state, or a slow session read bounces users back to login.
Point the app at the right Supabase projectConfirm the app's project URL and anon key belong to the Supabase project you intended, not a new one Bolt provisioned; Bolt's integration flow is known to create a fresh project instead of attaching to an existing one. If the connection is broken, disconnect and reconnect Supabase in Bolt's settings and claim the database in Supabase.
Diagnose from the deployed URLOpen the deployed site in an Incognito window with DevTools open and watch the Fetch/XHR requests. 401 and 403 responses plus a missing sb-access-token cookie pinpoint whether the problem is RLS, keys, or auth configuration.

How to prevent it

Review every RLS policy Bolt generates against the actual queries before deploying.
Never let the service_role key into client code; anon key only in the browser.
Add the production domain to Supabase URL Configuration as part of the deploy checklist, not after the first login loop.
After connecting Supabase, confirm the project URL matches the project you meant to attach.
Smoke-test the deployed URL in Incognito with DevTools open before announcing the app.

Tools that actually fix this

Recommended because they address the failure mode above, not because of the payout. Some are affiliate links; see how we choose.

SupabaseFree tier incl. RLS

If your AI-built app uses Supabase, Row Level Security is the actual fix for exposed data, and it is free. The dashboard's Security Advisor lists every table you left open.

Try Supabase →

Clerkfree tier

Drop-in authentication that handles sessions, tokens, and protected routes properly, so you stop shipping the hand-rolled auth an AI guessed at. Generous free tier for a real app.

Try Clerk →

Frequently asked questions

Why does my Bolt app show success but save nothing to Supabase?

Because the write is being blocked by a Row Level Security policy and the generated UI never surfaces the 403. Bolt-generated RLS policies can pass in the preview but not match how the app actually queries in production, so Postgres rejects the insert. Check the Network tab for 403 Forbidden responses and compare each policy under Table Editor, Policies against the real queries.

Why do users get bounced back to the login page on my deployed Bolt app?

The Supabase auth redirect URLs were configured only for the Bolt preview domain, so the deployed domain is not an allowed redirect target and login loops back. Add https://yourdomain.com and https://yourdomain.com/** under Supabase Authentication, URL Configuration, and make the app await full session resolution before checking auth state.

Why did Bolt create a new Supabase project instead of using mine?

Bolt's Supabase integration flow has a known tendency to provision a brand-new project and tables rather than attach to your existing database, and connections also fail when the Bolt database was never claimed in Supabase. Verify the project URL and anon key in your app match the project you intended, then disconnect and reconnect Supabase in Bolt's settings and claim the database.

Is it a problem if Bolt used the service_role key in my app?

Yes. If the service_role key ships to the browser it bypasses Row Level Security entirely, which hides policy bugs during testing and leaks privileges to anyone reading your client code in production. Client-side code should only ever use the anon key (VITE_SUPABASE_ANON_KEY); anything that genuinely needs service_role belongs on the server.

Sources

The Vibe Oops briefing

One email when something ships to production that should not have. New incidents, new error guides, no filler.