Bolt.new app can't connect to Supabase? What to check
Why a Bolt.new app fails to reach Supabase: missing URL or key, the wrong key type, RLS blocking reads, a paused project or auth URLs. How to find and fix each.
Leer en español →
A Bolt.new app that can't talk to Supabase almost always has one of five problems: the project URL or key is missing where the app is built, the key is the wrong type or belongs to another project, Row Level Security is blocking the request, the Supabase project is paused, or the auth URLs still point to the preview. The browser's console and Network tab tell you which one in under a minute.
This guide starts with a question many people skip (is the app even using Supabase?), then maps each error message to its cause, walks through the fix and shows how to confirm it.
Is my Bolt project using Supabase or Bolt Database?
Since Bolt Cloud launched, new projects use Bolt Database by default, on every plan. Supabase is an alternative on Pro and Teams plans: you connect your Bolt account to one Supabase organization under Applications in the settings, then connect a Supabase project from the Advanced tab of the database settings.
This matters because the fixes differ. Bolt's own troubleshooting says that if the console shows errors referencing a Supabase URL, the project may expect a Supabase connection that was never set up. Two warnings from the Bolt Supabase guide are worth knowing before you click anything:
- Connecting a Supabase project to a project that already has a Bolt database replaces that connection and can lose data. Claiming the Bolt database into Supabase keeps it.
- Restoring an earlier version in Bolt's version history doesn't touch the database. Code goes back; tables don't.
What does each error mean?
Open the live app, press F12 (or Cmd+Option+J on a Mac), reproduce the problem and look at the Console and Network tabs.
| What you see | Most likely cause |
|---|---|
supabaseUrl is required. | The URL variable was empty when the app was built |
Invalid API key | The key is mistyped, from another project, or was deactivated |
Failed to fetch or a network error | Wrong project URL, a paused project, or a blocked request |
Requests return 200 with an empty array [] | RLS is on and no policy allows that user to read |
new row violates row-level security policy for table "..." | RLS is on and no policy allows the insert |
| Sign-in works in the preview, fails on the live site | Site URL and redirect URLs still point to the old address |
A server function returns 401 when Stripe or another service calls it | JWT verification is on for a function that receives webhooks |
How do I fix it?
1. Check that the URL and key reach the app
A typical Bolt (Vite) project creates the client like this. Your variable names may differ, so search the code for createClient:
import { createClient } from '@supabase/supabase-js';
export const supabase = createClient(
import.meta.env.VITE_SUPABASE_URL,
import.meta.env.VITE_SUPABASE_ANON_KEY
);
VITE_ variables are copied into the JavaScript when the app is built. If you publish somewhere other than Bolt hosting, such as a Netlify site that builds from GitHub, those variables must exist in that host's settings, and you have to rebuild after adding them.
2. Compare the URL with the project you think you're using
In the Supabase dashboard, open the project and copy the project URL from the Connect dialog or the API settings. It looks like https://<project-ref>.supabase.co. People often connect a second, empty Supabase project by mistake, and everything "works" except that the data isn't there.
3. Use the right kind of key
Supabase's API key guide describes two families:
- Publishable key (
sb_publishable_...) or the legacy anon key: safe in the browser, because RLS limits what it can reach. - Secret key (
sb_secret_...) or the legacy service_role key: bypasses RLS and belongs only on a server or in a server function.
Supabase plans to deprecate the legacy anon and service_role keys by the end of 2026. If someone deactivated the legacy keys in the dashboard, an app still using the old anon key starts failing with Invalid API key. Switch it to the publishable key. If you ever find a secret key in front-end code, treat it as leaked and rotate it; our guide on whether the Supabase anon key is safe to expose explains the difference.
4. Read empty results as an RLS question
An empty list with no error isn't a broken connection. It's RLS doing its job with no policy that lets this user read. Check that each table has RLS on and a policy for the operation that fails, for example:
create policy "Users read their own projects"
on public.projects for select
to authenticated
using ((select auth.uid()) = owner_id);
Don't fix it by turning RLS off. That makes the table readable and writable by anyone with your public key. Our Supabase RLS guide for Lovable and Bolt covers the common policies.
5. Wake up a paused project
Supabase pauses inactive projects on the free plan. The dashboard shows the project as paused and offers a restore button; requests fail until it's back. Bolt Database has its own version of this: in unpublished projects, a database with low usage for six days or more may be paused and restored the next time you open the project. See why a free Supabase project gets paused.
6. Update the auth URLs for your real domain
In Supabase, open Authentication > URL Configuration. Set the Site URL to your live domain and add every address users sign in from to the redirect URLs, including the bolt.host address if you still use it. Sign-in emails and OAuth both redirect to these.
7. Check server functions separately
If the browser can read data but a server function fails, look at the function's logs. Bolt's troubleshooting lists three usual causes: a CORS header that doesn't allow your domain, JWT verification blocking a webhook (turn it off for that function and validate the webhook signature instead) and a missing secret, which Bolt reports as Missing secrets. More on the first one in our CORS explainer.
How do I confirm the connection works?
- In the Network tab, find a request to
https://<project-ref>.supabase.co/rest/v1/.... It should return200with rows when you're signed in as a user who owns data. - Sign out and repeat. Private tables should now return nothing.
- Create a record from the app and check it appears in the Supabase table editor (or Bolt's Tables view).
- Run the database Security check in Bolt, or Supabase's Security Advisor, and clear anything marked as an error.
Quick answers
Do I need a Pro plan to use Supabase with Bolt? According to Bolt's documentation, connecting or claiming a Supabase database requires a Pro or Teams plan. Bolt Database is available on every plan.
Why does it work in the Bolt preview but not on my host? The preview has the variables; the external host's build doesn't. Add them there and rebuild.
Can I just paste the service role key to make it work? No. It bypasses every RLS policy, and anything in the browser can be read by anyone.
The data is in Supabase but the app shows nothing. Is it broken? Usually not. It's an RLS policy that doesn't allow the read for that user.
Want someone to check the whole setup?
Connection errors often sit next to permission problems. The free health check looks at what your live app exposes, and our Supabase security review goes table by table through policies and keys. For broader Bolt issues, see Bolt app rescue or contact us.


