Lovable put a .env file in my GitHub repo. Is my Supabase key leaked?

You open your project on GitHub and see a file called .env. Inside is your Supabase address and a long key. Every guide says never commit a .env file. Is your app leaking?

Usually not. My own checker made this exact mistake. Its first version raised its loudest alarm on this file in three of six apps, and it was wrong all three times.

What is in the file

In the apps I looked at, the file held the project address, a key named VITE_SUPABASE_PUBLISHABLE_KEY or VITE_SUPABASE_ANON_KEY, and one more public setting such as the project id.

Two things make these harmless to publish.

• The VITE_ prefix. The build tool copies every value with that prefix into the code that runs in the browser. Anyone who visits your app already has it.
• The kind of key. Supabase has public keys and secret keys. The publishable key is the public kind, and Supabase's own guide calls it safe to expose online. The older anon key is the earlier version of the same thing.

So the file tells the world nothing your website does not already tell it.

The condition that matters

The public key is safe only if your database rules are in place. It opens the door to the database, and Row Level Security decides what the visitor can do once inside. With a table that has no rules, that public key is usually enough to read and change the table.

That is the real question. It is not "is my key visible". It is "what can someone do with it".

Which key is the dangerous one

• New style: a key starting with sb_secret_ is secret. One starting with sb_publishable_ is public.
• Old style: both keys are long strings starting with eyJ. In the Supabase dashboard one is labelled anon and the other service_role. The service_role key is the secret one.

A secret key skips every rule you have. It belongs on a server only. It is a real leak if it appears in any of these places:

1. In the .env file in your repository.
2. In any variable whose name starts with VITE_, even if the file is not committed.
3. In an older commit. Deleting a file does not remove it from the history.

The same goes for keys of other paid services, such as an AI provider or an email service.

If the secret key was exposed

Deleting it is not enough. First take it out of the code, so the new key does not leak the same way. Then create a new key in the Supabase dashboard, switch your server to it, and turn the old one off. Supabase calls this rotating the key.

The two-minute check

Run this in the Supabase SQL editor. It only reads.

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

Any table with rowsecurity = false has no rules at all. That matters far more than the .env file.

One more thing to know: Supabase says it is deprecating the older anon and service_role keys by the end of 2026, so a move to the new keys is coming either way.

If you want your app checked

I read your repository and its history for a fixed list of problems, including secret keys in the code and tables without rules, and report each with its file and line. It is an option with the scan on my Upwork listing. The scan costs $95, and the security check adds one day and $50. That is an opening price for the first five clients. After that it is $150. An empty report does not mean the app is secure.