Every new Lovable project gets Lovable Cloud by default, and Cloud is Supabase underneath. So "Lovable Supabase" means two different things depending on who's asking. Most people mean the integration: you connect a Supabase project that you own, Supabase bills you, and Lovable builds against it. That is the setup this post is about, because it's the one we put clients on when an app is going to have real users.
If your app already runs on Cloud and you want out, skip to the end. That is a different job.
Connecting it takes two people (sometimes)
The docs split the connection into two steps, and they're split for a reason.
First, someone links a Supabase organization to the Lovable workspace. Only workspace owners and admins can do that. You'll find it on the Connectors page, or under More, then Cloud, inside a project. Once an org is linked, everyone in the workspace can see its projects, even people with no Supabase account of their own.
Second, anyone with edit access connects a Lovable project to one Supabase project from that org. In the Cloud view it's the "Already have a Supabase project? Connect it here" link, then Connect next to the project you want.
This is where agencies and freelancers get stuck. A founder invites a developer as an editor, the developer goes to connect Supabase, and the "Add Organization" button is greyed out. Nothing is broken. The founder has to do step one, or make the developer an admin. We've had a call stall for twenty minutes on exactly that.
Do it at the start if you can. Connecting your own project to a brand new Lovable app is ten minutes. Lovable has no one-click migration between Cloud and your own Supabase, in either direction, so choosing late costs real work.
What Lovable does once it's connected
Pretty much what it does on Cloud, but in your project, where you can see it.
Schema changes come up in chat as SQL and only run when you approve them. Each one is saved as a file under supabase/migrations/ in the repo, and the TypeScript types get regenerated. I like this more than the Cloud flow. You end up with a real migration history in Git, and any developer can read it and replay it on a staging project with the Supabase CLI. Data inserts and updates also need your approval, which is slower but has saved at least one client from a "clean up the test users" prompt that matched real users too.
Edge functions get written and deployed straight to your project. Lovable reads their logs when something fails, and you can watch them yourself under Edge Functions in the Supabase dashboard. Secrets go in through a masked input, get stored in your project, and Lovable never reads the values back or puts them in code. That's fine. Just know where they live: Supabase dashboard, Edge Functions, Secrets. Not in Lovable.
Auth is wired to Supabase Auth for email and password. Social logins you turn on yourself in the Supabase dashboard under Authentication, and then Lovable adds the button.
Lovable also runs its security checks after schema changes, including RLS coverage. Don't treat that as a sign-off. The docs themselves tell you to check every table's policies in the Supabase dashboard before going live, and missing policies are still the most common hole we find in audits. A table with RLS enabled and a using (true) select policy passes a lot of automated checks.
The bits that stay on Cloud
This list is in the docs but people skim past it. With your own Supabase connected, these Lovable features don't apply:
- the in-editor Database, Users, Storage, Secrets, Jobs, Usage and Logs views (you use the Supabase dashboard instead)
- managed backups and instance resizing
- auth emails sent by Cloud
- managed Google sign-in and SAML SSO
- signed-in browser testing, and PII scanning of your data
- built-in payments on older React + Vite apps
Two of those cause real problems.
Email. On Cloud, signup confirmations and password resets just arrive. On your own Supabase they go through Supabase's default SMTP, and that server is a toy: 2 messages an hour, and it refuses to send to any address that isn't on your Supabase team. So it works perfectly while you test with your own email, then your first real user never gets a confirmation link. Set up custom SMTP (Resend, Postmark, SES, whatever you like) under Authentication before launch. It's fifteen minutes of work and the most common "nobody can sign up" ticket we see.
Google sign-in. Cloud's managed Google login has no equivalent here. You create an OAuth client in Google Cloud Console, paste the client ID and secret into the Supabase Google provider, and add the Supabase callback URL to the client. Then publish the consent screen. If it's left in Testing, only the test users you listed can log in, and everyone else gets an "access blocked" page that looks like your app is broken.
Don't share one Supabase project between two Lovable projects
The docs warn about this and I'll repeat it louder. If two Lovable projects connect to the same Supabase project, they overwrite each other's secrets, including LOVABLE_API_KEY.
A founder we worked with remixed their app to make a "staging" copy and connected the remix to the same Supabase project as production. Felt sensible, same data, quick to test. The remix wrote its own LOVABLE_API_KEY over the production one, and the production app's AI summary feature started failing with 401s the next morning. Nothing in the production project had changed. It took a while to find, because who looks at a staging remix when prod breaks?
Staging gets its own Supabase project. Free tier is fine for that.
Disconnecting is gentler than it sounds
Disconnect in the Cloud view and Lovable just stops deploying edge functions and reading your schema. Your code stays in the repo and your data stays in Supabase. You can reconnect later. One gotcha: supabase/config.toml keeps the project ref from whichever project the code was last linked to. If you point the app at a different project, check that file, or the CLI deploys to the old one.
Already on Lovable Cloud?
Then connecting a Supabase project isn't a switch you flip, so check first whether it saves you anything: the free Lovable cost check compares your current bill with the same app on your own Supabase. You have to move the data, users, files, functions and secrets out of a project you don't own, and the export doesn't take all of that with it. The Cloud to Supabase migration checklist shows what breaks, and we do the move as a fixed-scope job, see Lovable Cloud to Supabase migration. If you're starting fresh and want it set up properly from day one (SMTP, Google OAuth, RLS, staging), tell us about the app.
Originally published on lovable2live.com. Aakash Verma, software developer and founder of Lovable 2 Live.
Top comments (0)