Bolt.new environment variables not working after deploy
Bolt.new does not carry its environment variables to Netlify, so a deployed app often runs without its Supabase URL, API keys or other settings. Add each variable in the host's settings, use the VITE_ prefix for anything the browser needs, and trigger a fresh deploy, because Vite writes the values into the files at build time. If calls still fail, the API is probably rejecting your live domain as an origin.
What you'll see
Everything that touches a database or API works in the Bolt preview and fails on the live site. You see "Failed to fetch", "Invalid API key", CORS errors in the console, or lists that are simply empty. Static pages are fine, which makes it look like a data problem rather than a deploy problem.
Why it happens
1. The variables only exist inside Bolt
Bolt's .env file or settings are not copied to Netlify. The deployed build therefore has undefined values wherever the code reads import.meta.env.
2. The wrong prefix
Vite only exposes variables whose names start with VITE_ to browser code; Next.js uses NEXT_PUBLIC_. A variable named SUPABASE_URL is quietly left out of the bundle.
3. Added, but not rebuilt
Values are inserted when the site is built. Saving them in the host's dashboard has no effect on a deploy that already exists.
4. The live domain is not an allowed origin
Some APIs, and Supabase auth redirects, only accept requests from origins you list. The preview address was allowed; the new domain was never added.
How to fix it
- List every variable the app reads: search the code for import.meta.env and process.env, and compare against the .env file in Bolt.
- In Netlify open Site configuration > Environment variables and add each key with its value, or run netlify env:set KEY value from the CLI.
- Rename any variable the browser needs so it starts with VITE_, and update the code to match. Keep secrets that must stay private, such as service keys, out of the frontend entirely and move that logic to a server function.
- Trigger a new deploy (Deploys > Trigger deploy > Clear cache and deploy site) so the build picks up the values.
- Add your live domain to the API's allowed origins, and to Supabase's Redirect URLs if sign-in is involved.
- Reload the live site with DevTools > Network open and check each API call returns a 2xx status.
Prompt to paste into Bolt.new
List every environment variable this app needs in production, say which are safe for the browser (VITE_ prefix) and which must stay server-only, and make the app show a clear error banner if a required variable is missing instead of failing silently.
How to check it's fixed
- On the live site, DevTools > Network should show API calls returning 200 with no CORS errors in the console.
- Open DevTools > Sources and search the loaded JavaScript for "service_role" or "sk_" to make sure no secret key was exposed while fixing this.
What a QAlaunch scan shows for this
- Failed network requests and CORS errors in the console on the live page.
- Empty lists or sections where data should appear, visible in the screenshots.
- The scan cannot read your host's variables; it reports the visitor-side failure they cause.
See exactly what a full report contains in the sample report.
Frequently asked questions
Is it safe to put a VITE_ variable in the browser?
Only for values designed to be public, like a Supabase anon key protected by Row Level Security or a publishable Stripe key. Anything prefixed VITE_ can be read by every visitor, so secret keys must live in a server function.
Why do I need to redeploy after adding variables?
Vite replaces each import.meta.env reference with the actual value when it builds. The existing deploy was built without them, so only a new build includes them.
Does this apply if I publish on Bolt Cloud instead of Netlify?
Bolt Cloud keeps secrets in the project's database settings, which the app reads on Bolt's own hosting. This guide is for moving the app to Netlify or another host, where you set the variables yourself.
Rather have a QA engineer test it by hand?
If this is a site you're launching or handing to a client, I'll go through it by hand, including the Bolt.new-specific issues a scan can't reach, like logged-in flows.
- Up to 10 key pages tested by hand, not a scan
- Every flow a customer uses: forms, sign-up, checkout, booking
- Real mobile and desktop browsers
- A written report in plain language, with screenshots
- A 15-minute call to walk you through it
- 10 years of professional QA experience
Tell me about your site and I'll reply personally, usually the same day.
No payment now. I'll confirm scope and price first.
Related fixes
- Bolt.new blank page after deploy: causes and fixes
- Bolt.new Google sign-in not working: causes and fixes
- Bolt.new site shows 404 on refresh: the Netlify fix
- Bolt.new custom domain not connecting: causes and fixes
- Bolt.new emails not sending: contact forms and auth emails
- Bolt.new site stopped working: hosting limits and other causes
More for Bolt.new: all Bolt.new fixes · Bolt.new testing · 9 bugs every AI-built site ships with
Written by Waqas Ahmad, QA engineer with 10 years of professional testing experience. Last checked October 26, 2026.
Sources: Netlify: deploy your Bolt app to Netlify · KrishaWeb: fixing a Bolt app