How to Migrate from Lovable Cloud to Supabase

What is a Lovable migration?

A Lovable migration means moving the backend of an app you built with Lovable (its database, users, files and functions) out of the managed Lovable Cloud environment and into a Supabase project you own. Your app's code stays the same. After the migration the app talks to your Supabase project instead.

People search for this in many ways: migrate from Lovable, migrate Lovable to Supabase, move a Lovable app to your own hosting, or export a Lovable app. They all describe the same job, and the steps below cover it end to end. If you only want the code, see how to export your Lovable project.

Why migrate from Lovable Cloud to your own Supabase project

Lovable Cloud is convenient because it hides the backend. That convenience has trade-offs that start to matter once an app has real users.

• Ownership. Your own Supabase project sits under your account, billing and access controls. You decide who can see the data and when to export it.
• Direct database access. You get the full Supabase dashboard: SQL editor, table editor, logs, backups and connection strings for external tools.
• Scaling and limits. You choose the compute size, region and plan, and you can upgrade when traffic grows instead of waiting on a platform limit.
• Cost control. Supabase pricing is published and predictable, so you can compare it with what you pay today. Check supabase.com/pricing for current numbers.
• Portability. A standard Supabase project can be self-hosted later, which makes it far easier to leave any single vendor.

What you need before you start

Migration only copies data into the new project. Your Lovable Cloud backend is not modified, so you can retry as many times as you need.

• A Lovable project connected to GitHub (see how to sync your Lovable project to GitHub).
• A free Supabase account. Sign up at supabase.com with GitHub or email.
• CSV exports of your tables and, if you have users, one CSV of your auth users.
• Your storage files downloaded to your computer, if your app uses uploads.
• About 30 minutes, and a rule: never delete anything in Lovable Cloud until you have tested the new project.

Migrate Lovable Cloud to Supabase in 3 stages

Every migration, manual or automated, boils down to the same three stages. Knowing them first makes the detailed steps below easier to follow.

1. 1Connect

   Give the tool (or yourself) access to your GitHub repository and your new Supabase project. The migrator uses the official OAuth sign-in for both, and only reads from GitHub.

2. 2Upload

   Provide the pieces Lovable does not hand over automatically: CSV exports of each table, a CSV of your auth users, and your storage files.

3. 3Migrate

   Run the migration. The schema is replayed in order, rows are inserted parents-first, users keep their ids and password hashes, and files keep their folder paths.

Step 1: Sync your Lovable project to GitHub

Your database structure lives in your code as SQL migration files inside supabase/migrations. To get those files you need your project in GitHub. In Lovable, use the GitHub connection in the project settings, approve the app, and choose to create a repository.

Once the repository exists, open it on github.com and use Code → Download ZIP, or clone it with git. Read the full walkthrough in our GitHub sync guide. The Lovable documentation at docs.lovable.dev describes the GitHub integration in more detail.

Step 2: Create your Supabase project

4. 4Create an account

   Go to supabase.com and sign up. Continuing with GitHub is the fastest option.

   

5. 5Create a new project

   Click New project, choose a name, pick a region close to your users, and save the database password in a password manager.

   

6. 6Wait for it to be healthy

   Provisioning takes a minute or two. When the project overview shows the status Healthy, it is ready.

   

Step 3: Move the database schema and RLS policies

The schema is the set of tables, functions, triggers and Row Level Security (RLS) policies. It is stored as timestamped SQL files, and the timestamp in each filename defines the order they must run in. Running them out of order is the most common cause of migration errors.

You have three ways to apply them. Pick one:

• The migrator tool. Upload the ZIP or connect GitHub, and it runs each file in order with live status and Retry, Skip or Stop on errors.
• The Supabase CLI. Link your project and push the files. See the Supabase CLI docs.
• The SQL editor. Open each file in the Supabase SQL editor and run them oldest first.

supabase login
supabase link --project-ref YOUR_PROJECT_REF
supabase db push

What if there is no migrations folder?

Some projects keep their structure only in the live database. In that case run a query in Lovable Cloud's SQL editor that rebuilds CREATE statements from the system catalogs, then run the result in Supabase. The migrator tool includes a ready-made query for this, and our export guide explains the approach and its limits.

Step 4: Export and import your table data

Table data is not stored in GitHub, so you export it separately. In Lovable, open the Cloud area, go to the database view, open each table and export it as CSV. Name each file after its table, for example profiles.csv, so it can be matched automatically.

Import order matters because of foreign keys. A child table such as comments cannot be loaded before the parent table posts it references. The tool reads the new database's foreign keys and sorts the tables for you. By hand, work from the tables nothing depends on outward.

Types need care when you import CSV: empty strings must become NULL, true and false must become booleans, and JSON and array columns must be parsed. The tool does this per column type and inserts in batches of 500 rows.

Step 5: Migrate your auth users and keep their passwords

Users live in the auth schema, which is not part of your migration files. Export them with this query in Lovable Cloud's SQL editor, then save the result as CSV.

To keep logins working you must insert users into auth.users with the same id and the same bcrypt encrypted_password, and add a matching auth.identities row for email sign-in. Keeping ids identical matters just as much: it keeps your data tables pointing at the right person. The full explanation is in Migrate Lovable Cloud users to Supabase.

select id, email, encrypted_password, email_confirmed_at,
       raw_user_meta_data, raw_app_meta_data, created_at
from auth.users
order by created_at;

Step 6: Move your storage files

Create each bucket in Supabase with the same name and the same public or private setting, then upload the files keeping the same folder paths. Existing URLs and database columns that store file paths then keep working. See Move Lovable Cloud storage files to Supabase for details and size limits.

Step 7: Deploy your edge functions and secrets

Functions are code, so they are deployed rather than copied. With the Supabase CLI, link your project and run supabase functions deploy for each function folder in supabase/functions.

Secret values are never exported. Search each function for Deno.env.get( to list the names it needs, then set them again with supabase secrets set. The edge functions guide has the exact commands.

Step 8: Point your app at the new project

Update three values in your .env file (VITE_SUPABASE_URL, VITE_SUPABASE_PUBLISHABLE_KEY, VITE_SUPABASE_PROJECT_ID) and the project_id in supabase/config.toml. Redeploy the front end. The environment guide covers this and how to test it safely.

Move from Lovable Cloud to Supabase: what changes technically

Understanding what actually changes makes the migration less intimidating. Your app code does not change: it talks to Supabase through the same client library, using a project URL and a publishable key. What changes is the project those values point to, and everything that project contains.

Your database is the first thing that changes owner. In Lovable Cloud the Postgres instance is created and operated for you. In your own Supabase project you control it: you pick the region and compute size, you can see logs and query performance, and you decide how backups are handled. The tables, columns, indexes and policies are the same, because they come from the same migration files.

Authentication is the second. Users are stored in the auth schema, with their ids, emails and password hashes. When you migrate, the same rows are created in the new project. Sessions issued by the old project are not valid in the new one, so signed-in users will be asked to sign in once more. OAuth providers such as Google must be configured again in the new project, with your own OAuth client credentials and the new callback URL that Supabase shows you.

Storage and functions are the third and fourth. Files live in buckets with policies on storage.objects, and functions run on the Supabase Edge Functions runtime with their own secrets. None of these is stored in your table data, which is why each needs its own step.

Plan a safe cutover with no surprises

The safest way to migrate is to treat it as a rehearsal first and a cutover second. Because the migration only reads from Lovable Cloud, you can run it into a fresh Supabase project as many times as you like without any effect on live users.

• Rehearse on a throwaway project. Create a second Supabase project, run the whole migration, and fix every error while nobody is affected. Delete it when you are done.
• Pick a quiet moment for the real run. New rows written to Lovable Cloud after you export your CSV files will not be in the new project, so migrate when traffic is low, or pause writes briefly.
• Do a final delta export. If your app keeps writing during the rehearsal, export again right before the cutover and import the new rows only.
• Switch the environment variables last. Only after the new project has been tested end to end do you change the three values in your .env and redeploy.
• Keep the old backend for a while. Do not delete anything in Lovable Cloud until the new project has run cleanly for a few days. Rolling back is just restoring the old values.

Security checklist after you migrate

A new project is also a chance to start clean. Spend ten minutes on these checks before you announce the switch.

• Rotate anything that was shared. Delete the personal access token or OAuth authorization you used for the migration, and generate fresh API keys if you pasted any key into a tool.
• Keep the service role key secret. It bypasses Row Level Security. It belongs in server-side code and edge function secrets only, never in your front-end .env.
• Confirm Row Level Security is on. Every table in the public schema that holds user data should have RLS enabled with at least one policy. A table with RLS enabled and no policies denies all access, which is safe but will look like missing data.
• Test as a real user. Request data while signed in as an ordinary account and while signed out. The service role hides policy mistakes, so only an ordinary account tells you the truth.
• Review Auth settings. Set the Site URL and redirect URLs to your real domain, decide whether email confirmation is required, and review password rules.
• Turn on backups. Check the backup options for your Supabase plan and, for important data, schedule your own exports as well.

Costs and sizing your new Supabase project

Most small Lovable apps run comfortably on a small Supabase compute size. The things that grow your bill are database size, file storage, bandwidth and, for busy apps, compute. Look at the number of rows and the size of your uploaded files before you choose a plan, and compare them with the limits on the Supabase pricing page.

A practical approach is to start on the smallest plan that fits your data, watch the usage graphs in the dashboard for a week, and only then change the plan. Because you own the project, you can scale up in minutes when you need to, and you can see exactly what you are paying for.

After the migration: backups, monitoring and next steps

Once you are live, a few habits keep a self-managed backend healthy. Use the Supabase dashboard to watch database size and API errors. Keep your migration files in Git, and create every future schema change as a new timestamped file, so staging and production never drift apart. If you work with a team, add collaborators to the Supabase organization instead of sharing logins.

Finally, keep your CSV exports and your migration report somewhere safe for a while. They are your proof of what was moved, and a quick way to compare row counts if anything ever looks wrong.

Verification checklist

• Row counts per table match between Lovable Cloud and Supabase.
• You can log in with an existing account and the password still works.
• Row Level Security policies exist and a logged-out request cannot read private tables.
• Images and files load from their original paths.
• Each edge function responds and its secrets are set.
• Google or other social providers are re-enabled in the Supabase Auth settings.

Common problems and how to avoid them

Most failures come from five causes: migrations run out of order, child rows imported before parents, empty strings in non-text columns, missing secrets, and RLS blocking an import. Every one of them is covered, with fixes, in Lovable to Supabase migration errors and how to fix them.

How long does it take and what does it cost?

A small app finishes in about 20 minutes. Large tables take longer because rows are inserted in batches. The migrator is free. Supabase has a free tier, and bigger projects may need a paid plan; check Supabase pricing before you commit.

Frequently asked questions

Related guides