How to connect Supabase to Lovable app step by step: login, tables, RLS and storage

Lovable's Supabase integration docs open with a question most tutorials skip: do you need Supabase at all? Lovable's answer is no for most people, because its built-in backend is enabled by default and "most projects never need a separate Supabase account." The integration exists for the case where you want the backend in your own name: your Supabase account and billing, the full Supabase dashboard, or a Supabase project you already run. If that is you, the procedure below is the full path, written for someone who does not write code, with the prompt to send and the check to run after each stage.

Every Lovable and Supabase step, limit and price on this page was checked against the vendors' own docs and pricing page on 26 October 2026.

Should you use Supabase or Lovable's built-in backend?

Lovable's built-in backend and your own Supabase project give your app the same building blocks, and the difference is who owns and manages them. The built-in backend docs say it "utilizes Supabase's open-source foundation", is billed in Lovable credits, and is managed from the Database, Users and Storage views inside Lovable. With your own Supabase project, Supabase bills you directly and you manage data, users, auth settings and backups in the Supabase dashboard.

Make the call before you write your first prompt. Lovable's integration page is explicit: "Switching between the two is not automatic." There is no automatic migration in either direction, so a project that starts on the built-in backend stays there unless you rebuild it.

Supabase's own pricing page sets what the free start looks like:

Supabase plan limit	Free	Pro
Price	$0 per month	From $25 per month
Monthly active users	50,000	100,000
Database	500 MB database size	8 GB disk size per project
File storage	1 GB	100 GB
Max file upload size	50 MB	500 GB
Active projects	Limit of 2 active projects	$10 per month in compute credits covers one project on Micro compute; additional projects add their full compute cost

The Free column is enough to build and test everything on this page. Its one trap for demos is on the same pricing page: "Free projects are paused after 1 week of inactivity." Open the project before a stakeholder demo, not during it.

What do you need before you connect Supabase to Lovable?

You need a Supabase account, a Supabase project (or an organization where you can create one), and a Lovable project that has no backend yet. Lovable's Supabase docs say the integration "is available on all plans", and that the Supabase free tier is enough to get started.

The third requirement is the one that catches people. Lovable's built-in backend permission, called Enable Cloud, defaults to Always allow, so the first time you ask for a login or a saved list, Lovable can switch on its own backend without asking. The External Supabase option in project settings only shows on a project without a backend: in the words of Lovable's docs, "The option appears on projects that don't have a backend yet." Connect Supabase first, before any prompt that stores data or signs users in. If you want a safety net, set Enable Cloud to Ask each time under Account settings, Preferences, Agent permissions, so Lovable has to ask before it creates a built-in backend.

How do you connect a Supabase project to Lovable, step by step?

Connecting is two actions, and Lovable's docs note they are often done by different people: a workspace owner or admin links a Supabase organization once, then anyone with edit access connects a project.

Step 1. Create the Supabase project. In the Supabase dashboard, create a new project in your organization and wait until it is active. You can also start from Lovable's connect dialog, whose Create Project button opens the Supabase dashboard for you.

Check: the project shows as active in Supabase. Lovable's troubleshooting notes say it cannot connect a project that is paused or still provisioning, and shows "Check project status in Supabase" instead.

Step 2. Link your Supabase organization to the Lovable workspace. A workspace owner or admin opens Connectors from the Lovable dashboard sidebar, selects Supabase and clicks Connect Supabase. A Supabase window opens to sign in and authorize Lovable for the organization you pick. Members of the workspace do not need their own Supabase accounts after this.

Check: the organization appears under Linked Supabase organizations. If the buttons are disabled for you, you are not an admin; ask one to do this step.

Step 3. Connect the Lovable project. For a new project, click + in the dashboard prompt box, open Databases and pick your project under the Supabase heading. For an existing project with no backend, open Settings → General → External Supabase, click Connect, click Continue, then click Connect next to your Supabase project.

Check: More → Supabase in the editor shows your Supabase project's name and status, with links to the Supabase dashboard. A warning icon next to a project in the list means another Lovable project already uses it.

How do you add email login once Supabase is connected?

Email login is a single prompt, because Lovable wires the sign-up and sign-in pages to Supabase Auth for you. Send the prompt Lovable's docs use:

Add email and password login, and require users to be signed in to access the dashboard.

Before you test, deal with email confirmation. Supabase's password auth docs say whether users must verify their email is configurable, and "On hosted Supabase projects, this is true by default." Lovable's docs suggest turning confirmation off in the Supabase dashboard's Authentication settings while testing, so test accounts can sign in immediately, and turning it back on before real users arrive.

Check: sign up with a test address in the Lovable preview, then open Authentication in the Supabase dashboard. The new user should be listed there. If the account is missing, the sign-up form is not reaching your project; fix that before building anything on top of it.

How do you create the first table from your app's data?

The first table should come from your product brief, not from a guess at a database design. Take the nouns your brief says the app stores and the fields each one needs, and describe them in plain language. If you do not have a brief yet, writing a PRD for vibe coding gives a one-screen format. For a client request tracker, the prompt reads:

Store client requests in the database. Each request has a title, a status (new, in progress or done), a due date and notes. Each request belongs to the signed-in user who created it. Show the signed-in user's requests on the dashboard, with a form to add one.

Lovable designs the table, then shows you the SQL migration and asks for approval in the project chat before running it. Read the column list in that message against your brief before you approve. After approval, Lovable runs the migration on your Supabase project and saves the file under supabase/migrations/ in your code.

Check: add two requests in the preview, then open the Table Editor in the Supabase dashboard. Both rows should be there, each carrying your user's id in the owner column.

How do you turn on row level security so each user sees only their own rows?

Row level security (RLS) is the database rule that decides which rows each signed-in user can read and change, and without it the table is open. Supabase's Row Level Security docs put it plainly: "A table in an exposed schema without RLS is readable and writable by any role with a grant on it."

Lovable's own warning before going live is shorter: "Missing RLS policies are the most common way app data gets exposed."

Send one prompt that covers every operation, because Supabase's procedure is a policy per operation plus grants trimmed to what each role needs:

Make sure users can only see and edit their own data. Enable row level security on every table, add separate policies for select, insert, update and delete that only match rows owned by the signed-in user, and remove any access signed-out visitors do not need.

Approve the migration Lovable shows you. Lovable also runs automated security checks after schema changes, including RLS coverage, and flags what it finds. Treat those flags as a prompt to look, not as proof the rules are right: Supabase's RLS guide says that until your policies are tested, "you don't know whether the policies do what you intended." The two-account test at the end of this page is that test for a non-developer. The vibe coding security checklist covers the rest of what to check before launch, including which keys may sit in the browser.

Check: in the Supabase dashboard, open the table and confirm RLS shows as enabled, with policies listed for each operation.

How do you add file storage to a Lovable app on Supabase?

File storage in Supabase lives in buckets, and each bucket is locked until a policy opens it. Supabase's storage access control docs state: "By default Storage does not allow any uploads to buckets without RLS policies." So the prompt has to say who may upload and who may read:

Let users attach one file to a request. Store files in a private bucket, and only let the user who uploaded a file view or delete it.

Lovable builds the upload logic and asks for approval before creating or changing buckets on your Supabase project. Lovable's docs say upload limits follow your Supabase plan, and on the free tier individual files are limited to 50 MB.

Check: attach a file to a request, then open Storage in the Supabase dashboard. The file should be in the new bucket, and the bucket should not be marked public.

How do you test the whole flow with two accounts?

A two-account test is the only check here that proves the security rules work, because every earlier check ran as one user who owns everything. Use two email addresses you control.

1. Sign in as account A, create two requests and attach a file to one of them.
2. Sign out, sign up as account B and open the dashboard. The list should be empty, and no file from account A should be reachable.
3. As account B, create one request. Sign back in as account A and confirm you still see only your two.
4. In the Supabase Table Editor, confirm all three rows exist with two different owner ids.

If account B sees account A's data, stop and fix the policy before anything else ships. The Lovable error loop guide covers how to prompt for that fix without stacking changes.

Then close the testing shortcuts. Turn email confirmation back on in Supabase. Before you do, set the Site URL to your published app's address: Supabase's redirect URL docs say the default is http://localhost:3000 and "This setting is critical for email confirmations and password resets."

When is connecting your own Supabase the wrong choice?

Your own Supabase project costs you some Lovable features, and Lovable's integration page lists them. The Database, Users, Storage, Secrets, Logs and Usage views inside Lovable are built for the built-in backend, so you work in the Supabase dashboard instead. Auth settings and social login providers are configured in Supabase rather than from the project chat. Lovable's signed-in browser testing works on the built-in backend only; with your own project it tests pages that do not require signing in. Backups, pausing and instance size become yours to manage in Supabase.

For a first prototype that only needs to work in a demo, that trade usually points to the built-in backend. Own the Supabase account when a team already runs Supabase, when billing has to sit outside Lovable, or when an engineer will take the backend over. Handing a Lovable project to Cursor covers what changes for each backend at that point, and building a prototype with Lovable covers the steps before the backend.

Where can you practise connecting Lovable to a real backend?

Builders Camp's Building with Lovable bootcamp takes you from idea to an interactive full-stack prototype using Lovable, connecting real backends, with no code required. It runs 2 weeks with 3 live sessions and 9 self-paced microlessons, is led by programme director Ricardo Luiz, and names Lovable, Supabase and GitHub as its tools. Its FAQ states that it is designed for non-technical professionals.

Before your next build, write the table list from your brief and decide which backend owns it. That one decision is the step you cannot undo later.