DEV Community: FixLoop

Lovable custom domain stuck on Verifying? It is almost always one of five DNS or auth settings

FixLoop — Sat, 24 Oct 2026 13:02:12 +0000

Your Lovable custom domain is not working: it sits on Verifying, the browser shows a security warning, it loads your old website, or the site works but login fails. From the guide: "Almost every case is one of five DNS or auth settings, and Lovable's domain status tells you which one."

Open Project settings, Domains, read the status next to the domain, then fix the matching cause.

The records Lovable expects

For a domain bought elsewhere and connected with manual setup, Lovable gives you two records:

A record on @: 185.158.133.1
TXT record on _lovable: lovable_verify=...

Then check that nothing else is fighting them: no AAAA record on that host, no leftover A or CNAME from your old host, and no CAA record that blocks Lovable's certificate authorities.

Stuck on "Verifying" or "Unable to verify"

Lovable cannot see the records it asked for yet. In order of how often it shows up:

The A record is proxied. In Cloudflare, an orange-cloud A record hides Lovable's IP. From the guide: "Lovable's docs say that while verification is in progress you should not enable proxying on the A record or point it at a CDN. Switch it to DNS only (grey cloud)."
The TXT value is cut off or on the wrong host. The host is _lovable and the whole lovable_verify= value has to be there.

A couple of other notes from the guide: custom domains need a paid Lovable plan, and the project has to be published before the domain serves anything.

If login breaks on the new domain

Adding a domain does not update Supabase Auth. Your new URL has to be in the Supabase redirect URL list too, or sign-in loops back to the old host.

Full guide with all five causes and the record table: fixloop.dev/guides/lovable-custom-domain-not-working. Stuck on it right now? Paste the error at fixloop.dev/start and we will email the likely cause within 24 hours, free. (I run FixLoop.)

Free tool: find Supabase tables that will 42501 after Oct 30

FixLoop — Fri, 23 Oct 2026 13:11:35 +0000

On October 30, 2026, existing Supabase projects stop auto-granting privileges on new tables in the public schema. Source: Supabase changelog.

What that means in practice:

Existing tables are not affected. They keep their current grants and stay reachable.
New tables in public created after the change without a GRANT return Postgres error 42501, permission denied for table, through the Data API (supabase-js, REST, GraphQL). RLS policies don't help, because Postgres checks grants before RLS.
Direct Postgres connections, and the auth and storage schemas, are not part of this change.

The fix, if you just want the SQL

Put the grants in the same migration as the table and its policies, least privilege:

alter table public.your_table enable row level security;
grant select, insert, update, delete on table public.your_table to authenticated;
grant select, insert, update, delete on table public.your_table to service_role;
-- only if signed-out visitors should read it:
-- grant select on table public.your_table to anon;

Skip grant all on all tables in schema public. That also opens tables where RLS was never turned on.

The checker

If you have a pile of migrations (or Lovable keeps writing new ones), I built a free page that does the tedious part:

Supabase grants checker

Paste one or more migration files.
It lists new public tables that are missing a GRANT for authenticated or service_role (it also subtracts any later REVOKE in the paste).
Copy the GRANT statements it writes.

It runs entirely in your browser. The SQL is never sent anywhere, and there's no signup. Comments and string literals are ignored, and tables in auth, storage or other schemas are skipped.

Tell your AI builder

Lovable and other AI builders learned the old default: create table, enable RLS, add policies, done. Add this to your project instructions:

When you create a Supabase table, put CREATE TABLE, ENABLE ROW LEVEL SECURITY, the policies and explicit GRANTs to authenticated and service_role in the same migration. Grant to anon only if signed-out users should read it. Never use GRANT ALL.

Full walkthrough: Supabase Oct 30 grants change: fix 42501 on new tables.

Still stuck on a 42501 (or anything else in a Lovable/Supabase app)? Paste the error and get a free diagnosis within 24 hours.

Supabase "Email address not authorized": why users never get your signup email

FixLoop — Thu, 22 Oct 2026 13:06:47 +0000

Sign-up works when you test it. Then real users sign up and the confirmation email never shows up, or supabase.auth.signUp() comes back with Email address not authorized.

Nothing is broken. Your project is still on Supabase's built-in email service, and that service only mails your own team. From the docs: "Unless you configure a custom SMTP server for your project, Supabase Auth will refuse to deliver messages to addresses that are not part of the project's team."

You're on the team, so your test emails arrive. Your users aren't, so theirs don't.

The limits of the default service

Team addresses only. "All other addresses will fail with the error message Email address not authorized."
A tiny rate limit. "Currently this value is set to 2 messages per hour," and Supabase says it can change without notice.
Best effort. It's "not meant for production use."

It applies to every Auth email: confirmations, magic links, one-time codes, invites, email change and password reset.

The fix: bring your own SMTP

Pick a provider. Supabase lists Resend, AWS SES, Postmark, Twilio SendGrid, ZeptoMail and Brevo as examples. Anything that speaks SMTP works.
Verify a sending domain with SPF, DKIM and DMARC. Use something like no-reply@auth.yourdomain.com.
Enable custom SMTP in your project's Authentication settings: host, port, user, password, sender email, sender name. Save.
Raise the rate limit. Custom SMTP starts at "a low rate-limit of 30 messages per hour." Bump it on the Auth rate limits page.
Test with an address that isn't on your team. A fresh Gmail works. Check spam too.

Host:          smtp.yourprovider.com
Port:          587
Username:      from your provider
Password:      SMTP password or API key
Sender email:  no-reply@auth.yourdomain.com
Sender name:   Your App

Don't "fix" it by turning off confirmation

Sign-up will look fine, but password reset still sends email, and on the default service that only reaches your team. Supabase's changelog warns "the forgot password / reset password flow will be broken for your project." It also lets anyone register with an address they don't own.

Still not arriving?

Still "not authorized": custom SMTP isn't enabled or didn't save.
"Error sending confirmation email": Supabase reached your SMTP server and got refused. The Auth logs show the provider's reply, usually bad credentials or an unverified From domain.
Lands in spam: finish SPF/DKIM/DMARC and keep Auth mail plain.
Link opens localhost or the preview: that's your Site URL, not SMTP. I covered that in Lovable login works in preview, breaks in production.

Full guide with the checklist and FAQ: fixloop.dev/guides/supabase-email-address-not-authorized. If you're stuck on it right now, paste the error at fixloop.dev/start and we'll email the likely cause within 24 hours, free. (I run FixLoop.)

Supabase select returns [] with no error: 5 RLS causes

FixLoop — Wed, 21 Oct 2026 13:11:05 +0000

You run supabase.from("posts").select("*") and get { data: [], error: null }. The rows are in the table. The same query works in the SQL editor. Your app shows nothing.

That's Row Level Security doing its job. RLS on with no matching SELECT policy filters every row out: zero rows, no error. The SQL editor runs as postgres, which owns the tables and skips RLS, so it sees everything. Your app goes through the Data API as anon or authenticated, and those roles only see rows a policy allows.

If you get 42501 permission denied for table instead, that's a missing GRANT, not this bug: the Oct 30 grants post.

1. RLS on, no SELECT policy

From the Supabase RLS docs: "Once RLS is enabled, no data is accessible through the API when using a publishable key, until you create policies."

create policy "anyone can read posts"
on public.posts
for select
using (true);

2. Policy targets the wrong role

to authenticated never matches a signed-out visitor, or a signed-in one whose session hasn't loaded yet. For public reads use to anon, authenticated, or leave out to.

3. `auth.uid()` is null

using (auth.uid() = user_id) only works when the request carries the user's JWT. Without it, null = user_id is never true, so every row disappears. Usual reasons: not signed in, querying on first render before the session is ready, or server code creating a client with only the anon key.

const { data: { session } } = await supabase.auth.getSession();
console.log("uid:", session?.user?.id); // undefined = no session

4. The rows belong to someone else

The policy is right; the data isn't. Check in the SQL editor:

select id, user_id from posts;

user_id null or another account's id means the insert path is wrong, not the policy.

5. Policy checks the wrong column

AI-generated schemas sometimes call the owner column user_id, owner_id, or reuse id. A policy comparing auth.uid() to the row's primary key matches nothing.

Confirm it in two minutes

select polname, cmd, roles, qual
from pg_policies
where tablename = 'posts';

No row with cmd = SELECT? That's cause 1. Then log user?.id right before the query. If it's undefined, fix auth first.

For owner-only data, this is the shape the Supabase docs use:

create policy "owners can read their posts"
on public.posts
for select
to authenticated
using ( (select auth.uid()) = user_id );

Don't fix it by disabling RLS. That hands every row to anyone holding your publishable key.

Full guide

Longer version with the debug policy trick, the empty-array vs 42501 difference, and an FAQ:

https://fixloop.dev/guides/supabase-select-returns-empty-array

I run FixLoop. Still stuck? Paste the error and we'll email you the likely cause, free.

Lovable app not deploying or broken after deploy: 4 env causes

FixLoop — Tue, 20 Oct 2026 13:12:41 +0000

Preview works. You publish, or point Cloudflare Pages / Netlify at the GitHub repo, and the live site is blank, says Failed to fetch, or the build dies. You didn't touch the React. The environment changed.

Lovable preview reads your committed .env and injects your Cloud secrets for you. An external host does neither unless you copy the values into its Production env and rebuild.

What it looks like

Preview loads data. Production is empty or spins forever.
The deploy is green, but DevTools > Network on the live site hits undefined.supabase.co, localhost, or your preview project.
The build log complains about a missing env var, or npm run build fails on a secret a plugin expected.
Edge Functions work in preview and 500 on the live host.

Test in a private window on the live hostname. Preview cookies and preview env will lie to you.

1. `VITE_` vars set on Preview, not Production

Cloudflare Pages and Netlify keep separate Preview and Production env. A common miss: paste VITE_SUPABASE_URL and the publishable key into Preview, check the preview URL, never open the Production tab.

Also: if you gitignored .env "for security," Lovable can keep previewing from its copy while the Git-connected host builds with nothing. Put the VITE_* values in the host's Production env (they're public browser values anyway). Never put backend secrets there.

2. Secrets that never left Lovable

Lovable Secrets (STRIPE_SECRET_KEY, RESEND_API_KEY, webhook signing secrets) are injected into Lovable Cloud functions. They're not in git, so your new host or your own Supabase project doesn't have them. Copy every name the server code reads into the host's secrets (or Supabase Edge Function secrets). A function that 500s only in production with a missing-env line in its log is this one.

The opposite mistake: putting SUPABASE_SERVICE_ROLE_KEY in a VITE_ var to "make it work." That ships it in your JS bundle. That's a leak, not a fix.

3. Changing env without rebuilding

This is the one that wastes the most time. From the Vite docs, import.meta.env values are "statically replaced at build time." The live JS already contains the old string (or undefined):

const supabaseUrl = import.meta.env.VITE_SUPABASE_URL;
// after `vite build` this is a string literal,
// or undefined, which turns into a broken request URL

So saving a new value in the Pages / Netlify UI and refreshing does nothing. Retry the production deployment (or push a commit) so the build runs again. Also, process.env.VITE_* in client code is the wrong API; Vite uses import.meta.env.

Quick check: search the built JS for your Supabase project ref. If it isn't there, the build never saw the var.

4. URL and key from different projects

Production has the URL from project A and the anon key from project B, or an old key after a rotation. The client "connects," but auth, rows and RLS belong to a different project. Names drift too: older templates read VITE_SUPABASE_ANON_KEY, current Lovable .env uses VITE_SUPABASE_PUBLISHABLE_KEY. If Production only has the old name, createClient gets undefined.

Checklist

Private window, live hostname, DevTools > Network: which host do /rest/v1 calls hit? Same as preview?
Host env, Production tab: VITE_SUPABASE_URL + publishable key, same project.
After any env change, rebuild. Don't just refresh.
Search the bundle for your project ref.
Every secret your functions read exists on the live host or in Supabase secrets.
Build failed? The log names the variable. Set it on Production, rebuild.

VITE_SUPABASE_URL=https://YOUR_PROJECT.supabase.co
VITE_SUPABASE_PUBLISHABLE_KEY=eyJ...   # anon/publishable, never service_role

If deploy is fine but login breaks on the live domain, that's the redirect allowlists, not env: the 3 redirect lists.

Full guide

Longer version with sources and an FAQ (Lovable Secrets vs VITE_, build failures, preview and production on different projects):

https://fixloop.dev/guides/lovable-preview-works-deploy-breaks

I run FixLoop. Still stuck? Paste the error and we'll email you the likely cause, free.

Stripe webhook 401 on Supabase Edge Functions: verify_jwt is blocking it

FixLoop — Mon, 19 Oct 2026 13:04:34 +0000

Checkout works. Stripe's dashboard shows the webhook failing with 401. Your Edge Function logs are empty for that timestamp. That combo is almost never your Stripe code. It's the Supabase JWT check running before your handler.

What it looks like

In Stripe Workbench, open the endpoint and look at a failed delivery. The response body comes from the platform, not from your return new Response(...):

{
  "code": 401,
  "message": "Missing authorization header"
}

Sometimes it's Invalid JWT instead. Same thing. Other tells:

No invocation in the function logs for that delivery.
The function works when you call it yourself with Authorization: Bearer <anon key>.
Local stripe listen + supabase functions serve --no-verify-jwt works, production 401s.

Why it happens

Every Edge Function request goes through two layers:

verify_jwt (on by default). The platform wants a Supabase JWT in Authorization. Missing or wrong means 401 and your code never runs.
Your handler. This is where Stripe's signature check belongs.

Stripe sends Stripe-Signature and a JSON body. It has no Supabase token, so layer 1 always rejects it. Supabase's own function config docs use a Stripe webhook as the example for turning this off.

Fix 1: turn off JWT verification for that one function

In supabase/config.toml (use the function's folder name):

[functions.stripe-webhook]
verify_jwt = false

Redeploy, or supabase functions deploy stripe-webhook --no-verify-jwt. You can also flip the toggle in the dashboard, but if Lovable redeploys the function, a dashboard-only toggle can come back on. Put it in config so it sticks. Leave JWT verification on for every user-facing function.

Fix 2: verify the signature on the raw body

Now anyone can POST to that URL, so the handler has to prove it's Stripe. Two gotchas on Deno:

Read the body with req.text() first. Stripe's docs: "Stripe requires the raw body of the request to perform signature verification." req.json() before verifying will break it.
Use constructEventAsync, not constructEvent. Deno's crypto is async.

import Stripe from "npm:stripe";

const stripe = new Stripe(Deno.env.get("STRIPE_SECRET_KEY")!);
const cryptoProvider = Stripe.createSubtleCryptoProvider();

Deno.serve(async (req) => {
  const signature = req.headers.get("Stripe-Signature") ?? "";
  const body = await req.text();

  let event;
  try {
    event = await stripe.webhooks.constructEventAsync(
      body,
      signature,
      Deno.env.get("STRIPE_WEBHOOK_SECRET")!,
      undefined,
      cryptoProvider
    );
  } catch (err) {
    console.error("Stripe signature verification failed:", err);
    return new Response("bad signature", { status: 400 });
  }

  // handle event.type, then acknowledge fast
  return new Response(JSON.stringify({ received: true }), {
    headers: { "Content-Type": "application/json" },
    status: 200,
  });
});

Return 400 on a bad signature (not 401, or you'll think the JWT bug is back) and 200 quickly once you've accepted the event.

The secret mix-up

Production deliveries are signed with the endpoint secret from Stripe Workbench (starts with whsec_).
stripe listen prints a different whsec_. Don't mix them.
Test mode and live mode each have their own.
Keep STRIPE_SECRET_KEY and STRIPE_WEBHOOK_SECRET in Edge Function secrets, never in VITE_ client env.

Checklist

401 body says Missing authorization header or Invalid JWT? JWT gate. Set verify_jwt = false on that function only.
req.text(), then constructEventAsync(...).
400 on bad signature, 200 when accepted.
Dashboard whsec_ in prod, CLI secret only with stripe listen.

Full guide

Longer version with source links and an FAQ ("does turning off verify_jwt make it public?", constructEvent vs constructEventAsync):

https://fixloop.dev/guides/stripe-webhook-401-supabase-edge-functions

If the webhook "succeeds" but the row never changes, that's usually RLS silently blocking the update, not Stripe. If it's login that broke after deploy, I wrote up the 3 redirect lists.

I run FixLoop. There's a free scan for leaked keys and missing headers, and we fix broken Lovable/Supabase apps for a fixed price. No fix, no pay.

Lovable login works in preview, breaks in production: the 3 redirect lists

FixLoop — Sun, 18 Oct 2026 17:04:15 +0000

Login works on the Lovable preview. You publish, or put a custom domain in front, and now sign-in loops, drops you on localhost:3000, or comes back with no session. The React didn't change. The host did.

Supabase Auth only sends the browser back to URLs it already trusts. Preview was on that list. Production wasn't.

What it looks like

Preview: Google / GitHub / magic link works. Production: spinner, then the login page again.
After OAuth you land on http://localhost:3000 or the old *.lovable.app preview host.
The address bar ends in #error=... or error_description=Unsupported%20redirect.
Google shows Error 400: redirect_uri_mismatch naming a URL you don't recognize.
Confirm / reset emails open the preview app, or 404 on the live domain.

Test in a private window on the live origin. Preview cookies will lie to you.

There are three lists, not one

Most people paste the production URL into one box and call it done.

Supabase Site URL (Authentication → URL Configuration). The default redirect when your code doesn't pass redirectTo. Magic links and password resets use it. A new project starts at http://localhost:3000.
Supabase Redirect URLs (same page). The allowlist. Every redirectTo must match it, or Auth quietly ignores it and uses Site URL. That's how you "set production" and still bounce to localhost.
The OAuth provider's Authorized redirect URI (Google Cloud, GitHub). This is not your app. It's Supabase's callback, https://YOUR_PROJECT.supabase.co/auth/v1/callback. Publishing the Lovable app doesn't change it. Getting it wrong gives redirect_uri_mismatch at the provider, which looks like a Lovable bug.

On a connected Supabase project, the first two live in the Supabase dashboard, not the Lovable chat. (Lovable Cloud, the built-in backend, is configured in Lovable instead.)

The fix

Site URL = the live origin, e.g. https://myapp.com (or your *.lovable.app host if that's what's published). Leave preview out of it, since it's the default for emails.

Redirect URLs: add every origin you actually use. ** matches across /:

https://myapp.com/**
https://myapp.com/auth/callback
https://*.lovable.app/**
http://localhost:5173/**

Whatever path your code passes as redirectTo must be covered. A trailing-slash mismatch is enough to fall back to Site URL.

Provider console (Google / GitHub): JavaScript origins get your app's origin. Authorized redirect URIs get the Supabase callback copied from Authentication → Providers. Don't put https://myapp.com/auth/callback there: Google returns to Supabase, and Supabase returns to your app.

redirectTo in code: hardcoding the preview host is how production "randomly" returns to preview. Use the current origin:

const redirectTo = `${window.location.origin}/auth/callback`;

const { error } = await supabase.auth.signInWithOAuth({
  provider: "google",
  options: { redirectTo },
});

Same for resetPasswordForEmail and signInWithOtp. If you customized email templates, {{ .SiteURL }} always points at Site URL; use {{ .RedirectTo }} when the link should follow what you passed.

60-second checklist

Private window, live hostname.
Site URL is production, not localhost or only the preview host.
Redirect URLs cover production (plus /auth/callback if you use it); preview can stay as a wildcard.
Provider redirect URI is https://YOUR_PROJECT.supabase.co/auth/v1/callback.
redirectTo is built from window.location.origin.
Read the error / error_description in the URL fragment on the landing page. Auth still redirects on failure; the reason is in the hash.

Full guide

The longer version with source links and an FAQ (Site URL vs Redirect URLs, "I set Site URL, why localhost?", Lovable vs Supabase settings) is here:

https://fixloop.dev/guides/lovable-login-preview-vs-production

If sessions exist but saves silently do nothing, that's RLS, not redirects. I wrote up a 5-minute check for that.

I run FixLoop. There's a free scan for leaked keys and missing headers, and we fix broken Lovable/Supabase apps for a fixed price. No fix, no pay.

Is my Supabase database public? A 5-minute check with the anon key

FixLoop — Sat, 17 Oct 2026 20:09:09 +0000

If you shipped a Lovable (or any Supabase) app, your anon key is in the browser. That's fine, it's supposed to be. The real question is different: can a stranger read your tables with that key and no login?

If Row Level Security is off on a table that still has grants to anon, the answer is yes. Here's a 5-minute check you can run on your own project.

Why the anon key isn't the leak

The anon key is a public JWT. Postgres then decides what it can do in two layers:

Grants decide whether anon can SELECT / INSERT / UPDATE / DELETE the table at all.
RLS decides which rows survive that grant.

RLS off means the second layer never runs. If anon also has a grant (the old default on public tables), every row is reachable from the REST endpoint. A policy of using (true) is the same hole with RLS "on": the dashboard badge looks fine, the table is still public.

The check

Open your live app in a private window, DevTools → Network, filter rest/v1. Grab the project host (abcdefghij.supabase.co), a table name from the path, and the apikey header from a signed-out request. Never use the service_role key for this (or anywhere in the client).

curl "https://YOUR_PROJECT.supabase.co/rest/v1/YOUR_TABLE?select=*&limit=5" \
  -H "apikey: YOUR_ANON_KEY" \
  -H "Authorization: Bearer YOUR_ANON_KEY"

No cookies, no session. If this returns user data, anyone can do it too.

Reading the result

200 + rows: anon can read the table. RLS is off or a policy allows anonymous SELECT. Fix this first.
200 + []: there's a SELECT grant but no rows passed RLS (or the table is empty). Retry on a table you know has data. If the signed-in app shows rows and anon still gets [], you're probably fine.
401: bad or truncated key. This does not mean the table is private.
403 / 42501: anon has no grant, so the request never reaches RLS. After Oct 30, 2026 this shows up a lot on new tables (why).
404 / PGRST205: wrong table name. Use the one from the network tab.

The safe fix

Turn RLS on and scope policies to auth.uid(). Don't "fix" an open table by granting more.

alter table public.your_table enable row level security;

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

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

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

Don't do any of these:

GRANT ALL ON ALL TABLES IN SCHEMA public TO anon;
any grant to anon while RLS is off
using (true) on a table with private rows
the service_role key in frontend env

In Lovable, put the same rules in your project instructions so the next migration doesn't recreate the hole.

Full guide

The longer version with the browser-console variant, a checklist, and an FAQ (should I rotate the anon key? Lovable says RLS is on, can it still be public?) is here:

https://fixloop.dev/guides/is-my-supabase-database-public

I run FixLoop. There's a free scan for leaked keys and missing headers, and we fix broken Lovable/Supabase apps for a fixed price. No fix, no pay.

Supabase Oct 30: why new tables get 42501 (and how to fix grants + RLS)

FixLoop — Sat, 17 Oct 2026 17:14:20 +0000

If you just created a table in Lovable, turned on RLS, wrote policies, and the app still returns permission denied for table, this is the one.

Starting October 30, 2026, existing Supabase projects stop auto-granting privileges on new tables in the public schema. The table is there. The policies are there. The Data API still cannot see it.

Source: Supabase changelog · Securing your API

What it looks like

The request fails with Postgres error 42501. PostgREST (the Data API behind supabase-js) sends something like:

{
 "code": "42501",
 "message": "permission denied for table your_table",
 "hint": "Grant the required privileges to the current role with: GRANT SELECT ON public.your_table TO anon;"
}

Typical setup: a Lovable-created table, RLS enabled, policies that should allow the row, and it still fails. Old tables keep working. Only the new one fails.

The hint names the missing grant. It is not a recommendation to copy blindly. Read it, then grant only what that role should have.

Grants vs RLS

Postgres runs two checks, in order:

Grants decide whether a role can touch the table at all (SELECT, INSERT, UPDATE, DELETE).
Row Level Security decides which rows that role can see or change.

If the grant is missing, RLS never runs. That is why "I have policies" does not fix 42501.

Until now, a new table in public automatically received select/insert/update/delete for anon, authenticated, and service_role. RLS was the only gate. New projects already dropped that default. On October 30 it applies to every existing project too.

Existing tables keep their grants. Direct Postgres connections are not affected. This is a Data API change: REST, GraphQL, and the client libraries.

The fix

Put grants in the same migration as the table, RLS, and policies. Least privilege, not GRANT ALL.

alter table public.your_table enable row level security;

-- signed-in users: the operations your app actually uses
grant select, insert, update, delete on table public.your_table to authenticated;

-- server code / Edge Functions using the service_role key
grant select, insert, update, delete on table public.your_table to service_role;

-- only if signed-out visitors should read this table
-- grant select on table public.your_table to anon;

Leave anon with nothing unless the table is meant to be public. Skip GRANT ALL ON ALL TABLES IN SCHEMA public - that also opens tables where RLS was never turned on.

If you already see 42501, check who has what:

select grantee, privilege_type
from information_schema.role_table_grants
where table_schema = 'public'
 and table_name = 'your_table';

Tell Lovable to include grants

Paste this into project instructions / Knowledge before the next migration:

When you create or change a Supabase table, put all of this in the same migration: CREATE TABLE, ENABLE ROW LEVEL SECURITY, CREATE POLICY, GRANT to authenticated and service_role, and GRANT SELECT to anon only if signed-out users should read it. Do not use GRANT ALL. Do not skip grants because RLS is on.

Full checklist + FAQ

The longer version with the Lovable paste block, checklist, and FAQ lives here (canonical):

https://fixloop.dev/guides/supabase-oct-30-grants-change

I run FixLoop - we fix broken Lovable/Supabase apps for a fixed price. No fix, no pay.

DEV Community: FixLoop

Lovable custom domain stuck on Verifying? It is almost always one of five DNS or auth settings

The records Lovable expects

Stuck on "Verifying" or "Unable to verify"

If login breaks on the new domain

Free tool: find Supabase tables that will 42501 after Oct 30

The fix, if you just want the SQL

The checker

Tell your AI builder

Supabase "Email address not authorized": why users never get your signup email

The limits of the default service

The fix: bring your own SMTP

Don't "fix" it by turning off confirmation

Still not arriving?

Supabase select returns [] with no error: 5 RLS causes

1. RLS on, no SELECT policy

2. Policy targets the wrong role

3. auth.uid() is null

4. The rows belong to someone else

5. Policy checks the wrong column

Confirm it in two minutes

Full guide

Lovable app not deploying or broken after deploy: 4 env causes

What it looks like

1. VITE_ vars set on Preview, not Production

2. Secrets that never left Lovable

3. Changing env without rebuilding

4. URL and key from different projects

Checklist

Full guide

Stripe webhook 401 on Supabase Edge Functions: verify_jwt is blocking it

What it looks like

Why it happens

Fix 1: turn off JWT verification for that one function

Fix 2: verify the signature on the raw body

The secret mix-up

Checklist

Full guide

Lovable login works in preview, breaks in production: the 3 redirect lists

What it looks like

There are three lists, not one

The fix

60-second checklist

Full guide

Is my Supabase database public? A 5-minute check with the anon key

Why the anon key isn't the leak

The check

Reading the result

The safe fix

Full guide

Supabase Oct 30: why new tables get 42501 (and how to fix grants + RLS)

What it looks like

Grants vs RLS

The fix

Tell Lovable to include grants

Full checklist + FAQ

3. `auth.uid()` is null

1. `VITE_` vars set on Preview, not Production