Frequently asked questions

Not to your database, ever. Checks work from your GitHub repo only. The lab rebuilds a copy of your database structure from supabase/migrations in a disposable local Postgres, fills it with fake rows, and tests that. We never use your Supabase URL, your keys or your users’ data. If you turn on Live posture for an app, PatchLabs loads its public home page once a day, like any visitor, but only on a domain you have verified, and only to grade HTTPS, the certificate, security headers and cookie flags.

A public GitHub repo, read like any visitor would read it. No GitHub sign-in, no app install, no tokens, no Supabase credentials. You prove you own the repo by committing one small file. Why we ask.

Not yet. Private repos need our GitHub App, which is coming. Until then, email the founder if you need one checked.

Anyone you give the link to. Check IDs are long random identifiers that can’t be guessed, and we only email the link to the address that requested it. The report never contains your users’ data, because we never see it. Workspace members see reports for their apps in the dashboard.

No. A check tests who can read which rows in a database rebuilt from your migrations, and scans your code and git history for exposed keys. It doesn’t attack your live app, test your login flow or look for every kind of vulnerability. We say so on every report.

No. PatchLabs doesn’t train models. Our agents use Claude models to write and test fixes during your check. See security for what we keep and for how long.

In our lab study the median was 3.5 minutes per app (n=20, 9 Nov 2026). Allow 5 to 15 minutes in practice, including time in the queue. Your check page updates by itself and we email you when it’s done.

In an autonomous run on 20 new apps, 18 fixes passed the strict lab proof with no human involved, and 15 of those needed only the smallest model (n=20, 9 Nov 2026). The other 2 went to a person. In an earlier study, 19 of 20 real fixes, re-verified by us, worked first time and applied cleanly (5 Nov 2026). A fix that doesn’t pass the proof is never labelled proven. Methodology.

That in the lab, after the fix, an anonymous visitor with your public key was denied, a signed-in stranger was denied, and the owner could still read their own rows. All three, on the database rebuilt from your migrations plus the fix. It is proof about the access rules we test, not a guarantee about the whole app.

The proof checks the owner can still read their own data, which catches the most common way a fix breaks things. Each report also rates the risk of a visible change and names any code change needed. We don’t test every query your app makes, so your engineer reviews the fix before it ships. Applying a fix.

We sampled 436 public Lovable and Supabase repos; in 318 the migrations built a working database. 106 of those 318 (33%) let the wrong people read personal data: 70 (22%) to anyone with the public key and 36 (11%) to anyone who signs up. After removing businesses’ own public contact details, about 1 in 4 (25 to 28%). PatchLabs lab study, Nov 2026. The full study.

It means none of the tables we tested let the wrong people read personal data on that date. It can’t see policies made by hand in the Supabase dashboard that aren’t in your migrations, and it covers read access, not everything. Keep monitoring on so a later change gets caught.

Apps whose database is Supabase (Postgres) with migrations in supabase/migrations, whether built with Lovable, Bolt, Replit, Cursor or by hand. Other databases, such as Firebase, aren’t supported. PatchLabs is independent and not affiliated with any of these platforms.

Then the lab has nothing to rebuild from. If your schema lives only in your hosted Supabase project, the Supabase CLI can write it out as a migration file:

supabase link --project-ref <your-project-ref>
supabase db pull

Commit the generated file and request the check again. Check Supabase’s docs if the command asks for anything unexpected.

Not yet; that needs our GitHub App, which is coming. Today each fix comes as a downloadable migration and a one-click link that opens GitHub with the file filled in, ready to commit or turn into a pull request.

Exposed AI, payment and database keys in your code and its full git history. A key you deleted in a later commit is still readable by anyone who clones the repo, so we look there too. If we find one, rotate it at the provider first.

Claude models, starting with the smallest and moving up only if the lab proof fails, with a spend cap on every check. Model costs are ours, not yours: the median was $0.46 per app in our study (n=20, 9 Nov 2026), and your price is your plan.

Free covers one app, re-checked monthly, with 4 manual runs a month. Maker is £19 a month (3 apps, weekly checks), Agency £99 a month (10 apps, +£8 per extra app), and Enterprise is custom. Card payments aren’t live yet: request access and we reply within a day. Pricing.

Not for a free check: just a repo and an email. Sign in (a magic link, no password) to monitor apps, invite your team, use API keys and webhooks, and record decisions.

In Settings, or with GET /me/export and DELETE /me. Export gives you everything we hold about you as JSON. Deleting removes your account and your free checks, and any workspace you own alone. Details.

No. PatchLabs is independent and not affiliated with Lovable, Supabase, Bolt, Replit or Cursor. It’s built by Manraj Singh Dhillon, a technical founder in London.

Thank you. Email manraj@patchlabs.dev with the subject “Security”. See our security page and disclosure policy.