Apply

Applying a fix

A fix arrives as one SQL migration file, plus any code change the report lists. Your engineer reviews it and ships it the way they ship any other migration. Nothing reaches your live app until they do.

Before you apply

• Read the risk line. The report rates how likely the fix is to change something your users notice, and why.
• Check for code changes. If the report says a page or query needs to change too, plan to ship both together.
• Read the SQL. It is a normal migration, usually a few lines that drop an over-broad policy and create a narrower one. Nothing in it is hidden or generated at apply time.
• Apply it as written. The proof covers the exact file we tested. If you edit it, the lab result no longer applies to your version (and its hash won’t match the receipt).

Get the file

A finished report with a proven fix offers three ways to take it:

Commit the fix on GitHub

Opens GitHub’s new-file page with supabase/migrations/<timestamp>_patchlabs_leak_fix.sql and the SQL filled in. Review it, then commit to a new branch and open a pull request, or commit straight to your default branch. Shown when the fix is short enough to fit in a GitHub link (under about 7,000 characters).

Download the fix (.sql)

Saves the same file with the same name. Always available.

Copy fix

Copies the SQL, for pasting into an SQL editor or your builder’s chat.

Apply it on your platform

• Supabase CLI
• Supabase SQL editor
• Lovable
• Bolt
• Replit
• Cursor or any local repo

Builders change how they handle databases often. Where we say “check your platform’s docs”, we mean it: the steps below are the general shape, not an official guide from any of these companies.

Supabase CLI

The most reliable route, and the one the fix is designed for. With the file in supabase/migrations/:

# optional: replay every migration on a local database first
supabase start
supabase db reset

# link once, preview, then apply to your hosted project
supabase link --project-ref <your-project-ref>
supabase db push --dry-run
supabase db push

supabase db push applies migrations that the hosted database hasn’t run yet, in filename order. The fix’s timestamp puts it last.

Supabase SQL editor

If you don’t use the CLI, paste the SQL into the SQL editor in your Supabase dashboard and run it. Then keep your repo in step, so a later db push doesn’t try to run it twice:

# commit the file to supabase/migrations/, then mark it as already applied
supabase migration repair --status applied <timestamp-from-the-file-name>

Lovable

Lovable keeps your project in sync with its GitHub repo, so committing the fix through the GitHub link adds the file to your project. Whether that file is then run against your database automatically depends on how your project’s database is connected, so check Lovable’s docs. Two routes that work either way:

• Paste the SQL into Lovable’s chat and ask it to apply it as a database migration exactly as written. Review what it proposes before you approve it, and make sure it hasn’t rewritten the SQL.
• If your project uses your own Supabase project, run the SQL in the Supabase SQL editor.

Bolt

For Bolt projects that use Supabase, the same two routes apply: ask Bolt to apply the migration exactly as written and review it before accepting, or run it yourself in the Supabase SQL editor or with the CLI. Check Bolt’s docs for how it applies migrations to a connected Supabase project.

Replit

If your Replit app uses Supabase and has a supabase/migrations folder, add the file there and run the CLI from the Replit Shell, keeping your Supabase access token in Replit Secrets rather than in code:

npx supabase link --project-ref <your-project-ref>
npx supabase db push

Or use the SQL editor. PatchLabs checks Supabase migrations only, so apps on a different database aren’t covered. Check Replit’s docs for its current database options.

Cursor or any local repo

Save the file in supabase/migrations/, run supabase db reset to test it locally, commit, and ship it through your usual route (supabase db push or your CI). Asking Cursor’s agent to explain the fix is fine; letting it “improve” the SQL isn’t, because the proof covers the file as written.

Code changes

Some fixes remove access that a page relied on, such as a public list of every user’s profile. When that’s the case, the report names the change in plain words. Ship it with the migration, or the page may show an empty list after the fix goes live.

Confirm it worked

1. Run a re-check: press Run check now on the app’s page in your dashboard (or Run now in the apps list), call POST /apps/{id}/checks, or request a new free check. The result should read no leaks found.
2. Check you shipped the exact file we proved. Its SHA-256 should match fix_sha256 in the check’s signed receipt:

shasum -a 256 supabase/migrations/*_patchlabs_leak_fix.sql   # macOS
sha256sum supabase/migrations/*_patchlabs_leak_fix.sql       # Linux

Compare against the downloaded file. Editors that add a trailing newline on save change the hash without changing the SQL.

If something breaks

Roll forward with a new migration that restores the old behaviour: the fix’s DROP POLICY lines name exactly what it replaced, so you can recreate it. Then tell us with the check link and what broke. We read every one, and it helps the next fix.