---
title: "Bolt apps, secrets, and Supabase access"
slug: bolt-rls-keys-and-auth
severity: critical
category: Secrets
summary: "Vite documents that VITE_ values are bundled into the client, and Vercel's Bolt export guide says the Secrets panel values are not in the zip you deploy."
platforms:
  - Supabase
  - Vercel
updated: "2026-10-14"
related:
  - secret-keys-in-the-frontend
  - supabase-tables-without-rls
  - auth-checked-only-in-the-ui
---

Bolt's own product docs were not the source for this page. Two vendor pages describe the stack a Bolt app often ships with. Vite's env guide says variables prefixed with `VITE_` are exposed in client source after bundling, and that those variables should not contain API keys. Vercel's guide to deploying a Bolt project says Bolt does not include Secrets panel values in the exported zip, so API keys are missing until you recreate them as Vercel environment variables.

If the app talks to Supabase, Supabase's securing-data guide still applies: the publishable key may be in the client only with row level security and grants, and a secret key bypasses RLS. This page does not claim a count of Bolt apps that ship with RLS off. That number was not on the pages above.

## How to check in 5 minutes

1. Search the Bolt project for `VITE_` and open the built JavaScript if you have a production build. Vite's guide says a `VITE_` value is in the client bundle and a variable without that prefix is not.
2. If you exported a zip for Vercel, open the Vercel project's environment variables. Vercel's Bolt guide says Secrets panel values are not in the export. A missing key fails closed. A key you pasted into a `VITE_` name fails open.
3. If the app uses Supabase, open the table's RLS flag in the Supabase dashboard. Confirm a signed-out request with the publishable key does not return another user's row.

## How to fix

### Bolt

Remove the `VITE_` prefix from any value that is a secret, and stop reading it from `import.meta.env` in client code. Call the third party from a server or edge function. Keep the Supabase publishable key as the client key only after RLS is on.

### Vercel

Recreate Bolt secrets as Vercel environment variables, using the Secret type for credentials. Vercel's env docs say Secret values are write-only after saving, and Config values stay readable. Redeploy. An old deployment keeps the previous values.

### Supabase

Enable RLS and policies for the roles the client uses. Do not put the secret key in a `VITE_` variable. Supabase says that key bypasses RLS.

## Agent prompt

```text
You are fixing secret exposure in a Bolt project that uses Vite. Do not add features.

1. List every VITE_ variable. Any secret in that list moves to a server-side env var and out of client code.
2. If the app uses Supabase, enable RLS and show the policy. Do not put the secret key in the client.
3. Do not invent a statistic about Bolt apps. Show the files you changed.
```

## FAQ

### Does the Vercel export include Bolt secrets?

No. Vercel's Bolt deployment guide says the Secrets panel values are not in the zip, and that you recreate them as Vercel environment variables before features that call external services will work.

### Does Vite hide a VITE_ key?

No. Vite's env guide says the prefix exists to expose values to client code, and that API keys should not use it.

## Sources

- [Env variables and modes](https://vite.dev/guide/env-and-mode)
- [Deploy a Bolt.new app with Vercel Drop](https://vercel.com/kb/guide/bolt-vercel-drop)
- [Environment variables](https://vercel.com/docs/environment-variables)
- [Securing your data](https://supabase.com/docs/guides/database/secure-data)