How to Migrate Off Lovable Cloud to Your Own Supabase

Why migrate off Lovable Cloud

For most of Lovable Cloud's life, the honest answer to "can I leave?" was: sort of. Your backend lived somewhere you could not fully reach, and every migration guide, this one included, was a collection of careful workarounds. The community kept asking for a real exit. In July 2026, Lovable built one: three official self-service actions under Cloud → Overview → Advanced settings.

• Export project data creates a full backup of your database: structure, data, security policies, and auth users. The limit is 5 GB and one export per day; for larger databases, Lovable asks you to write to support@lovable.dev with your project ID.
• Pause Cloud puts the instance to sleep so it stops consuming credits, and you can wake it up anytime. If your only concern is that an idle project burns credits, Pause solves that without any migration.
• Remove Lovable Cloud permanently deletes the Cloud instance. It cannot be undone.

Export project data, Pause Cloud, and Remove Lovable Cloud at the bottom of the Advanced settings page · click to enlarge

There is a paradox here: a real exit door is also a reason to relax. Your data is no longer stuck, so staying on Cloud becomes a choice instead of a default. Even if you never migrate, taking an export from time to time gives you a genuine off-platform backup of your database. That alone is worth the two clicks.

Removing Cloud is still not the same as migrating it. Lovable's documentation says there is no one-click move from the built-in backend to your own Supabase project: you export the Cloud data, prepare the destination, restore the backup, move the remaining backend pieces, verify the new system, and only then remove the old Cloud instance.

This guide focuses on that order of operations. Do not remove Lovable Cloud until your exports, destination, application configuration, and rollback plan have been tested.

How this guide works

This guide has three phases. Which ones you need depends on where you want to end up:

• Phase 1: Own your data sets up your own Supabase project and copies your database, users, files, functions, and secrets off Lovable Cloud, using Lovable's official export for the database. Your app keeps running on Cloud, untouched, while you do this. Everyone starts here.
• Phase 2: Own your hosting deploys your frontend to Vercel so your app no longer depends on Lovable's hosting layer. Do this phase if you want infrastructure fully under your control or plan to keep building with another AI tool. If you want to keep publishing through Lovable, skip it.
• Phase 3: Cut the cord removes the old Lovable Cloud instance and, if you are staying in Lovable, connects your own Supabase to the same project so you keep building exactly as before. Removal is permanent and does not move data for you, which is why it comes last.

At the end, there is an emergency playbook for when Lovable Cloud goes down. If you have already completed Phases 1 and 2, there is nothing to do. If you only completed Phase 1, you can have your app serving from your own hosting in about 20 minutes.

What travels with your code

When Lovable syncs to GitHub, your repository gets the full source code of your application. This includes:

• Frontend code: React components, pages, routing, styles. Everything the user sees.
• Schema migrations: The supabase/migrations/ folder contains SQL files that define your database structure, including table definitions, indexes, and RLS policies.
• Edge Functions: The supabase/functions/ folder contains your serverless backend logic.
• RLS policies: These live inside the migration files as SQL statements.

What does NOT travel with the code:

• Table data: The actual rows in your database. Your users, their records, their content. None of this is in the GitHub repo.
• Storage bucket files: Images, documents, and other files uploaded through Supabase Storage.
• Auth users: The user accounts and their authentication state.
• Environment variables and secrets: API keys, Stripe keys, and other configuration stored in Lovable's secrets manager.

What travels with the official export

Lovable's database export covers most of that gap in one file. The backup contains your full database, structure and data: your tables and rows, RLS policies, triggers, sequences, scheduled job definitions, and the auth schema with your user accounts.

What travels with neither the code nor the export:

• Storage bucket files: the database keeps the bookkeeping rows, but the actual files must be downloaded and re-uploaded separately.
• Secret values: only the names exist anywhere; the values must be re-entered by hand in the destination.
• Provider configuration: OAuth credentials (like Google sign-in) and anything else set up in a dashboard rather than in code or data must be recreated on the destination.

So the full picture is: code, including your Edge Functions, travels through GitHub; database and users travel through the export; storage files, secret values, and provider configuration are the manual remainder.

Keep credentials private during migration

Never paste a password, a secret key, or customer data into a chat prompt, even when an AI tool is helping you migrate.

The export backup contains your users' personal data: keep it private, store it only on your own machine, and delete it once the migration is complete and verified.

Phase 1: Own your data

You want your database, users, files, functions, and secrets replicated on a Supabase project you control, verified, while your app keeps running on Lovable Cloud untouched.

You need: a Supabase account (free tier works), a GitHub account, and 2 to 4 hours depending on the size of your app. The one technical step, the database restore, is handled by an AI assistant for you.

Before you begin: the export is a snapshot. Anything your users write after the export starts will not be in it. For the final cutover, take your app offline first so no data is created behind the backup. Lovable does not have a maintenance mode, but you can unpublish your project (Project Settings, then Unpublish project). Let your users know in advance, and start when traffic is lowest. You can republish once the migration is complete. For a first dry run, you can skip this and migrate a copy of live data while the app stays up.

Connect your Lovable project to GitHub

If your project is already connected to GitHub, skip to the next step. Otherwise:

1. Create a GitHub account at github.com if you do not have one
2. Create a new repository (the name can match your project, e.g. my-lovable-app)
3. In the Lovable editor, go to Project Settings, then Git, then GitHub, and connect to that repository

Lovable will push your full source code, including database migrations, Edge Functions, and RLS policies. You need this for the Edge Function code and for Phase 2.

Create a new Supabase project

Go to supabase.com, create a new project. Choose a region close to your users. You will be asked to set a database password. Save it somewhere safe; the restore step needs it. Also save the project URL and publishable key (use the Copy dropdown in the dashboard).

Export your database from Lovable Cloud

In your Lovable project, open Cloud → Overview → Advanced settings. In the Export project data section, click Export data and confirm. Lovable emails you a download link when the export is ready; the file also appears as a bucket in Cloud → Storage, named something like database_export_..., holding a .backup file.

Advanced settings sits at the bottom of Cloud → Overview; the database_export bucket in Storage is where your export lands · click to enlarge

Download the file now and keep it somewhere safe. The export lives inside your project's Cloud storage, so it is deleted together with Cloud if you ever remove it.

The limits: 5 GB per export, one export per day. If your database is larger than 5 GB, write to support@lovable.dev with your project ID. If you cannot use the export at all, the old fallback still works: export each table as CSV from the Cloud tab's Database view. But be warned that Lovable writes semicolon-delimited CSVs with JSON-style array syntax that Supabase's importer rejects; ask your AI tool to convert them, and treat the backup restore as the far less error-prone path.

Restore the backup into your Supabase

Fair warning: this is the one step in the guide that cannot be done with clicks. A .backup file is a compressed binary that only a restore command can read. The Supabase dashboard does have import buttons, but the Table Editor imports CSVs one table at a time and the SQL Editor runs pasted SQL; neither can open this file. And the CSV route would lose exactly what makes the export valuable: your users' passwords, your security policies, your triggers. So let an AI assistant run the restore for you, while Cloud is still safely running:

Option 1: Claude Code. Open it in an empty folder and ask; it installs what it needs, runs the restore, and checks the result. It will open your browser once so you can log in to Supabase.

I exported my Lovable Cloud database to [path to your-export.backup].
Install the Supabase CLI, then restore this backup into my new Supabase
project [project name]. Install anything else you need. When done, show
me row counts for every table and the number of auth users, so I can
spot-check them against Lovable Cloud.

Option 2: claude.ai, nothing to install. Connect the Lovable and Supabase connectors (Settings, then Connectors), open a chat, and ask:

Move my Lovable Cloud database for [project name] into my new Supabase
project [new project name]. Bring the schema, all table data, RLS
policies, and the auth users with their identities and password hashes.
Then verify by showing row counts for every table on both sides.

Claude reads from Cloud and writes to your new Supabase, and the row-count table at the end is your proof.

With either option, one known quirk: if the restore reports errors on auth.identities, ask for the restore to be run a second time; the second pass fills in what the first could not. And if you would rather run the restore yourself, Supabase documents it in its migration guide.

Verify the restore

Open the Table Editor in your new Supabase project. Your tables should be there with their rows. Check Authentication to confirm your users arrived, and spot-check row counts on your most important tables against the Lovable Cloud side.

Check your auth users can sign in

The export carries the complete auth schema, so your user accounts arrive with the restore. What happens to passwords is less clear: Lovable's documentation says user passwords are not exported in a usable form and advises planning a password reset flow, while builders who tested the export in mid-2026 report that migrated users could sign in with their original passwords after a full restore.

Treat this as something to verify, not assume. Create a test account on your live app, run it through the export and restore, and try signing in against the new project. If the password does not survive, use Supabase's reset flow to send reset emails at cutover. Either way, plan for users to sign in again: sessions do not transfer between projects.

Deploy Edge Functions and re-enter secrets

Your Edge Function code is in your GitHub repo, not in the backup. In your new Supabase project, go to Project Settings → Integrations, connect your GitHub repository, and enable deploys from the main branch. To trigger the first run, make any tiny change in the repo (example: open your README.md on github.com, click the pencil icon, add a space, and commit). Supabase deploys your Edge Functions automatically, and every future push keeps them up to date. Check Edge Functions in the sidebar a couple of minutes later to confirm they arrived.

Then the secrets. Secret values never leave Lovable, by design. List the secret names your functions use (check your Lovable project's secrets and your function code), and re-enter each value in your new Supabase project under Edge Functions → Secrets. The names must match exactly, or the functions will fail at runtime.

Export storage bucket files

In your Lovable project, click the Cloud button, then go to Storage in the side menu. For each bucket:

1. Select the bucket
2. Click the checkbox to select all items
3. Click the download button

Then in your new Supabase project, create the same buckets and upload the files through the Storage section of the dashboard.

Recreate scheduled jobs

If your app uses scheduled jobs (cron), their definitions came along in the export, but the restore cannot write them into their protected home in the new project, so they need to be recreated. First, in your new Supabase project, go to Database → Extensions and enable pg_cron (and pg_net, which jobs use to call your functions over HTTP). Then list what you had: in the Lovable Cloud SQL Editor (Cloud button, then Database, then SQL Editor), run:

SELECT jobname, schedule, command FROM cron.job;

Recreate each job in your new project's SQL Editor with cron.schedule, or paste the list into your AI tool and ask it to write the statements for you. Watch the URLs: a job that calls an edge function still points at your old project's address, so swap in the new project's URL as you go. If you skip this, scheduled work silently keeps hitting a backend that will disappear in Phase 3.

Migrate Google sign-in (Optional)

If your app does not use Google sign-in, skip this step. If it does but it is not critical to your app, consider disabling it for now. You can always add it back later once the rest of the migration is complete. Google sign-in is the most involved part of the migration.

If you do need it, there are two things to handle:

1. Configure Google OAuth in your new Supabase project. Check your Lovable auth settings (Cloud button, then Auth). If you are on "Managed by Lovable", you will need to create your own Google Cloud OAuth credentials (ask your AI tool to walk you through it if the Google docs feel dense) and configure them in your new Supabase project under Authentication, then Providers, then Google. If you are already on "Your own credentials", you can reuse the same Client ID and Client Secret.

2. Update your code. Lovable Cloud handles Google sign-in through its own libraries, not through Supabase directly. These will not work outside Lovable Cloud. Ask your AI tool to search your codebase for any calls to lovable.auth or imports from @lovable.dev/ and replace them with the equivalent native Supabase auth methods.

Existing users may need to sign in again after the move. Verify account matching and session behavior with test users before cutover; do not assume OAuth identities or existing sessions will transfer automatically.

Where you stand after Phase 1

Everything now exists in two places: your app still runs on Lovable Cloud, untouched, and a verified copy of your database, users, files, functions, and secrets lives on your own Supabase. Nothing has switched yet, which is exactly the point: the original Cloud instance is your rollback until the new path is verified end to end.

Two roads from here:

• You want to keep building in Lovable: go to Phase 3. You will remove Cloud and connect your own Supabase to the same Lovable project.
• You want your own hosting, or to switch tools: go to Phase 2 first, verify everything on Vercel against your new Supabase, then finish with Phase 3.

Phase 2: Own your hosting

After Phase 1, the migrated data is on your own Supabase and the original Lovable Cloud instance remains available as a rollback source. This phase moves the frontend to Vercel so the new production path no longer depends on Lovable hosting. This is also the phase to complete if you want to continue developing your project with another AI tool like Claude Code, Codex, or Cursor. Once your app is deployed on Vercel from your GitHub repo, you can work on the code with any tool you want and Vercel auto-deploys every push.

You need: a Vercel account and about 20 minutes.

Create a Vercel account

Go to vercel.com and sign up. The easiest option is to sign up with your GitHub account, which connects the two automatically.

Import your project

In the Vercel dashboard, click New Project, then Import your GitHub repository. Vercel auto-detects that it is a Lovable project and configures the build settings. Click Deploy.

Update environment variables

Your Lovable project uses environment variables to connect to Supabase. You need to set the same values in Vercel. Find your credentials in your Supabase dashboard: click the Copy button next to your project URL, then select Project URL or Publishable key from the dropdown.

In your Vercel project settings, add:

• VITE_SUPABASE_URL = your new Supabase project URL (e.g. https://yourproject.supabase.co)
• VITE_SUPABASE_PUBLISHABLE_KEY = your new publishable (anon) key
• VITE_SUPABASE_PROJECT_ID = your new project reference ID

If your app uses other environment variables (Stripe, OpenAI, Resend, etc.), add those through Vercel's protected environment settings too. Inventory the required variable names from the application code and provider dashboards; do not commit an .env file or secret values to GitHub.

Point your domain

If you have a custom domain, add it to your Vercel project and update your DNS records to point at Vercel instead of Lovable's hosting.

Your app now runs on your own infrastructure. Your users hit Vercel, which talks to your own Supabase. Lovable Cloud still exists on their side, but nobody depends on it. You can still use the Lovable editor to make changes. Since Lovable pushes to the main branch by default and Vercel auto-deploys from main, your Lovable edits will go live on Vercel automatically. If you use another AI tool like Claude Code or Codex, you can preview and test changes locally before pushing to main.

Phase 3: Cut the cord

Your data lives on your own Supabase, and, if you did Phase 2, your app already serves from your own hosting. The old Cloud instance is still attached to your Lovable project. This phase removes it, and reconnects the project to your Supabase if you are staying in Lovable.

Before you remove anything

Removal is permanent, so the checklist comes first:

• The export .backup file is downloaded to your machine. The export is stored inside your project's Cloud storage, so it is deleted together with Cloud.
• Storage files are downloaded and re-uploaded to the new project.
• The restore is verified: tables, rows, users, policies.
• Edge Functions are deployed and secrets re-entered on the new project.
• Scheduled jobs point at the new project's URLs.
• A real sign-in test passed against the new Supabase. If you are staying in Lovable and have no app pointing at the new project yet, spin up a throwaway deployment (Phase 2 without the domain step) on a vercel.app URL, test sign-in and data there, then delete it.

Remove Lovable Cloud

Open Cloud → Overview → Advanced settings and click Remove in the Remove Lovable Cloud section. Lovable makes you check two confirmation boxes (the second unlocks after the first) and type the project's exact name before the final Remove. This permanently deletes the Cloud instance, it cannot be undone, and it does not migrate anything for you. That is what the checklist above was for.

Connect your own Supabase to the same project

If you are staying in Lovable: after removal, the Cloud tab offers "Already have a Supabase project? Connect it here". Click it, authorize your Supabase organization, and select your new project. Lovable rewrites the project's environment configuration to point at your Supabase automatically; you do not edit anything by hand. If the preview shows an error page right after connecting, make a small edit or refresh to trigger a rebuild.

From here you keep building and publishing in Lovable exactly as before, except the backend is a Supabase project you own.

If you are done with Lovable

If you completed Phase 2 and are moving to another tool, there is nothing to connect: your app runs on Vercel and your own Supabase, and the old Cloud instance was the last dependency. Even then, do not remove it merely to finish a checklist; keep it until you are certain nothing depends on it, because preservation is safer than irreversible deletion when any dependency is uncertain.

If Lovable Cloud goes down

This is the emergency playbook. Lovable Cloud is unreachable, your app is down, and your users are affected.

If you already completed Phase 2, there is nothing to do. Your app runs on Vercel and your own Supabase. Lovable Cloud being down does not affect you.

If you completed Phase 1 but not Phase 2, follow Phase 2 now. Your data is already on your own Supabase, so the remaining work is deploying the frontend and configuring the destination environment variables. Treat the 20-minute estimate as a best case for a simple frontend; DNS, integrations, and production verification can take longer.

If you have not started any phase, you can still get your frontend back online. Deploy to Vercel from your GitHub repo (follow Phase 2), keep the environment variables pointing at the Lovable Cloud Supabase (the values already in your .env), and point your domain to Vercel. Your app will be served from Vercel but still talk to the Lovable Cloud database.

Verifying everything works

After completing whichever phases you need, run through this checklist:

• Auth flows: Sign up, log in, log out, password reset. All should work against your new Supabase project.
• Data queries: Browse your app as a user would. Verify that data loads correctly, lists populate, and detail pages render.
• Storage files: Check that images, documents, and other uploaded files load correctly from the new storage buckets, and that no stored signed URLs still point at the old project.
• Edge Functions: Test any server-side logic. Payment processing, email sending, API integrations.
• RLS policies: Log in as different user types. Verify that users can only see and modify their own data.
• Webhooks: If you use Stripe, Resend, or other services with webhooks, update the webhook URLs to point at your new domain.
• Scheduled jobs: Confirm cron jobs run against the new project and no job still calls an old Cloud URL.
• Custom domain: Verify your domain resolves to Vercel and that HTTPS works correctly.
• Performance: Run a few page loads. Check that response times are acceptable from your new infrastructure.

If any check fails, the issue is almost certainly in environment variables or missing data. Go back to the relevant phase and verify each piece transferred correctly.

Manual schema deployment

If your project has no production data worth restoring (a prototype you are rebuilding fresh), you can skip the export entirely and deploy just the schema from your repo's migration files. Do not run this on a project you restored the backup into: the backup already contains the schema, and replaying migrations on top can conflict. These steps require Git (pre-installed on most Macs; on Windows, download here) and Node.js (which includes npx). Open a terminal (Terminal on Mac, PowerShell on Windows) and run:

git clone https://github.com/your-username/your-lovable-app.git
cd your-lovable-app
npx supabase login
npx supabase link --project-ref your-new-project-ref
npx supabase db push
npx supabase functions deploy

Replace your-new-project-ref with the project reference ID from your Supabase dashboard (the part before .supabase.co in your project URL, e.g. asqyjpagrwvcmrcucsgn). supabase login opens your browser to authenticate. supabase link will ask for the database password you saved earlier. db push applies your database schema (tables, RLS policies, indexes). functions deploy deploys your Edge Functions.

If db push fails with an error like "relation does not exist", it means a migration file references a table that was created through the Lovable UI instead of through code. Paste the error into your AI tool and ask it to fix the migration file.

What comes next

You have migrated. Your app runs on infrastructure you control. You can change database providers, switch hosting platforms, or scale independently without waiting for anyone's support team.

But owning your infrastructure is not the same as running a production app. Who audits your security, code quality, and compliance? Who monitors your app at 3 AM when a database connection drops? Who notices your Stripe webhook is returning 500 errors before your users start complaining?

That is where BWorlds helps. BWorlds audits the app across security, code quality, operations, and compliance readiness, monitors production signals, prioritizes findings, and provides investigation context and fix prompts. After you apply a change, BWorlds verifies the code or live site when technical verification is possible. The migration gives you control; BWorlds adds an operating layer around it.