DEV Community: PatchAndShip

Free check walkthrough for the first 20 Lovable, Bolt, Replit or Cursor apps

PatchAndShip — Sun, 01 Nov 2026 20:52:50 +0000

If you built an app with Lovable, Bolt, Replit or Cursor and it runs on Supabase, a few settings may never have had a second look. Row Level Security might be off on a table, a key might be sitting in your JavaScript, or a storage bucket might be public when you didn't mean it to be.

So we're offering a free personal walkthrough to the first 20 people who ask. Once 20 people have claimed it, it ends.

We run the instant check on your app and walk you through what it found in plain words: any keys or secrets sitting in your JavaScript, which security headers are missing, and any public storage links in your files. It only sees what a visitor's browser already gets. It doesn't query your database or look at your RLS rules, so we'll tell you plainly what it can't see.

It's free, there's nothing to buy, and it's one walkthrough per app or founder.

To ask for one, run the free instant check on your app first. It needs no signup and only looks at what any visitor's browser already gets. Then email patchandship@gmail.com with your app's link and "first 20" in the subject.

https://patchandship.com/check.html?utm_source=devto&utm_medium=article&utm_campaign=first-20

Got a question about your own setup? Leave it in the comments and we'll answer there.

Not affiliated with Lovable, Bolt, Replit or Cursor.

Your app worked, then one deploy broke it. Where do you look first?

PatchAndShip — Sun, 01 Nov 2026 19:27:08 +0000

A common one with Lovable and Bolt apps: it was live and fine, then a small change and a new deploy, and now it's a blank page, a 404 on refresh, or a login loop.

Often the code isn't the problem. Something outside it didn't come along:

VITE_ env vars are baked in at build time, so set them on the host and redeploy.
Supabase's Site URL and Redirect URLs may still point at an old address.
Refreshing a page gives a 404? The host often needs a rewrite to index.html.

What's the last thing that broke after a deploy for you?

If you're stuck on one, App Rescue is $149 for one issue: https://patchandship.com/app-rescue?utm_source=devto&utm_medium=community&utm_campaign=app-rescue

Moving off Lovable Cloud to your own Supabase project

PatchAndShip — Sun, 01 Nov 2026 18:51:11 +0000

If your app runs on Lovable Cloud and you want your database in a Supabase account you own, you can move it. Lovable doesn't do it in one step, though. Here's what changes, what you keep, and a quick way to check the move worked before you remove anything.

Why people move

It usually comes down to three things. You want your database in a Supabase account you own and control. You want to see and manage your own usage and billing. And you want room to keep building with other tools, not only inside Lovable.

What you keep

Lovable can export your database, including your users' accounts. You start the export under More → Database → Manage → Settings → Export data → Export → Start export, then download it from More → Storage.

Then you restore that export into your new Supabase project by running a few restore commands on your own computer, with your own database password.

Your users keep their passwords, so nobody has to reset anything.

What changes

The export is a copy of your data and users. It isn't a working app on its own. A few things don't come with it:

Files, secrets, sign-in settings and edge functions. These have to be set up again in the new project.
Sessions. Anyone who's signed in will need to sign in again, once.
Your app's connection. Your env vars (in a Lovable app, usually VITE_SUPABASE_URL and VITE_SUPABASE_PUBLISHABLE_KEY) still point at the old backend until you change them to the new project's URL and public publishable (or legacy anon) key, then rebuild.
Auth URLs. In your new project's Supabase Auth settings, update the Site URL and the redirect URLs to match your live app.
Google sign-in, if you use it. In Google Cloud, add your new Supabase callback URL under Authorized redirect URIs, and your live domain under Authorized JavaScript origins. Then turn on the Google provider in the new project and paste in your Google client ID and secret.

So the full job is: export, restore, check, reconnect sign-in, and point your app at the new project.

Don't remove Lovable Cloud yet

Leave your Lovable Cloud backend alone until you've checked everything on the new project. Using Remove database in Lovable (More → Database → Manage → Settings) permanently deletes the database, its backups, your app's user accounts and your storage files, and it can't be undone. Keep your export file too.

A 3-step self-check

Before you call the move done, run through these on your live app:

Data and rules. Open the new project in Supabase and look at your tables. Are the rows there? Are your row level security policies there on the same tables as before? Then sign in as a normal user and make sure you see your own data, and not anyone else's.
Sign-in. Sign in with an existing user's email and password. If you use Google, sign in with Google too and make sure it sends you back to your live app, not to a localhost or preview URL. If it bounces, look at the Site URL, the redirect URLs and the Google settings above.
The app is really on the new project. Open your live app with the browser dev tools on the Network tab and check that requests go to the new project's Supabase URL. Upload and open a file if your app uses storage, and trigger anything that runs an edge function.

If all three pass, your app is running on a Supabase project you own. Only then think about removing the old backend.

If you'd rather not do it yourself

If you'd like it handled, we offer this move: you run the restore on your own computer with our step-by-step guide, and we never see your database password. We set the rest up with you and point your app at the new project. Auth users come over on every size, storage files on Medium and Large, and up to 10 edge functions on Large. You pick a size and send a request through the page. Details are here: Lovable Cloud to Supabase.

Questions about your own move? Ask in the comments.

Want the next guide by email? Sign up for our newsletter, Preview to Prod: patchandship.com/newsletter.

Two common breaks in Lovable and Bolt apps (and when to hand them off)

PatchAndShip — Sat, 31 Oct 2026 14:35:46 +0000

Two problems come up a lot with apps built in Lovable, Bolt, Replit and Cursor, so we put up a page for each.

1. It works in preview, then breaks once it's live

Often it's a small setting, not your code:

Supabase Site URL is the default place people land after sign-in when your app doesn't pass a redirectTo. If it still points at the preview domain, that's where they go. Set it to your live domain.
Redirect URLs is the allow list. Add your live domain, like https://yourapp.com/**.
Google sign-in: your live domain goes under Authorized JavaScript origins, and the redirect URI is https://<project>.supabase.co/auth/v1/callback.
Blank page or "supabaseUrl is required": with Vite, only VITE_-prefixed vars reach the app, and they're baked in at build time. Add them on your host, then redeploy.

If you've checked those and it's still stuck, App Rescue is $149 for one issue. Send us your app and what's broken: App Rescue

2. Moving off Lovable Cloud to your own Supabase

Lovable can export your database, including your users' accounts. Files, secrets, sign-in settings and edge functions don't come with it, so those get set up again. You run the restore with your own database password; nobody helping you should need it. Don't remove Lovable Cloud until you've checked everything, since removing it deletes its database, backups, users and files.

We do the move at a fixed price by size ($149, $349 or $599). What we move depends on the size: auth users on every size, storage files on Medium and Large, and edge functions on Large. Tell us about your app: Lovable Cloud to Supabase

Not affiliated with Lovable, Bolt, Replit, Cursor or Supabase.

Lovable or Bolt app won't deploy: common fixes

PatchAndShip — Fri, 30 Oct 2026 20:04:45 +0000

It works in the editor. You hit publish, or push to Vercel or Netlify, and something breaks. The build fails, the page is blank, login bounces you back, or every page except the home page shows a 404.

Most of these come down to a short list of causes. Here they are, in the order we'd check them.

1. The build itself fails

The preview in Lovable or Bolt is more forgiving than a production build. A production build runs npm run build, and it stops on things the preview lets slide, like a type error or a missing import.

What to do:

Read the error. In Lovable, a failed publish shows a "Publishing failed" message or "Build errors need fixing", with a Try to fix button. Use it, or describe the error in chat. (Lovable: Publish)
Fix the build errors (or let Try to fix do it), then publish again. (Lovable: Publish)
If Bolt can't publish to Netlify, Bolt's own fallback is: run the build command (usually npm run build), download the project, and deploy it to Netlify by hand. (Bolt: Publishing issues)

2. Missing environment variables (the VITE_ prefix)

Lovable and most Bolt apps are built with Vite. Vite only passes variables that start with VITE_ to your app in the browser. A variable called SUPABASE_URL won't be there. (Vite: Env variables)

Your host also doesn't read the .env file from your project. Netlify says its build system doesn't read .env files; you add the values in its settings instead. (Netlify: Build environment variables)

What to do:

Copy the exact names from your project's .env file into your host's environment variable settings. (Netlify: Deploy your Lovable app)
Then rebuild. VITE_ values are baked in when the app builds, not when it runs. Adding them after the build changes nothing until you deploy again. (Lovable: Hosting outside Lovable)
Only put public values in VITE_ variables. Vite's own docs say they end up in the code anyone can download. Private keys belong in server functions. (Vite: Env variables)

3. Supabase URL and key not set on the host

This is the most common version of #2. The app loads, but nothing saves, lists are empty, or sign-in does nothing. Netlify's Lovable guide says a site deployed by drag-and-drop (no build, no environment variables) loads but fails every data call. (Netlify: Deploy your Lovable app)

What to do: set these on your host, copied from your .env:

VITE_SUPABASE_URL
VITE_SUPABASE_PUBLISHABLE_KEY (older projects use VITE_SUPABASE_ANON_KEY)
VITE_SUPABASE_PROJECT_ID if your Lovable project has it

(Lovable: Hosting outside Lovable, Netlify: Deploy your Lovable app)

Newer Lovable projects that use server functions also need SUPABASE_URL and SUPABASE_PUBLISHABLE_KEY for the server side, plus any secrets those functions read. (Lovable: Hosting outside Lovable)

4. 404 when you refresh a page

The home page works. You click to /dashboard, it works. You refresh, and get a 404. This happens because the host looks for a real file called /dashboard and there isn't one. Your app handles that route in the browser.

What to do: tell the host to send every route to index.html.

Netlify: add a file public/_redirects with this one line: /* /index.html 200. (Netlify: Rewrites and proxies, Netlify: Deploy your Bolt app)
Vercel: add a vercel.json with a rewrite from /(.*) to /index.html. (Vercel: vercel.json)

One exception: Lovable projects created from May 13, 2026 are built on TanStack Start and run a server part. For those, a 404 usually means the host isn't running that server part, not a missing rewrite. Vercel and Netlify detect it on their own; on Vercel, it needs @lovable.dev/vite-tanstack-config at ^2.6.2 or higher. (Lovable: Hosting outside Lovable, Vercel: Lovable)

5. Login redirects back to the wrong place

Sign-in works in the preview, but on your real domain users land on localhost, the old preview link, or an error. Supabase only sends people to addresses you've allowed.

What to do: in your Supabase dashboard, open Authentication â†’ URL Configuration (direct link).

Set Site URL to your live address. Supabase says this setting is critical for email confirmations and password resets. (Supabase: Redirect URLs)
Add your live address, and any preview addresses you use, to Redirect URLs. (Supabase: Redirect URLs)
If you use Google sign-in or another OAuth provider, add your live domain to that provider's allowed redirect URLs too. (Lovable: Hosting outside Lovable)

6. Wrong Node version

Bolt builds inside a browser-based environment that can differ from your host's. A build that passes in Bolt can fail on the host because of the Node version. (Netlify: Deploy your Bolt app)

What to do:

Lovable's docs say to build with Node.js 22. (Lovable: Hosting outside Lovable)
On Netlify, set it with a .nvmrc file or a NODE_VERSION variable. (Netlify: Build environment variables)
On Vercel, set it under Project Settings â†’ Build and Deployment â†’ Node.js Version. (Vercel: Configuring a build)

7. Wrong build output folder (blank page)

If the deploy "succeeds" but you see a blank page or a folder listing, the host may be serving the wrong folder. Vite writes the finished site to dist. Create React App uses build. (Netlify: Deploy your Bolt app)

What to do: set the build command to npm run build and the publish (output) directory to dist. On Vercel, Lovable says no output directory setting is needed. (Lovable: Hosting outside Lovable)

A quick check after any deploy

Lovable suggests testing a new host before you switch over: open a deep page directly and refresh, sign in and out, and try the reads, writes and uploads your app depends on. (Lovable: Hosting outside Lovable)

FAQ

Why does my Lovable app work in the editor but not when deployed?
The production build is stricter than the preview, and your host doesn't have the values from your .env file until you add them. Check the build error first, then your VITE_ variables.

Why do I get a 404 when I refresh a page?
The host is looking for a file that doesn't exist. Add a rewrite that sends every route to index.html: /* /index.html 200 in Netlify's _redirects, or a rewrite in vercel.json.

Why does login send users to localhost?
Your Supabase Site URL still points at your old or local address. Change it to your live domain under Authentication â†’ URL Configuration, and add the domain to Redirect URLs.

Do I need to rebuild after adding environment variables?
Yes. VITE_ values are baked in at build time, so deploy again after you add or change them.

Still stuck?

Want to know if your live app is exposing keys? Our free instant check scans your homepage and its JavaScript for leaked keys and reviews your security headers. It can't see your database.

Want it fixed and deployed for you? Fix & Deploy ($249) is everything in the Security Fix plus the production deploy to one host (Vercel or Netlify, or Lovable or Replit hosting, depending on your builder): env vars, Supabase auth redirect URLs, custom domain with SSL, and a smoke test. See Fix & Deploy

A 12-step security checklist for vibe-coded apps on Supabase (2026)

PatchAndShip — Fri, 30 Oct 2026 16:42:10 +0000

You built an app with Lovable, Bolt, Replit, v0 or Cursor on top of Supabase, and it works in preview. Before real users show up, here's how to check whether their data is actually protected. For each step you get what to check, how to check it yourself, and what the fix looks like.

One rule before we start: run every check against an app you own. Don't test someone else's app without permission, not even with a single curl.

Short version: Row Level Security (RLS) on for every table in public, every policy limited to the row's owner, no secret key in your frontend or repo, private files in private buckets, and Site URL pointing at production. Then test it all while logged out.

What the scans found

Two security vendors published scans this year. Both sell scanning tools, and they measured different things, so don't compare their numbers against each other.

Sentris (public code repositories, published Aug 5, 2026; vendor research): Sentris scanned 2,144 public repositories that use Supabase, not live apps. In Sentris's scan of public GitHub repositories, 57% of Lovable repos had a table in the public schema with Row Level Security switched off, compared with 21.7% of Supabase repos with no AI-tool marker. Sentris says this one check accounts for almost all of the gap. Leaked credentials showed up in 11.3% of Lovable repos and 11.2% of repos with no AI-tool marker, "the same rate, within noise". A public storage bucket turned up in 38.7% of Lovable repos, compared with 10.5% of repos with no AI-tool marker. (Sentris)

Symbiotic Security (live sites, published Jun 2, 2026; vendor research): In Symbiotic Security's scan of 1,072 vibe-coded sites that use Supabase, 172 let anyone delete database records without authentication, 172 allowed unauthenticated PATCH (modification), 39 had tables fully readable with the public Supabase key, and 14 allowed unauthenticated inserts. (Symbiotic Security)

Per Sentris, the gap between Lovable repos and repos with no AI-tool marker comes almost entirely from tables with RLS switched off, not from leaked credentials. So that's where we start.

How Supabase security works, in one paragraph

Your frontend talks to Supabase directly, using a key that ships in your JavaScript. Publishable (anon) keys are meant to be public. What actually protects your data is RLS together with grants: grants control whether a role can reach a table, RLS controls which rows it can access. The other key is a different story. Supabase: "A secret key bypasses every Row Level Security policy you have. Never put one in a browser, a shipped application, or source control." (API keys, Securing your API)

So "is my key exposed?" is usually the wrong question. The better questions are "which key?" and "what do my policies allow?"

The 12 checks

1. Every table in `public` has RLS enabled

select c.relname as table_name
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public'
  and c.relkind = 'r'
  and not c.relrowsecurity;

Any table this returns has RLS off. The Security Advisor flags this as an error (lint 0013): "Anyone with your project URL can read, edit, and delete all data in this table because Row-Level Security is not enabled." (Database Advisors)

Fix: alter table public.your_table enable row level security; and add the policies from step 2 in the same migration. Supabase: "Once RLS is enabled, no data is accessible through the API when using a publishable key, until you create policies." (Row Level Security)

2. Policies are per operation and scoped to the owner

The Advisor flags always-true conditions such as using (true) as a permissive policy (lint 0024, a warning). And when a request has no signed-in user, auth.uid() returns null (Row Level Security).

Our guidance: using (true) lets everyone in, and auth.uid() is not null on its own lets any signed-in user reach every other user's rows. Compare auth.uid() to the owner column:

create policy "orders_select_own" on public.orders
  for select to authenticated
  using ((select auth.uid()) = user_id);

create policy "orders_insert_own" on public.orders
  for insert to authenticated
  with check ((select auth.uid()) = user_id);

create policy "orders_update_own" on public.orders
  for update to authenticated
  using ((select auth.uid()) = user_id)
  with check ((select auth.uid()) = user_id);

create policy "orders_delete_own" on public.orders
  for delete to authenticated
  using ((select auth.uid()) = user_id);

For updates, using decides which existing rows can be updated and with check decides what the resulting row may look like, which stops a user from reassigning user_id. If with check is omitted, using applies to both (PostgreSQL: CREATE POLICY). We write both so the rule is explicit. Wrapping it as (select auth.uid()) lets Postgres cache the result per statement via an initPlan, which improves RLS performance (RLS performance and best practices).

Check: sign in as user A, grab the ID of a record owned by user B, and try to load, edit and delete it. Every attempt should fail.

3. Views don't quietly bypass RLS

The Advisor flags a security definer view as an error (lint 0010). Views bypass RLS by default because they run with the owner's permissions, usually postgres in Supabase. On Postgres 15+:

create view public.public_profiles
with (security_invoker = true) as
select id, display_name, avatar_url from public.profiles;

On older versions, revoke access from anon and authenticated, or move the view to an unexposed schema (Row Level Security, PostgreSQL: CREATE VIEW).

4. The logged-out test returns only public data

In your live app, open DevTools, then Network, find a request to https://<project>.supabase.co/rest/v1/... and copy the apikey header. Then:

curl "https://<project>.supabase.co/rest/v1/<table>?select=*&limit=5" \
  -H "apikey: <public-key>"

Private tables should return [] or a permission error. If one returns rows, anyone can do what you just did. Own apps only.

5. No secret key in the frontend or the repo history

Search the built bundle: npm run build, then grep -rE "sk_live_|sb_secret_|service_role|c2VydmljZV9yb2xl|NlcnZpY2Vfcm9s|zZXJ2aWNlX3Jv" dist/. The last three patterns catch a legacy service_role key: it's a JWT (starts with eyJ), so the word "service_role" only appears base64-encoded inside it.
Vite: "Variables prefixed with VITE_ will be exposed in client-side source code after Vite bundling." (Vite)
History: git log -p --all | grep -E "sk_live_|sb_secret_|service_role|c2VydmljZV9yb2xl|NlcnZpY2Vfcm9s|zZXJ2aWNlX3Jv".

If a secret was committed, GitHub says to revoke or rotate it first. Removing it means rewriting history, and old commits may still be reachable in clones, forks, cached views and pull requests (GitHub Docs).

Fix order (our guidance): move the code to a server (Edge Function or API route), create a new key, deploy it everywhere, then revoke the old one. Revoke last, or you'll break production mid-deploy.

6. Storage buckets match what's in them

Buckets "are private by default". For a public bucket, "anyone who possesses the asset URL can readily access the file" (Storage Buckets). Check which buckets are Public, and whether any of them hold per-user files like IDs, invoices or exports. Make those private and add policies on storage.objects.

7. New public tables need explicit grants. Never GRANT ALL to anon

From Oct 30, 2026, once the change reaches your project, new tables in public need an explicit grant before the Data API can reach them; existing tables keep their current grants. New projects have had this by default since the May 30, 2026 rollout (Supabase changelog). The risky quick fix is grant all ... to anon: once a grant exists, RLS is the only guard.

More on this: GRANT ALL to anon is the wrong fix for Supabase 42501 after Oct 30

Our rule: grant only what each role needs, keep RLS on with policies, and never GRANT ALL to anon. Put the grant, RLS and policies in one migration:

begin;
alter table public.orders enable row level security;
revoke all on table public.orders from anon, authenticated;
grant select, insert, update, delete on table public.orders to authenticated;
-- plus the four policies from step 2
commit;

8. Auth URLs point at production

Supabase: change the Site URL "from http://localhost:3000 to your production URL"; it's "critical for email confirmations and password resets". Use exact redirect URLs in production, not wildcards (Redirect URLs).

9. Payment state comes from verified webhooks

If the browser can mark a user "paid", so can anyone else. Set the flag only in a server-side handler for a verified Stripe webhook, and verify the Stripe-Signature header first. Stripe says endpoints "might occasionally receive the same event more than once", so log processed event IDs and skip repeats (Stripe: Webhooks).

10. Edge Functions check who's calling

OWASP Top 10:2025 keeps Broken Access Control at #1 (A01), including "an accessible API with missing access controls for POST, PUT, and DELETE" (OWASP). For each function, ask what stops a stranger from calling it. The answer should be a verified user JWT (plus a per-record check), a verified webhook signature, or a shared secret for cron. "Nobody knows the URL" doesn't count. Supabase's default is verify_jwt = true; leave it on for user-facing functions. For Stripe-style webhooks, keep verify_jwt = false and verify the signature in the handler (Functions auth).

11. Rate limits on anything that costs money or sends mail

Our guidance: endpoints that call a paid AI API, send email or SMS, or create accounts can be run up by a script. Add CAPTCHA or bot protection to sign-up if you see abuse, cap per-user usage on the server, and set spending limits with your providers.

12. You know what's deployed

Preview, repo and production drift apart over time. After any fix, re-run the logged-out test (step 4) and the two-account test (step 2) against production.

Got 15 minutes?

Run the RLS query in step 1.
Run the logged-out curl against your three most sensitive tables.
Run the two greps in step 5 (they cover sb_secret_, sk_live_ and legacy service_role JWTs).
Check which buckets are public.
Add one line to your AI tool's project instructions: Every new table must enable RLS, grant only needed operations, and have one owner-scoped policy per operation, in the same migration.

This isn't a penetration test, a compliance audit or a guarantee. Apps that handle health, payment-card or children's data need more than this.

Sources

Sentris: We scanned 2,144 AI-built Supabase repos (Aug 5, 2026; vendor research)
Symbiotic Security: We Scanned 1,072 Vibe Coded Apps (Jun 2, 2026; vendor research)
Supabase Docs: Database Advisors, Securing your API, API keys, Row Level Security, RLS performance, Storage Buckets, Redirect URLs, Functions auth
Supabase changelog: Tables not exposed to Data and GraphQL API automatically (Apr 28, 2026)
Vite: Env Variables and Modes, OWASP A01:2025, Stripe: Webhooks, GitHub: Removing sensitive data
PostgreSQL: CREATE POLICY, CREATE VIEW

Checked Oct 27, 2026. Lines marked "our guidance" are ours, not the sources'.

The full checklist, with the CVE background and more detail on each step, is on our site. If you'd like a second look, there's a free check.

Not affiliated with Supabase.

PatchAndShip Team

The easiest planted hole to misread in our Supabase demo

PatchAndShip — Thu, 29 Oct 2026 21:20:13 +0000

We planted a few holes in a throwaway demo Supabase project to see how each one looks from the outside. The easiest one to misread was the secret key in the frontend. A long eyJ... string in your bundle looks alarming, but the public anon key looks exactly like that too. What matters is whether one decodes to "role":"service_role", or whether a newer key starts with sb_secret_ (sb_publishable_ is meant to be public).

How do you all check what your app actually ships to the browser?

For our launch, we're doing a free 15-minute look at Supabase database rules for the first 10 apps. Read-only, no keys needed. Comment here or email patchandship@gmail.com if you want one.

GRANT ALL to anon is the wrong fix for Supabase 42501 after Oct 30

PatchAndShip — Tue, 27 Oct 2026 16:48:51 +0000

From Oct 30, 2026, Supabase will apply a change to existing projects: new tables in public won't be visible to the Data API until you grant access. Supabase's changelog puts it like this:

"Once the change is rolled out to your project, new tables you create in public schema require an explicit opt-in (via a Postgres grant) before the Data API can see them. Existing tables are not affected in your project, they keep their current grants and stay reachable."

Once the change reaches your project, the first new table you add will likely fail with 42501 permission denied for table. And the quickest-looking fix, often the one an AI assistant suggests, is this:

-- Don't run this
grant all on all tables in schema public to anon;

If you want the full walkthrough of what 42501 means, we covered it in the first article. This one is about the fix: keep RLS on, grant only what each table needs, and check your older tables too.

Read the error before you fix it

Three results look alike but mean different things:

42501 permission denied for table: the role has no grant. You need a specific grant.
An empty list, no error: the grant is there, and RLS is hiding rows. Check your policies.
42501 new row violates row-level security policy: RLS is working and blocked the write. Fix the policy or the data you send, not the grants.

Only the first one is a grant problem. A broad grant does nothing for the other two.

Why GRANT ALL to anon is wrong

anon is the role behind your public anon key, and that key ships in every browser that loads your app. Any signed-out request runs as anon.

GRANT ALL gives that role every table privilege Postgres has: SELECT, INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES, TRIGGER, and, on Postgres 17 and later, MAINTAIN. A signed-out visitor has no use for most of those.

After that, RLS is the only thing deciding what happens. If RLS is off on a table, or a policy is permissive (like using (true)), anyone with your public key can read or write that table. The grant removed one layer of protection and left everything to the other.

Step 1: turn RLS on first

Enable RLS before you grant anything, in the same migration:

alter table public.your_table enable row level security;

With RLS on and no policies, the table returns nothing to API roles. That's a safe starting point. Then add the grants and policies the app actually needs.

Step 2: grant only the verbs each table uses

For a typical per-user table, signed-in users work with their own rows and signed-out visitors need nothing:

alter table public.your_table enable row level security;

grant select, insert, update on public.your_table to authenticated;

create policy "Users read own rows"
  on public.your_table for select
  to authenticated
  using ((select auth.uid()) = user_id);

create policy "Users insert own rows"
  on public.your_table for insert
  to authenticated
  with check ((select auth.uid()) = user_id);

create policy "Users update own rows"
  on public.your_table for update
  to authenticated
  using ((select auth.uid()) = user_id)
  with check ((select auth.uid()) = user_id);

Add delete (and a matching delete policy) only if the app deletes rows. No grant to anon at all: a signed-out request gets a 42501, which is correct here.

For a table that really is public, like a published product list, anon gets select and nothing else, with a policy that limits which rows:

alter table public.products enable row level security;

grant select on public.products to anon;

create policy "Anyone reads published products"
  on public.products for select
  to anon, authenticated
  using (published = true);

If the table has a serial id, the role that inserts also needs the sequence:

select pg_get_serial_sequence('public.your_table', 'id');
-- usually returns public.your_table_id_seq
grant usage on sequence public.your_table_id_seq to authenticated;

Step 3: check your older tables too

The changelog says existing tables "keep their current grants and stay reachable". Tables created under the old defaults may give anon more than a new one would, so review them too.

These two queries only read metadata. First, what anon and authenticated can do on each table:

select table_name, grantee, string_agg(privilege_type, ', ' order by privilege_type) as privileges
from information_schema.role_table_grants
where table_schema = 'public'
  and grantee in ('anon', 'authenticated')
group by table_name, grantee
order by table_name, grantee;

Second, which tables have RLS off:

select tablename
from pg_tables
where schemaname = 'public'
  and rowsecurity = false
order by tablename;

Start with any table that's in the second list and also shows grants for anon or authenticated in the first. Before you revoke anything, check what your signed-out pages actually read, so you don't break a public page. To take back an anon grant and keep only reads:

revoke all on public.your_table from anon;
grant select on public.your_table to anon; -- only if the table is truly public

Quick check

Which 42501 is it: "permission denied" or "violates row-level security policy"?
RLS enabled on the table before any grant?
anon has no grant, or only select on a truly public table?
authenticated has only the verbs the app uses, each with an owner policy?
serial id? Sequence usage granted to the inserting role?
Older tables reviewed with the two queries above?
Tested as a real signed-in and signed-out user, not in the SQL editor?

That last point matters. The SQL editor runs as postgres, which bypasses RLS, so a query that works there tells you nothing about what your users see. Test from the app, or use the dashboard's user impersonation to run queries as a specific role or user.

Recap

When Oct 30 reaches your project and a new table throws 42501, the fix is a few lines, not one big grant: RLS on first, the specific verbs each role needs, and a review of the tables you already have.

Not affiliated with Supabase.

Want a quick outside look at what your app's public files expose? Run the free check.

Supabase error 42501 "permission denied for table": the safe fix before Oct 30

PatchAndShip — Mon, 26 Oct 2026 06:50:05 +0000

If a request to your Supabase table suddenly fails with 42501 "permission denied for table", the role making the request has no grant on that table. It's a one-line error with a tempting one-line fix, and that fix is exactly what you want to avoid.

TL;DR: Grant only what each role needs, keep RLS on with policies, and never GRANT ALL to anon.

Status as of Oct 31, 2026: Supabase said it would start applying this change to existing projects from Oct 30. Once it reaches a project, new tables in public need a grant before the Data API can see them.

What Supabase will change

Here's how Supabase's changelog puts it: once the change reaches a project, "new tables you create in public schema require an explicit opt-in (via a Postgres grant) before the Data API can see them." The Data API is the auto-generated REST and GraphQL layer, the thing supabase-js talks to.

The timeline:

April 28, 2026: new projects could opt in at creation.
May 30, 2026: became the default for all new projects, rolled out gradually over a few weeks.
October 30, 2026: Supabase said it would start applying it to existing projects from Oct 30.

What stays the same, per Supabase:

Existing tables keep their current grants and stay reachable.
RLS behavior is unchanged.
Apps that only use a direct Postgres connection aren't affected.
Only the public schema is affected. storage, auth, realtime and custom schemas aren't.

Source: Supabase changelog: Tables not exposed to Data and GraphQL API automatically (published Apr 28, 2026).

What the error looks like

"code": "42501",
"message": "permission denied for table your_table"

The response also includes a hint with a suggested GRANT statement. Read it before you paste it. The right grant depends on who should see the data.

Same code, different cause: if the message says "new row violates row-level security policy", your grant is fine. An RLS policy's with check rejected the row. Fix the policy, leave the grants alone, and don't turn RLS off. (Supabase: Database API 42501 errors)

Why `GRANT ALL` to anon is the wrong fix

anon is the role behind your app's public key, the one that ships in your JavaScript. Your AI tool may suggest grant all on table ... to anon. The error disappears. Here's what you gave up to make that happen.

Supabase spells out the order of checks: "If the grant is missing, Postgres rejects the query before RLS comes into play." (Supabase changelog) Grants decide whether a role can reach a table. RLS decides which rows it can see (Supabase: Securing your API). Once the grant is in place, RLS is the only thing between a visitor and your data.

And if RLS is off on that table, Supabase's Security Advisor (lint 0013) doesn't sugarcoat it: "Anyone with your project URL can read, edit, and delete all data in this table because Row-Level Security is not enabled." (Supabase: Database Advisors)

Supabase's advice: "Use both controls for every exposed object."

The safe fix: grant, RLS and policies in one migration

Supabase's recommended fix treats three things as one unit: the grant, enabling RLS, and the policies you need. Ship them in one migration so none of them can go out without the others.

Here's an example for an orders table where each row belongs to one signed-in user via user_id:

begin;
alter table public.orders enable row level security;
revoke all on table public.orders from anon, authenticated;
grant select, insert, update, delete on table public.orders to authenticated;

create policy "orders_select_own" on public.orders
  for select to authenticated
  using ((select auth.uid()) = user_id);

create policy "orders_insert_own" on public.orders
  for insert to authenticated
  with check ((select auth.uid()) = user_id);

create policy "orders_update_own" on public.orders
  for update to authenticated
  using ((select auth.uid()) = user_id)
  with check ((select auth.uid()) = user_id);

create policy "orders_delete_own" on public.orders
  for delete to authenticated
  using ((select auth.uid()) = user_id);
commit;

Supabase's changelog example also grants service_role. Add that if your own server code reads or writes the table:

grant select, insert, update, delete on table public.orders to service_role;

Only grant anon access to data that signed-out visitors really need, and usually only select.

Test it: sign out and read the table with just the public key. You should get an error or an empty list. Only test projects you own or are authorized to test.

New projects hit this too

New projects have behaved this way by default since the May 30, 2026 rollout, so a brand-new project may need the same grants today.

If an AI tool writes your migrations

Give it the rule before it writes the migration. Paste this into your project instructions:

When you add a new table to Supabase, write one migration that does three things together: grant only the access each role needs (never GRANT ALL to anon), enable Row Level Security on the table, and add one policy per operation that limits each signed-in user to their own rows. Do not turn Row Level Security off to make an error go away.

Then check what it writes against the example above before you run it.

Quick FAQ

Will my existing tables break? No. Supabase says existing tables keep their grants and stay reachable, and RLS behavior is unchanged. The change only covers new tables in public.

Does it affect storage or auth tables? No. Only default privileges in public.

Where do I see affected tables? In the Security Advisor. Supabase: "From today through October 30, the Security Advisor flags affected tables per project and shows the remediation SQL." Supabase also planned email notices to owners and admins of active projects on September 23 and October 23, 2026.

Sources

Supabase changelog: Breaking Change: Tables not exposed to Data and GraphQL API automatically (Apr 28, 2026): timeline, scope, error 42501, recommended fix, Security Advisor.
Supabase Docs: Securing your API: grants and RLS.
Supabase Docs: Database Advisors: lint 0013.

All checked Oct 26, 2026. The rule "grant only what each role needs…" is our own guidance.

The full guide, kept up to date after Oct 30, is on our site. Want a second pair of eyes on your app? Try the free instant check (results in your browser in a few seconds, and it doesn't store your results) or ask for the free emailed mini check (one page within 24 hours). For app owners or people they authorize.

PatchAndShip Team

DEV Community: PatchAndShip

Free check walkthrough for the first 20 Lovable, Bolt, Replit or Cursor apps

Your app worked, then one deploy broke it. Where do you look first?

Moving off Lovable Cloud to your own Supabase project

Why people move

What you keep

What changes

Don't remove Lovable Cloud yet

A 3-step self-check

If you'd rather not do it yourself

Two common breaks in Lovable and Bolt apps (and when to hand them off)

1. It works in preview, then breaks once it's live

2. Moving off Lovable Cloud to your own Supabase

Lovable or Bolt app won't deploy: common fixes

1. The build itself fails

2. Missing environment variables (the VITE_ prefix)

3. Supabase URL and key not set on the host

4. 404 when you refresh a page

5. Login redirects back to the wrong place

6. Wrong Node version

7. Wrong build output folder (blank page)

A quick check after any deploy

FAQ

Still stuck?

A 12-step security checklist for vibe-coded apps on Supabase (2026)

What the scans found

How Supabase security works, in one paragraph

The 12 checks

1. Every table in public has RLS enabled

2. Policies are per operation and scoped to the owner

3. Views don't quietly bypass RLS

4. The logged-out test returns only public data

5. No secret key in the frontend or the repo history

6. Storage buckets match what's in them

7. New public tables need explicit grants. Never GRANT ALL to anon

8. Auth URLs point at production

9. Payment state comes from verified webhooks

10. Edge Functions check who's calling

11. Rate limits on anything that costs money or sends mail

12. You know what's deployed

Got 15 minutes?

Sources

The easiest planted hole to misread in our Supabase demo

GRANT ALL to anon is the wrong fix for Supabase 42501 after Oct 30

Read the error before you fix it

Why GRANT ALL to anon is wrong

Step 1: turn RLS on first

Step 2: grant only the verbs each table uses

Step 3: check your older tables too

Quick check

Recap

Supabase error 42501 "permission denied for table": the safe fix before Oct 30

What Supabase will change

What the error looks like

Why GRANT ALL to anon is the wrong fix

The safe fix: grant, RLS and policies in one migration

New projects hit this too

If an AI tool writes your migrations

Quick FAQ

Sources

1. Every table in `public` has RLS enabled

Why `GRANT ALL` to anon is the wrong fix