Preview to Prod

This is the first issue of Preview to Prod. It's a short email, every two weeks, for people shipping apps built with Lovable, Bolt, Replit or Cursor on Supabase. Each issue covers one useful fix, with sources.

What Supabase will change on Oct 30

From October 30, 2026, Supabase will stop exposing new tables in the public schema of existing projects to its Data API (Supabase's auto-generated REST and GraphQL API). A new table stays invisible to the API until you give access with a Postgres grant.

What doesn't change:

• Tables you already have keep their grants and keep working.
• RLS works the same way.
• Tables in storage, auth and other schemas aren't affected. Neither are apps that only use a direct Postgres connection.

New projects have worked this way by default since the May 30, 2026 rollout. Before Oct 30, the Security Advisor in your Supabase dashboard already flags the tables this will affect and shows the SQL to fix them.

Source: Supabase changelog: Tables not exposed to Data and GraphQL API automatically

What you'll see: error 42501

Once the change reaches your project, when you (or your AI tool) add a table without a grant, requests to it fail with:

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

That means the grant is missing. As Supabase puts it: "If the grant is missing, Postgres rejects the query before RLS comes into play." Once a grant exists, RLS decides which rows each role can see. So a grant on a table with RLS switched off opens every row to that role.

Two shortcuts to avoid

• grant all on public.your_table to anon. If RLS is off, anyone with your public key can read and change every row. That key ships in your site's JavaScript by design, so "anyone" really does mean anyone.
• Putting the secret key (sb_secret_) in your frontend to make the error go away. (service_role is its legacy name.) From Supabase's docs: "A secret key bypasses every Row Level Security policy you have. Never put one in a browser, a shipped application, or source control." (Supabase API keys)

The safe fix

Our rule: grant each role only what it needs, keep RLS on with policies, and never GRANT ALL to anon.

Put the grant, the RLS change and the policies in one migration. This example is for a table where each row belongs to one signed-in user. Swap notes and user_id for your table and its owner column:

revoke all on table public.notes from anon, authenticated;
grant select, insert, update, delete on table public.notes to authenticated;

alter table public.notes enable row level security;

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

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

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

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

Two notes:

• Only give anon access to tables that signed-out visitors actually need, like a public feed, and only select.
• Ship the policies in the same change that turns RLS on. Supabase: "Once RLS is enabled, no data is accessible through the API when using a publishable key, until you create policies." (Supabase: Row Level Security)

Building with Lovable or Bolt? Add this to your project instructions: "Every new Supabase table must be created in one migration that enables RLS, revokes all from anon and authenticated, grants only the operations the app needs, and adds one policy per operation."

A 2-minute check

Run this in the Supabase SQL editor. It lists the tables in public that have RLS switched off:

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;

The Security Advisor (Dashboard, then Advisors) reports the same problem as an error: "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)

One number

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.

Source: Sentris, "We scanned 2,144 AI-built Supabase repos. 40.6% had a critical exposure.", Aug 5, 2026. Sentris sells a scanner, so treat this as vendor research. Sentris may become a referral partner.

---

Rather have us do it? PatchAndShip fixes grants, RLS policies, storage policies and exposed keys for a fixed $149 (Security Fix), or $249 including deployment to your own domain (Fix & Deploy). Security Fix: every critical issue on our checklist fixed within 48 hours of working access. Fix & Deploy: fixed and live on your host within 48 hours. Otherwise, a full refund if you ask within 14 days of purchase. The Launch Pack is not covered. “Critical” and “live” are defined in our Refund Policy. It's not a penetration test or a compliance certification.

Not sure where you stand? Request a free check. PatchAndShip's free mini check is passive: it looks only at the public homepage, its scripts and its security headers, and nothing else. It flags exposed secret keys, missing headers and public storage links found in the code (the bucket itself is never opened or listed). No database queries, no logins, no changes. It returns a one‑page summary within 24 hours. It's for app owners, or someone the owner has authorized.

Stuck on a Supabase or deploy problem? Write to patchandship@gmail.com. Good questions may turn into future issues, and we always leave your app's name out.