How do I move my app from Lovable Cloud to my own Supabase project?

There is a specific moment when this question arrives. The app works, it has users, and you have decided you want to do something ordinary with your database — connect a backup tool, run a migration, look at a query plan, give a developer read access, plug in an analytics service. And you discover that you cannot, because there is no database to connect to. Not in the sense that it does not exist. In the sense that there is no door.

That is the thing worth understanding before anything else, so let me start there.

What Lovable Cloud actually is

Lovable Cloud launched at the end of September 2025 as the built-in backend: a database, authentication, file storage and server-side functions, all available without leaving the editor. It is enabled by default on new projects, which matters, because it means most people using it did not choose it — they simply never turned it off.

Underneath, it is Supabase. Lovable's documentation describes Cloud as built on Supabase's open-source foundation, and Supabase has publicly confirmed that every Lovable Cloud project is powered by Supabase behind the scenes. So the technology under your app is exactly what you would have picked anyway.

What is different is the operating model. In a normal Supabase project you have an account, a dashboard, a project URL, a connection string, an anon key and a service_role key, and everything Postgres and Supabase can do is available to you because you are the account holder. In Cloud, Lovable is the account holder. You are a tenant.

That distinction sounds administrative. It is not. It determines what you can see, what you can fix, and what you can take with you.

What you can and cannot reach

Inside Lovable, you get more than people expect. There is a Cloud tab with a SQL editor in it, so you can run queries against your own database, inspect your schema, and read your data. You can see your tables. You can see your auth users. For day-to-day building, it is genuinely usable.

What you do not get is the rest.

No Supabase dashboard. Your project does not appear in any Supabase account, because it is not in your Supabase account.

No connection string and no service_role key. This is the one that has real consequences. Every external tool that works with Postgres — a GUI client, a backup service, a migration tool, a BI dashboard, a data pipeline — connects by pointing at a database. There is nothing to point at.

Row Level Security policies are read-only in the interface. You can see the policies that exist. You change them by asking the AI to change them, not by editing them yourself. Given that RLS is the entire data-access security boundary in a Supabase-backed app — the thing standing between one customer's records and another's — being one layer removed from the controls is worth being conscious of. I have written separately about why RLS is where AI-built apps actually leak, and the short version is that this is not a theoretical concern.

Secrets are write-only. You can set an API key. You cannot read it back afterwards. This is defensible as a security design — plenty of platforms do it — but it has a practical consequence people discover at exactly the wrong moment: if you did not record a key somewhere else when you set it, it is gone, and migrating means going back to every third-party provider and issuing new ones.

None of this is hidden. It is all documented. It is just not the kind of thing anyone reads while the app is still fun to build.

The export, and exactly what is in it

For a long time the honest answer to "how do I get my data out of Cloud" was that there was no official one. That changed in July 2026, when Lovable shipped a documented export.

It is a real export and it does the main job: you get the full database, structure and data. That is the part that matters most and it is good that it exists.

Here is what it does not include, and this is the part to plan around:

Your storage bucket files. Every user-uploaded avatar, document, image and attachment lives in storage, and storage is not in the export. If your app is a file-handling app, the export contains the rows that describe your files and not the files.

Your edge function code. The server-side functions your app depends on — the webhook handlers, the scheduled jobs, the anything-that-cannot-run-in-the-browser — are not in the database export.

Your secrets. As above. Write-only means write-only, including at export time.

There are also operational limits worth knowing before you plan a migration day. The export is capped at 5 GB, and you can take one export per 24 hours. So if your first export reveals a problem, your second attempt is tomorrow, not in ten minutes. Plan for that rather than discovering it.

And there is a genuinely one-way door in here: removing Lovable Cloud from a project cannot be undone. That is not a warning against doing it. It is a warning against doing it before you have verified your export actually opens and actually contains what you think it does.

The claim about passwords, and why I am being careful about it

This is the one place in this post where the available sources disagree, and I would rather show you the disagreement than pick a side quietly.

Lovable's documentation states that passwords are not exported in a usable form, and that you should plan a password reset flow for your users.

The most-upvoted community post about Cloud migration says the opposite: that the export is a standard database dump including password hashes, and that your users will not need to reset anything.

I am siding with the documentation, for three reasons. It is the vendor's own statement about its own product, so it is the thing they are accountable for. No independent commenter corroborated the community claim. And the asymmetry of being wrong is stark: if you build a password reset flow and it turns out you did not need it, you have wasted an afternoon. If you skip it and the documentation was right, every user on your platform is locked out on the morning you migrate, and you find out from them.

For what it is worth, moving auth users between two Supabase projects that you control is well-supported, hashed passwords included, with a caveat about the JWT secret needing to match. But that caveat is the whole problem from Cloud, because the JWT secret is one of the things you never had.

So: build the reset flow. Send the email. Be pleasantly surprised if it was unnecessary.

What you give up by leaving

It would be dishonest to write this as though moving out is free. Connecting your own Supabase project is still fully supported on every plan, including the free one, and it is a native integration rather than a hack. But you lose some real conveniences.

You lose the backend views inside the editor, so checking your data means going to Supabase rather than looking at a tab. You lose built-in payments, which you will now wire up yourself. You lose managed transactional email, so you configure your own provider. And you lose the ability to change auth configuration by describing what you want in chat — you will do it in the Supabase dashboard like everyone else.

For a project that is genuinely still an experiment, that trade is not obviously worth making. For a project with paying customers, it is not really a trade at all, because every one of those conveniences is something you need to control anyway the first time it matters.

The order to do this in

The sequence matters more than any individual step, because the expensive mistakes are all sequencing mistakes.

First, before anything, inventory what is not in the export. Write down every storage bucket, every edge function, and every secret your app uses. This is the list you will be rebuilding by hand, and writing it down while you still have access is much easier than reconstructing it afterwards.

Second, get your code out and keep it out. Turn on GitHub sync if it is not already on. Code sync is available on every plan and there is no reason not to have it running permanently, regardless of whether you ever migrate.

Third, take the export and open it. Not "download it and assume." Open it, restore it somewhere, and confirm that your tables, your rows and your relationships are all present. This is also where you find out whether your RLS policies survived, which is the sort of thing to learn on a test restore rather than on launch day.

Fourth, stand up your own Supabase project and restore into it. At this point you have both — the running Cloud app and your own project with the data in it — and that overlap is the safest place in the whole process to sit for a few days.

Fifth, rebuild the three things the export left behind. Copy storage files across. Redeploy the edge functions from your synced code. Re-issue every secret from its original provider, and this time record what you set where.

Sixth, deal with auth. Confirm what actually came across, and have the reset flow written and tested before you switch traffic.

Seventh, switch, then watch. Point the app at the new project, and then actually use it — the signup flow, the payment flow, an upload, a password reset. The failures here are the quiet kind rather than the loud kind, which means you find them by looking, not by waiting for an alert. That is a general truth about this class of work and I have written about the shape of it in why your app works in preview and breaks in production.

Only then, remove Cloud. After everything is verified, not before. It cannot be undone.

Should you do this at all?

Three situations where I would say yes without much hesitation. If you are handling anything sensitive — health data, financial records, anything where a regulator or a customer's security questionnaire is in your future — you need direct control of the security boundary rather than a read-only view of it. If you have an actual developer working with you, being unable to give them database access is an ongoing tax on every hour they work. And if you have any operational maturity requirement at all — real backups you have tested, staging separate from production, migrations under version control — those all need the door that Cloud does not have.

And one situation where I would say no. If your app is still finding out whether it should exist, migrating is a week of work that produces nothing a user can see. Cloud is a good product for that stage and moving early is the sort of thing that feels productive and is not.

The version of this decision I would most like people to avoid is the accidental one: being three years and four hundred customers into a business, on infrastructure you never chose, discovering the constraints for the first time on a day when something is already wrong. Cloud being on by default is convenient. It is only a problem if nobody ever revisits it.

The wider question of what you actually own — on Lovable and on the other three platforms — is covered here in more detail, and how the platforms compare once real users are involved is in Lovable vs Bolt vs Replit vs Cursor for production.

If you would rather not do this alone

A Cloud-to-Supabase migration is a well-defined piece of work with a small number of ways to go badly, and almost all of them are avoided by doing the steps in the right order with a verified export in hand before anything irreversible happens.

I do a Production-Ready Audit that covers exactly this ground: what is actually in your Cloud project, what the export will and will not carry, what has to be rebuilt by hand, whether your RLS policies are doing what you think, and a written migration plan in sequence. From $499, back in five to seven days.

If you just want a sanity check first, tell me roughly what your app does and whether it stores user-uploaded files, and I will tell you whether this is a two-day migration or a two-week one. No charge — that part is usually obvious from the description.

The full picture of what tends to be missing at this stage is in the ten problems every AI-built app has in production, and the repair work itself is described on the AI SaaS rescue page.