Docs

PatchLabs documentation

Find out who can read your app’s data, get a fix that has already been proven in a lab, and keep it that way. Start with the quickstart below, or jump straight to the part you need.

What a check does

A check works from your GitHub repo only. It rebuilds your database from the files in supabase/migrations inside a disposable local Postgres that copies Supabase’s roles, auth functions and default grants. It seeds fake rows, then asks three questions as three different people:

  • An anonymous visitor, using your public anon key (it ships inside your frontend, so anyone has it).
  • A signed-in stranger: a brand-new account that owns nothing.
  • The owner: a user who should see their own rows and nothing else.

If a stranger can read personal data, an agent writes a fix (a SQL migration, plus any code change it notes) and the lab tests it again: the anonymous visitor must be denied, the stranger must be denied, and the owner must still read their own rows. Only a fix that passes all three is called proven. The same run scans your code and its full git history for exposed AI, payment and database keys.

lab run · manra399/patchlabs-demo-app
[REBUILD] 1 migration → lab Postgres  OK
[SEED]    2 test users, fake rows     OK
[PROBE]   anon     → 2 rows           LEAK
          stranger → 2 rows           LEAK
[FIX]     owner-only SELECT policy
[PROVE]   anon     → 0 rows         DENIED
          stranger → 0 rows         DENIED
          owner    → 1 row              OK
[DONE]    lab proof passed · 36 s
provenReal run on our own demo app, 9 Nov 2026

A check never connects to your live app or your live database. Your engineer approves every change before it ships. (Optional Live posture only loads your public home page, like any visitor, on a domain you verify.)

Before you start

  • A public GitHub repo for the app. Private repos need our GitHub App, which is coming; until then, email the founder.
  • Supabase migrations in supabase/migrations/*.sql. Apps built with Lovable, Bolt, Replit or Cursor on Supabase usually have them. If yours doesn’t, see the FAQ.
  • Permission to commit one file to the repo’s default branch, so you can prove it’s yours.
  • An email address for the report link. No account or password needed.

Quickstart

  1. Paste your repo and email

    Use the form below, or the one on the home page. You’ll land on your check’s own page.

    Free for your first appReads your public repo only
  2. Prove the repo is yours

    Commit a file named patchlabs-verify.txt containing the one-time code shown on your check page. The “Add the file on GitHub” button opens GitHub with the name and code filled in, so you only press “Commit changes”. Then press “I’ve added it”. More on verification.

    patchlabs-verify.txt
    patchlabs-3f9a1c0b7d2e4a65
  3. Let the lab run

    Your check page updates by itself and we email you when the report is ready. In our lab study the median run took 3.5 minutes per app (n=20, 9 Nov 2026); allow 5 to 15 minutes including the queue.

  4. Read the report

    You’ll see one of three results: fix proven, in review (a person checks the fix first) or no leaks found. The report names each leaking table, who could read it, and the before-and-after proof. How to read a report.

  5. Apply the fix

    Press “Commit the fix on GitHub” to add the migration to supabase/migrations/, or download the .sql file. Your engineer reviews it and ships it like any other migration. Steps for Supabase, Lovable, Bolt, Replit and Cursor.

  6. Keep it checked

    Sign in with the same email (a magic link, no password) and add the repo as an app. It gets re-checked on a schedule, and your team hears about any new leak. Set up monitoring.

Want an answer in seconds first?

The free RLS check reads your migrations and flags risky row-level-security patterns straight away, with no sign-up and no verification. It is static analysis: it reads the SQL, it doesn’t run it. The full check above is the one that rebuilds the database and proves who can actually read what.

Terminal
curl -s https://api.patchlabs.dev/tools/rls-check \
  -H 'Content-Type: application/json' \
  -d '{"repo": "manra399/patchlabs-demo-app"}'

What a check covers, and what it doesn’t

A check covers who can read which rows in the public schema of a database rebuilt from your migrations, plus exposed keys in your code and git history. It can’t see changes made by hand in the Supabase dashboard that never made it into a migration, it doesn’t test your live app, and it isn’t a penetration test. A clean result means our checks found nothing on that date, not that the app is secure in every way.

Where to go next

Updated 10 Nov 2026Something unclear or wrong? Tell the founder