From Lovable Cloud to your own Supabase: what moves and what does not

Lovable Cloud is the backend Lovable runs for you: database, sign-in, files and server functions, without you creating a Supabase account. Under the hood it is Supabase. The project just sits on Lovable's account, not yours. You cannot open the Supabase dashboard, you get no service role key and no direct database connection. While you are building that is convenient. Once there are customers on it, you want that to change.

Why you want off it

• Ownership: your customer data sits in a project you do not manage and can only reach through Lovable.
• Access: no SQL Editor, no backups on your own terms, no connection for tools that need direct database access.
• Cost and dependency: you pay through Lovable for usage you could buy from Supabase directly, and your hosting hangs on your Lovable subscription.
• Building on outside Lovable: if you want to continue with a developer or another tool, the backend has to live somewhere they can reach.

Lovable says so in its own documentation: there is no one-click migration from Cloud to your own Supabase. It can be done, and Lovable now has its own export route for it, but it is a move with a few loose boxes.

What moves, and what you do by hand

Under Cloud, Overview, Advanced settings, Lovable offers an export of your data. It is a full dump of your database. According to Lovable's documentation, this is in it, and this is not:

• Moves: tables, data, RLS policies and your users, including their password hashes. Nobody needs to create a new password.
• Does not move: sessions. Everyone has to sign in once more after the switch, because the new project signs sessions with its own keys.
• By hand: files in storage. Download them from Cloud and upload them to the same buckets in Supabase.
• By hand: edge functions. The code is in your repository under supabase/functions; you deploy it with the Supabase CLI.
• By hand: secrets. API keys you set in Lovable are not in the export.
• By hand: sign-in providers such as Google, redirect URLs and scheduled jobs.
• Replace: AI features. While you are on Cloud, model calls go through Lovable's AI gateway; afterwards you need your own account with OpenAI, Anthropic or Google.

Mind the limits of the export as well: you can export once every 24 hours and there is a maximum size. For a large database it goes through Lovable support.

The order that works

The golden rule: keep your app running on Cloud until the new side demonstrably works. Only then flip the switch.

• 1. Connect your project to GitHub if it is not already. That holds your code, your migrations in supabase/migrations and your edge functions.
• 2. Create a Supabase project on your own account, in an EU region if your customers are in Europe. Keep the database password.
• 3. Make an export in Lovable and download it, along with every file in storage.
• 4. Restore the dump into your new project with the Postgres or Supabase tools.
• 5. Upload the files to the same buckets, deploy the edge functions, set the secrets and the sign-in providers again.
• 6. Put the new Supabase URL and publishable key into your app, on a test environment, and test.
• 7. Right before the switch, make one last export so you do not lose data from the days in between, then point your domain over.
• 8. Only remove Cloud once everything runs. That deletes the old environment for good, including exports still sitting in Cloud storage.

How to check it worked

• Count the rows per table in the old and the new project. They should match.
• Compare the number of users under Authentication.
• Sign in as an existing test user with their old password.
• Sign in as two different users and check they cannot see each other's data.
• Open a few uploaded files and check the links in your app still work.
• Do one action that calls an edge function, and one that sends an email.

That fourth check is not a formality. The policies move along, but whether they were ever right is another question. A move is the moment to check, because afterwards you have real access for the first time. How to do that is in why can my users see each other's data. And if your app creates new tables after the move, watch out for Supabase's change on 30 October.

Third-party tools

There are now tools that promise to move everything in one go. Some work fine, but you temporarily hand them access to your whole database of customer data. Look at who is behind one and what exactly it does before you do. Lovable's official export does not have that problem.

Do it yourself or have it done

A small app with a few tables, no files and no edge functions you can move yourself in an afternoon with this list. It is a different story with storage, several edge functions, Google sign-in or Stripe payments, because then everything has to switch at once without a customer noticing.

I do that move as a fixed block, from € 2,250 excluding VAT: export, a new project in your name, files, functions, secrets, a check of the policies and the switch itself. What the other blocks cost is on hire a Lovable developer. If you also want your frontend off lovable.app, that part is in can I export my Lovable app and host it myself.

Not sure whether it has to happen now, start with the free vibecode scan. I look at your project and tell you honestly whether moving pays off now or can wait.