How to Migrate Off Lovable Cloud to Your Own Supabase

Why migrate off Lovable Cloud

Lovable markets itself as having "no vendor lock-in." The reality is more nuanced. Their own documentation states: "When you connect your project to Cloud, you can't revert that change or disconnect your project from the Cloud." There is no button, no setting, no self-service path to disconnect.

One builder shared their experience publicly on Reddit:

I had a production app with 106 database tables, 51 edge functions, and 302 RLS policies. I needed to disconnect from Lovable Cloud on a Saturday. I submitted a support request at 00:34. Fifteen hours later, still no response. The support AI told me to stop submitting duplicate tickets. I eventually deployed to Vercel myself and was back online in 20 minutes, but those 15 hours of silence on a production app were unacceptable.

To be clear: Lovable is excellent for building. Lovable Cloud is convenient for prototyping and early development. But when your app serves paying customers, you need either infrastructure you control directly or a support team that can respond immediately and whose priorities are aligned with yours. This guide shows you how to get the first one.

How this guide works

This guide has three phases, each building on the previous one. Read from the top and stop when you have reached the level of independence you need:

• Phase 1: Own your data sets up your own Supabase project and moves your database, files, and users off Lovable Cloud. You can keep using Lovable for editing and publishing. Many builders stop here.
• Phase 2: Own your hosting deploys your frontend to Vercel so your app no longer depends on Lovable's hosting layer. You can still edit in Lovable, but publishing through Lovable stops working. You handle the dev-to-production flow yourself.
• Phase 3: Cut the cord covers disconnecting from Lovable entirely, or requesting a support disconnect so the editor points at your own Supabase.

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 automatically:

• 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.

Understanding this distinction is critical. The code is portable. The data requires manual export.

Phase 1: Own your data

You want your database, files, and users on a Supabase project you control so that your production no longer depends on Lovable Cloud.

You need: a Supabase account (free tier works), access to the GitHub repo Lovable syncs your code to, and 2 to 4 hours depending on the size of your database.

Before you begin: take your app offline so no users are writing data while you migrate. If users keep using the app during the export, you risk missing data that was created after you started. 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 the migration when traffic is lowest. You can republish once the migration is complete.

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, you will need it shortly. Also save the project URL and publishable key (use the Copy dropdown in the dashboard).

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.

Clone your GitHub repo and push the schema

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 the following commands. If you get stuck, paste the error into your AI tool and it will help you troubleshoot.

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

supabase login opens your browser to authenticate. Replace your-new-project-ref with the project reference ID from your Supabase dashboard (it is the part before .supabase.co in your project URL, e.g. asqyjpagrwvcmrcucsgn).

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 (server-side logic like payment processing or email sending).

Your database and backend are now on your own Supabase.

Export table data

In your Lovable project, click the small Cloud button, then go to Database in the side menu. For each table with data you need:

1. Click on the table
2. Click Export CSV
3. Save the file locally

Then import each CSV into your new Supabase project by following Supabase's CSV import guide.

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.

Export auth users

Auth user migration is the trickiest part. If your app has registered users, open the SQL Editor in Lovable Cloud (Cloud button, then Database, then SQL Editor) and run:

SELECT * FROM auth.users;

Export the results as CSV. Do the same for auth.identities if your app uses OAuth providers (Google, GitHub, etc.).

Migrate Google sign-in

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 will not need to sign up again because Supabase matches identities by Google user ID, not by the OAuth credentials.

Connect Lovable to your new Supabase

Now that your data is on your own Supabase, update your Lovable project to use it. In the Lovable editor, click the Code button (</>), search for the file .env, and replace the Supabase variables with your new credentials:

• VITE_SUPABASE_URL = your new Supabase project URL
• VITE_SUPABASE_PUBLISHABLE_KEY = your new publishable (anon) key
• VITE_SUPABASE_PROJECT_ID = your new project reference ID

Find these values in your Supabase dashboard: click the Copy button next to your project URL, then select Project URL or Publishable key from the dropdown.

Republish your app from Lovable and verify that everything works against the new database.

Your app now runs on your own Supabase. You can keep building and publishing with Lovable exactly as before. The difference is that your data lives on infrastructure you control. If you want to stop here, that is a perfectly valid choice. Many builders do.

Phase 2: Own your hosting

After Phase 1, your data is on your own Supabase but your app still runs on Lovable's hosting. This phase moves the frontend to Vercel so your users no longer depend on Lovable's infrastructure at all. 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 too. Check the .env file in your GitHub repo to see which variables your project uses.

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

After Phases 1 and 2, your app runs on your own Supabase and your own hosting. But Lovable Cloud is still technically connected to your project on their backend. The old Cloud database still exists on Lovable's side, even though your app no longer uses it.

If you want to keep editing in Lovable

Your .env already points at your own Supabase (from Phase 1), so edits you make in Lovable use your database. But Lovable's backend still has a Cloud connection active. To fully clean this up, request a formal disconnect:

1. Open Lovable support (in-app chat or support email)
2. Request a "Cloud disconnect" for your project
3. Provide your project ID

What to expect: There is no self-service option, no API, and no documented SLA for how long this takes. The builder from the Reddit story requested a disconnect at 00:34 on a Saturday. After 15 hours of silence, the support AI told them to stop submitting duplicate tickets.

Recommendation: Request the disconnect on a weekday during business hours. Your app is already live on your own infrastructure, so there is no urgency. If support is slow, your users are unaffected.

If you are done with Lovable

You do not need to request a disconnect. Your app already runs on Vercel and your own Supabase. Lovable Cloud still exists on their side, but nobody is using it. You can stop paying for Lovable and never open the editor again.

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 you just need to deploy the frontend to Vercel and update your environment variables. This takes about 20 minutes. The builder from the Reddit story used this exact approach after waiting 15 hours for a support response and was back online in 20 minutes.

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.
• 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.
• 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.

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 what BWorlds does. Not another tool. A full AI production team that audits your app across security, code quality, operations, and compliance. We catch bugs, track performance, surface where users get stuck, and make sure your product keeps getting better. The migration gives you control. BWorlds makes sure it all works.