On October 8, 2026, Lovable gave Free and Pro plans a way to stop publishing to the whole internet. Its changelog entry is short: pick Invite only in the publish dialog, add people by name or email, and "only the people you add can visit the published app, after logging in."
That's a real lock. The question is what it's attached to. Lovable's publishing docs describe website access as controlling who can visit "the published app at its live URL." Your app's database doesn't live at that URL. It sits at its own supabase.co address, and the browser talks to it directly.
TL;DR
Invite only (Free and Pro, since October 8, 2026) controls who can load your published Lovable app. Lovable's docs never say it restricts direct requests to your Cloud database, and your app ships the database's URL and publishable key in its JavaScript by design. Anyone who has those two values can query your database and sign-up API directly, so Row Level Security and your sign-up setting are still what keep data private. Run the check below before you treat an invite-only app as private.
What Invite only actually does
Here's the setting as Lovable documents it, as of 2026-10-13:
| Public | Invite only | |
|---|---|---|
| Plans | All | Free and Pro (Business and Enterprise use Workspace or Custom) |
| Default | Yes | No, you have to choose it |
| Who can open the published URL | Anyone with the link | People you add, after logging in to Lovable, plus the project owner, workspace owners and anyone the project is shared with directly |
| What invitees need | Nothing | A Lovable account under the invited email (they can create one) |
| How long access lasts | n/a | Invites don't expire until you remove the person and publish |
Two details matter for what follows. Audience changes only take effect when you click Publish (or Publish changes). And Lovable's docs treat project access and website access as independent settings: one decides who can edit, the other who can visit.
Why your database isn't behind that gate
Your Lovable app lives at two addresses. The pages and JavaScript are served from your lovable.app URL (or custom domain). The database and login run in Lovable Cloud, which Lovable's own payments docs show at https://<ref>.supabase.co.
One nuance for newer projects. Apps built on TanStack Start (Lovable's default for new projects since May 2026) can also run server functions and API routes on the app's own host, and Lovable's docs treat code there as reachable only after sign-in when the site isn't public. That code may well sit behind the gate. The database address doesn't.
The app finds that database because two values are baked into it. Lovable's secrets docs say it plainly: VITE_SUPABASE_URL and VITE_SUPABASE_PUBLISHABLE_KEY "are embedded into the client bundle at build time and are safe to be public." The same page tells you not to gitignore .env, because Lovable needs it committed to build your app.
"Safe to be public" is true, with a condition. Supabase's API keys guide says the publishable key "only reaches what Row Level Security allows." So the key is fine to leak exactly to the extent your RLS policies are right. Invite only doesn't enter into it.
Nothing in Lovable's documentation says Invite only restricts direct requests to your Cloud database. We searched the full docs on 2026-10-13. Website access is described in terms of the published URL every time. Until Lovable says otherwise, assume anyone holding your Supabase URL and publishable key can query your database directly, whether or not they can open your site.
Who already has your key
If you just switched from Public to Invite only, the list is longer than "the people I invited":
- Everyone who loaded the app while it was Public. The key was in the JavaScript they downloaded. Switching the audience changes who can load new pages; it doesn't change a key that's already out.
- Every invitee. They have to open the app to use it, so they get the bundle and the key.
- Anyone with your Git repo. Lovable's Git sync docs say the repo's
.envcarries the Cloud backend URL and publishable key, and a copy of the code using that config "reads and writes the same backend as your published app." If the repo is public, so is the key. - Anyone with a preview link. Lovable's sharing docs say anyone with a preview link can open the in-progress version without a Lovable account, and its preview docs say the preview and your published app share the same backend and data. On Free and Pro, preview links expire after 7 days. (Lovable documents preview links as bypassing its workspace-level default website access setting; it doesn't address Invite only directly, but a preview link isn't the published URL.)
None of that is a bug. It's how a Supabase app is meant to work. It just means Invite only can't be your data's only lock.
The 5-minute check
You need your app open (as yourself, or any invitee) and a terminal.
Find the two values. Open your published app, open DevTools (F12), go to the Network tab and reload. Click any request to an address ending in .supabase.co. Note the host (your project URL) and the apikey request header (your publishable key). You can also read both from .env in Lovable's code editor.
Ask for a table as a stranger. From a terminal that isn't logged in to anything, request a table your app uses. Swap in your values and a real table name:
curl "https://YOUR-REF.supabase.co/rest/v1/YOUR_TABLE?select=*&limit=5" \
-H "apikey: YOUR_PUBLISHABLE_KEY"
An empty list [] or a permission error means anonymous callers can't read that table. Rows coming back means anyone with the key can read them, Invite only or not. Repeat for every table that holds anything personal.
Check whether a stranger can just sign up. Many RLS policies say "any logged-in user can read this." That's only private if strangers can't create a login. In Lovable, open More → Cloud → Users → Auth settings and look for Disable sign-up. Lovable's authentication docs say turning it on stops new sign-ups while you can still add users yourself with Add user. If your app is for a fixed group of people, that's the setting that matches Invite only.
Run Lovable's own scan. Lovable's publish dialog runs a Quick scan that checks RLS policy mistakes, and its docs say findings don't block publishing by default. Open the Security view and read what it found. The optional Deep scan looks for authorization gaps too.
An invite-only app can't be scanned from the outside by anyone, including our scanner, because the pages sit behind a Lovable login. Step 2 doesn't need the pages. It goes straight to the database, which is exactly the part that stayed reachable.
If rows came back
Don't panic, and don't switch back to Public. Fix the policy:
- For data only its owner should see, the policy should compare the row's owner column to
auth.uid(). Our guide to adding RLS to a Lovable app walks through it step by step. - For an internal tool used by a known group, turn on Disable sign-up, add your people with Add user, and then make sure policies require a signed-in user. With sign-up off, "signed in" actually means "someone you added."
- Re-run step 2 after every change. The curl result is the ground truth; a policy that looks right in the editor isn't.
If you're on Business or Enterprise and building for teammates, Lovable also offers workspace identity reuse, which passes the logged-in Lovable user to your backend. Note its own caveat: people who can only view the published app get no identity, so it doesn't cover external invitees.
Can I make my Lovable app private on the free plan?
Yes, since October 8, 2026. In the publish dialog, open Who can view your site and pick Invite only. Only the people you add can visit the published app, after logging in with a Lovable account. The project owner, workspace owners and anyone the project is shared with directly can always open it. Public is still the default.
Does Lovable Invite only protect my database?
Lovable's docs describe it as controlling who can visit the published app at its live URL, and they never say it restricts direct requests to your Cloud database. The browser talks to the database at its own supabase.co address with a publishable key that's built into the app. Row Level Security and your sign-up setting decide what someone holding that key can do, so check both.
Is the Supabase key in my Lovable app a secret?
No. Lovable's docs say VITE_SUPABASE_URL and VITE_SUPABASE_PUBLISHABLE_KEY are embedded into the client bundle at build time and are safe to be public. Supabase's docs say the publishable key only reaches what Row Level Security allows. That's safe only if your RLS policies are right.
Do people I invite need a Lovable account?
Yes. Invited people log in with the email address you invited. If they don't have a Lovable account, they create one with that address. Invites don't expire, and removing someone from the audience revokes their access when you publish the change.
Can people still see my Lovable app through a preview link?
Lovable's docs say anyone with a preview link can open the in-progress version without a Lovable account, and that the preview shares your published app's backend and data. A preview link isn't your published URL, so Invite only isn't what governs it. On Free and Pro, preview links expire after 7 days. Check which links you've shared.
Want a second opinion on your Lovable app?
Scan your app's URL for exposed keys, open files, missing headers and TLS issues. No signup needed to see your first results.