How to Migrate Off Lovable Cloud to Your Own Supabase

Why migrate off Lovable Cloud

Lovable now offers three self-service actions under More → Cloud → Overview → Advanced settings.

• Export project data creates a database backup containing structure, data, security policies, and auth users. The export file can be up to 5 GB, with one export every 24 hours.
• Pause Cloud stops an idle instance from consuming credits without deleting it.
• Remove Lovable Cloud permanently deletes the Cloud instance.

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

BWorlds tested the complete migration path, including password preservation and reconnection of the same Lovable project to a customer-owned Supabase. Removing Cloud still comes last. Export, restore, move the remaining backend pieces, and verify the destination before deleting anything.

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 moves, and how

| Component | Migration path | | --- | --- | | Frontend, migrations, Edge Functions, RLS policies | GitHub repository | | Database rows, schema, policies, auth users, password hashes | Official Lovable .backup restore | | Storage files | Download and upload separately | | Secret values and OAuth configuration | Recreate in the destination | | Scheduled jobs | Restore definitions, then recreate jobs and update URLs | | Active sessions | Do not transfer; users sign in again |

BWorlds verified the full auth-schema restore and same-project reconnection path in an end-to-end migration test.

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, a GitHub account, and 2 to 4 hours depending on the app. The database restore requires command-line tooling; use the reviewed process below.

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 More → 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.

Lovable allows one export every 24 hours. Projects using up to 15 GB of database storage are eligible for self-service export, but the export file itself must be no larger than 5 GB. If it exceeds that limit, 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

A .backup file requires command-line restore tooling; the Supabase dashboard cannot open it. Follow Supabase's migration guidance. If you use Claude Code to execute the restore, give it the backup path and destination project, then review each command before approving it.

Restore [path to backup] into Supabase project [project name] using
Supabase's supported migration process. Preserve the complete auth schema.
When finished, compare row counts for every table and the auth-user count.
Stop and show me any restore error before modifying auth tables.

Keep credentials out of the prompt. Authenticate through the browser or terminal when requested. If the restore reports errors on auth.identities, resolve them before continuing; do not replace the auth schema with hand-written inserts.

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

BWorlds restored the complete auth schema in an end-to-end migration test. Existing users signed in with their original passwords after the move. Active sessions did not transfer, so users had to sign in again.

Repeat that test with a real account before cutover.

Deploy Edge Functions and re-enter secrets

Your Edge Function code is in GitHub, not the backup. After the restore, connect the repository under Project Settings → Integrations, enable Deploy to production for the main branch, and confirm the functions are declared in supabase/config.toml. Trigger an intentional deployment and verify the functions in the dashboard.

The integration can also apply migrations. If it reports migration-state errors, resolve them instead of replaying the schema blindly.

Secret values never leave Lovable. Re-enter them under Edge Functions → Secrets with the exact names used by your functions.

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.