Bolt.new app throws "TypeError: Failed to fetch" on every Supabase call

You built an app in Bolt.new with Supabase behind it. Now login fails, data never loads, and the console shows TypeError: Failed to fetch. Sometimes it worked in the Bolt preview and broke the moment you deployed to Netlify. This error looks scary but it only has five real causes, and you can identify yours in about two minutes with devtools open.

What "Failed to fetch" actually means

The browser tried to make a network request and never got a usable response back. Not a 404, not a 500, nothing. That happens for exactly four reasons: the URL is wrong or unreachable, there is no network path to it, the browser blocked the response (CORS), or the request never really left because your Supabase client was created with an undefined URL or key. The error message is the same in all four cases, which is why pasting it back into the Bolt chat rarely fixes it. You have to look at the request itself.

Diagnose it first: read the actual request

1. Open your app, press F12 for devtools, and click the Network tab.
2. Reload the page or retry the login, and find the failing request. It should go to something like https://yourproject.supabase.co/auth/v1/token or rest/v1/your_table.
3. Read the full URL and the status column. This tells you which class you are in:

• URL contains the literal word "undefined" (like https://undefined/auth/v1/token): missing env vars. Cause 1 or 2 below.
• URL looks right but status shows "(failed)" with no number: the request never reached a server. Paused or deleted project, a typo in the URL, or an extension blocked it. Causes 3 and 5.
• Status is 401 or 403: the request arrived fine. That is a key or permissions problem, not a fetch problem. Check the anon key and your RLS policies (separate guide here).

Cause 1: the Supabase env vars are missing or undefined

Bolt apps use Vite, and the Supabase client is created from two environment variables: VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY. If either is missing, createClient receives undefined and every single call fails with "Failed to fetch". Nothing warns you at build time.

Check: the Network tab trick above is definitive. You can also add console.log(import.meta.env.VITE_SUPABASE_URL) near the top of your app and look at the console. If it prints undefined, this is your problem.

Fix: in Bolt, open the project settings and confirm both variables are set (if you connected Supabase through Bolt's integration it usually writes them for you, but a fork or a fresh import can lose them). On Netlify, go to Site configuration, then Environment variables, and add both. The values come from your Supabase dashboard under Project Settings, then API: the Project URL and the anon public key. The names must start with VITE_ exactly, or Vite refuses to expose them to the browser.

Cause 2: env vars are set, but you deployed before adding them

This is the one that catches almost everyone who says "it works in Bolt but not on Netlify". Vite bakes environment variables into the JavaScript bundle at build time. If your site was built before you added the variables, the deployed bundle still has undefined baked in, and adding the variables afterward changes nothing until you rebuild.

Check: the variables exist in Netlify, yet the Network tab still shows "undefined" in the request URL.

Fix: in Netlify, go to Deploys, click "Trigger deploy", and pick "Clear cache and deploy site". Clearing the cache matters, a plain redeploy can reuse the old build. Wait for the deploy to finish, then hard-refresh your site (Cmd+Shift+R or Ctrl+Shift+R).

Cause 3: the Supabase project is paused (or the URL is wrong)

Free-tier Supabase projects pause automatically after about a week of inactivity. When a project is paused, its URL stops answering entirely, and every request from your app fails with "Failed to fetch". If you built something two weeks ago and it "just stopped working", start here.

Check: open the Supabase dashboard. If the project shows a Paused badge, that is the whole problem. Also compare the URL in your env vars character by character against the Project URL in the dashboard; one wrong letter in yourproject.supabase.co produces the identical error.

Fix: click Restore project in the dashboard and wait a minute or two for it to come back up. No code changes needed. If you expect the app to sit idle for weeks at a time, know that this will happen again on the free tier.

Cause 4: your deployed domain is not in Supabase's auth URLs

This one breaks login flows specifically while plain data reads may still work. Supabase Auth only completes sign-ins and redirects for domains it has been told about. Your Bolt preview URL may be configured while your real Netlify domain is not.

Check: login fails on the deployed site but works in the Bolt preview, or the failure only happens during sign-in, email confirmation, or OAuth redirects.

Fix: in the Supabase dashboard go to Authentication, then URL Configuration. Set the Site URL to your deployed domain (like https://yourapp.netlify.app) and add it to the Redirect URLs list as well. Save, then try the login again in a fresh tab.

Cause 5: an ad blocker or privacy extension is eating the request

Some blockers and privacy extensions (and a few VPNs and corporate firewalls) block requests to supabase.co or to anything that looks like tracking. The request dies in the browser before it leaves, and you get "Failed to fetch" while the exact same app works fine on your phone or a friend's laptop.

Check: open the site in an incognito/private window with extensions disabled. If it works there, an extension is the culprit.

Fix: allowlist your site and supabase.co in the extension, or accept that a small slice of users with aggressive blockers will hit this. There is no code change that fully prevents it.

If you fixed the env vars and it still fails

Go back to the Network tab. The failing request always tells the truth: a URL with "undefined" means the build still does not have the variables (redeploy again, clear cache), a real URL with no status means the project is unreachable (paused, typo, or blocked), and any 4xx status means the fetch part is solved and you are now debugging keys or Row Level Security instead.

Still stuck?