Guides / Bolt.new security checklist before launch

last checked oct 2026

Bolt.new security checklist before launch

Bolt gets you from prompt to deployed app fast. These are the checks that stop that speed from turning into a public database.

1. Open the database Security Audit

In your Bolt project, click the database icon at the top center of the screen, then Security. The page is titled Security Audit and uses the same checks as Supabase's Security Advisor. It is on every plan.

Note what it covers: only your database, not your code. Results are labeled Error, Warning or Info, most serious first. If you can edit the project, an Ask Bolt to fix button appears. Re-open the page after every database change.

2. Take "RLS Policy Always True" seriously

Bolt's docs say that if you have not added sign-in, Bolt may write policies that let any visitor view, add, change and delete data. That is what this warning flags. For each table, decide which bucket it belongs in:

• Public read only: menus, blog posts, portfolio items. Visitors can read, not write.
• Public submit only: contact forms, waitlists, reviews. Visitors can insert, but cannot read anyone else's submission.
• Private: orders, messages, account data. Requires sign-in plus owner-only policies.

Bolt's docs suggest prompting it directly, for example:

Update the policies for my database so visitors can only view the posts table, and can only add rows to the contact_messages table.

Then verify the result instead of trusting it. If your database is in Supabase, run this in the SQL Editor:

-- 1. Which public tables have RLS off?
select tablename, rowsecurity
from pg_tables
where schemaname = 'public'
order by rowsecurity, tablename;

-- 2. What do the policies actually allow?
select tablename, policyname, roles, cmd, qual, with_check
from pg_policies
where schemaname = 'public'
order by tablename, cmd;

On a "public submit" table, you should see an INSERT policy for anon and no SELECT policy for anon.

3. Check every table you added yourself

Bolt turns on RLS for tables it creates. Tables you add another way (SQL, a migration, the Supabase table editor) need it turned on by you:

alter table public.your_table enable row level security;

With RLS on and no policies, the API returns nothing to publishable-key clients, which is the safe default until you add the policies you need.

4. Audit your VITE_ variables

Many Bolt projects are Vite apps (look for a vite.config file). Vite's docs: any variable prefixed VITE_ is bundled into client code at build time and is public. Open your .env and check every VITE_ line:

• VITE_SUPABASE_URL and a publishable/anon key: expected.
• Anything like VITE_OPENAI_API_KEY, VITE_STRIPE_SECRET_KEY or a Supabase secret/service_role key: it is already public in your deployed JS. Move the call to a server-side function and rotate the key (how).

5. Leaked password protection

If the Security Audit shows Leaked Password Protection Disabled, the Prevent Leaked Passwords setting is off. Bolt notes it is on by default for Bolt databases; on a Supabase free plan it is not available.

Pre-launch checklist

• Security Audit: no Errors, every Warning understood
• No "Always True" policy on private data
• RLS on for tables you added yourself
• No secret in any VITE_ variable
• Private data behind sign-in

Sources

Every product step above was checked against these official pages. Last checked Oct 2026. Products change; if a menu moved, the docs below are the source of truth.

• Bolt: Database security settings
• Vite: Env variables and modes
• Supabase: Row Level Security
• PostgreSQL: pg_tables view
• PostgreSQL: pg_policies view
• Supabase: API keys