Try the demo Check my app free

For Bolt apps

Built with Bolt and Supabase? Check who can read its data.

If your Bolt project uses Supabase and its migrations are in a public GitHub repo, we can rebuild the database in a lab, read it as a stranger, and hand you a proven fix.

Free for your first appReads your public repo onlySee a sample report

Independent: PatchLabs is not affiliated with Bolt.

your-bolt-app/
├─ src/
├─ package.json
└─ supabase/
   └─ migrations/    ← what we need
      └─ …_create_tables.sql
What we look for. If there’s no supabase/migrations folder in the repo, we can’t rebuild the database yet.

Will it work?

Check this before you paste your repo.

Works today when

  • The project uses Supabase
  • Its migrations are in supabase/migrations in a public GitHub repo
  • Personal data lives in database tables protected by RLS

Not covered yet

  • Projects whose database changes aren’t in the repo as migration files
  • Private repos, until our GitHub App ships
  • Non-Supabase databases

The common leak

The same Supabase rules, the same ways to leak.

A Bolt app on Supabase is protected by the same row level security as any other. The usual leaks: a table with RLS switched off, a read policy that is always true, or one that lets any signed-in user read every row.

No Bolt-specific numbers yet. Our study sampled public Lovable and Supabase repos, so we don’t publish figures for Bolt apps. The access rules work the same way on any Supabase database, which is what we test.

RLS never enabled: readable through the API
-- before: RLS was never switched on for this table
-- (with Supabase's default grants, anyone with the key can read it)

-- after: RLS on, owners read their own rows
alter table public.customers enable row level security;
create policy "Owners read own customer records"
  on public.customers for select to authenticated
  using (auth.uid() = owner_id);

Illustrative SQL. Your report contains the real migration for your tables, and it only counts as proven once the anonymous visitor and the signed-in stranger are denied and the owner still reads their own rows.

How the fix lands

From proven fix to your live app.

How a new migration file reaches your database depends on how your Bolt project is connected to Supabase. We haven’t verified Bolt’s behaviour for every setup, so check your platform’s docs.

We never push to your repo or touch your database. Nothing changes until you, or your engineer, applies the migration. Automatic pull requests need our GitHub App, which is coming.

  1. Get the fix

    Download the migration from your report, or commit it on GitHub in one click.

  2. Apply it to your Supabase database

    Paste the SQL into your Supabase project’s SQL editor, use supabase db push if you work with the Supabase CLI, or ask Bolt to apply the migration. Check your platform’s docs for which applies to you.

  3. Keep the file in the repo

    So the next change Bolt makes builds on the fixed rules.

  4. Re-check

    Run the check again to confirm the leak is closed.

Questions

Bolt questions.

Something else? Email the founder.

Lovable appsSupabase appsReplit appsCursor apps
My Bolt project doesn’t have a supabase/migrations folder.

Then we can’t rebuild the database yet. The key scan still runs on your code and history. Tell us how your project is set up and we’ll see what we can do.

Do you need access to my Bolt account?

No. Checks only read the public GitHub repo and never connect to your live app or database.

Will the fix break my app?

A fix only passes if the owner can still read their own rows. The report also includes a risk note about anything that could behave differently.

Is PatchLabs part of Bolt?

No. PatchLabs is independent and not affiliated with Bolt or StackBlitz.

Free check

Can a stranger read your users table? Find out in minutes.

You’ll get the leaks, the fix and the proof on one page. How it works.

Check my app freeSee a sample report