Leaving Lovable Cloud for Your Own Supabase

AI builders now ship with a managed backend attached: a database, logins, file storage and server functions that appear without you creating an account anywhere. It is genuinely useful, and it is why a prototype can reach a working login screen in an afternoon. The question arrives later, usually in one of two forms. Credits ran out and the bill no longer makes sense, or someone asked where the customer data actually lives and you did not like the answer.

Moving to a database project in your own account is a documented path rather than a rescue mission. But the word export does a lot of work in that sentence, and most of what goes wrong happens because people assume it covers more than it does.

What you already own, and what you only rent

Start by separating the two. Your application code is yours, and connecting the project to a GitHub repository is the step that makes that concrete. Alongside the code sit migration files: the SQL that creates your tables, indexes, access policies, functions and storage buckets. Those are the blueprint of your database, and they are in the repository too.

What is not in the repository is everything the blueprint produced. The rows in your tables, the files your users uploaded, the accounts they signed up with, and the API keys wired to Stripe or anything else all live in the managed project, not in your code. That is the gap you are actually crossing.

Decide three things before you touch anything

1. Whether you have real users yet. With no real users, this is an afternoon of housekeeping. With real users, it is a cutover with a window, a rehearsal and a rollback position.
2. Who owns the destination account. Create the new project under the company's own email and billing, not a personal account you will have to untangle later.
3. Whether you will keep prompting the builder afterwards. This decides more than anything else, and it is the question people skip.

On that last point: after you repoint the application at your own database, the builder environment can still be talking to the original managed one. Changes you prompt there will not appear in the database your live app is using. If you intend to keep working in the builder, settle how that will work before you move, not when a customer reports a missing record.

What moves by itself, and what you carry

The shape of the move is consistent, even as the tooling changes. You create your own project, apply the migration files to it in order so the schema matches, and point the application's environment variables at the new project instead of the old one.

Then you carry the rest by hand. Table data is typically exported and re-imported table by table, which means you have to respect the order in which records reference each other: parents before children, or the import fails on constraints. Uploaded files are downloaded and re-uploaded. Secrets are re-entered in the new project. Server functions and scheduled jobs are redeployed. Nothing here is difficult. It is simply a list, and the failure mode is an item quietly missing from it.

Your existing users and their passwords

This is the part that decides your timing. User records can be exported, but you may not be able to carry the stored passwords across, and in that case every existing account arrives without a working login. The fix is a forced password reset, which means an email to every user explaining why they are being asked.

That is a tolerable message to send to twenty early testers. It is a bad message to send to a few thousand paying customers, and it is the reason to make this decision early rather than after launch. Social logins need their own attention: each provider has to be configured again on the new project, and every redirect URL updated, or sign-in fails for everyone at once with an error that looks nothing like the cause.

Keys, environments and the two checks worth repeating

A migration is a good moment to fix things you inherited, because you are touching every key anyway. Two are worth deliberate attention.

First, access rules. Your policies migrate with the schema, which is both the good news and the bad news: if one user could read another user's records before, the new database reproduces that faithfully. Our piece on row-level security covers how to test it in a few minutes.

Second, key handling. The old project's keys should be treated as retired, and the new project's secret key must stay on the server. If an old secret key ever reached the browser bundle, rotating it is part of this job rather than a separate one; the key that ignores your security rules explains how to check the built output rather than the source.

In the platforms we build for clients, secrets live in the deployment environment rather than in the code, and applications run on the client's own hosting and accounts. That is the end state worth migrating towards, not just a different managed box.

What breaks if you do this halfway

The worst outcome is not a failed migration. It is a partial one, where the live site reads from the new database while a staging environment, a scheduled job or the builder itself still writes to the old one. Both fill up with real-looking data, neither is complete, and the divergence is usually discovered weeks later through a support ticket about an order nobody can find.

• Pick one database as authoritative on a stated date and write that date down.
• Verify after the switch: a login, a write, a file upload and a payment callback, in the real deployed environment rather than locally.
• Keep the old project read-only for a while rather than deleting it, so a missing table is an inconvenience instead of a loss.
• Only then turn off the old billing.

What to do next

If you have no real users, do it now while it costs you an afternoon. If you do have real users, write the list first, rehearse the import into a throwaway project, and schedule the password reset email as part of the plan rather than as a surprise.

If you would rather not run the cutover yourself, send us the app: we review the existing code and the backend before changing anything, then migrate, verify and hand over accounts you own, with a fixed quote. If you are still weighing whether to move at all, our production checklist is the shorter place to start, or tell us what you are building.