"supabaseUrl is required" or "Invalid API key"
The deployed build doesn't have your Supabase URL or key. Bolt projects use Vite, which reads VITE_ variables at build time. Add VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY (or whatever names your code uses) in your host's environment settings, then trigger a fresh build.
Copy the values again from your Supabase project's API settings. A trailing space or a key from a different project gives the same error.
"Failed to fetch" or requests time out
Supabase may pause Free Plan projects that show low activity over a 7-day period. Open the Supabase dashboard. If the project is paused, restore it. Also check the URL in your env variables matches the project you expect.
Not sure which of these it is? We'll tell you in 24 hours, free.
Get a free health check"relation does not exist"
Postgres is telling you the table isn't there. Bolt writes SQL migration files for your schema, but if one didn't run against your project, the table was never created. Open the SQL editor in Supabase, check which tables exist, and run the missing migration.
Saves fail or lists come back empty
That pattern points at Row Level Security. With RLS on and no matching policy, inserts fail and reads return nothing. Our guide to RLS errors walks through the policies you need.
Questions people ask
Why do my Supabase env variables work in Bolt but not after deploying?
The preview inside Bolt has its own copy of the variables. Your host builds the app separately, so the same VITE_ variables must be added in the host's settings, followed by a new build.
Should I put my Supabase service role key in a VITE_ variable?
No. Anything prefixed with VITE_ ends up in the browser. The service role or secret key bypasses all security rules and must stay on a server or in an Edge Function.