Leaving Lovable Cloud: what the export actually gives you, and what it doesn’t
Answer first: since July 2026, Lovable Cloud has an official exit: an “Export project data” function and a “Remove Lovable Cloud” option, documented in Lovable’s own Cloud docs. That ends the era of “there’s no way out”, and Lovable deserves credit for shipping it. But an export is a copy of your data, not a migration of your system. Lovable’s documentation itself states there is no one-click migration to your own Supabase: you export, connect a fresh Supabase project to a new Lovable project, and rebuild the schema there. This guide maps exactly what carries over, what has to be rebuilt, and what each path costs.
On Lovable specifically: the patch-or-rebuild assessment for Lovable products →
What changed in July 2026
Answer first: Lovable Cloud, the platform’s bundled backend, gained a documented export path in July 2026, first flagged in migration-community write-ups that month and confirmed in Lovable’s official Cloud documentation: you can export your project data, and you can remove Lovable Cloud from a project entirely. Before this, the bundled backend had no sanctioned exit at all, which is why “the code is portable, the infrastructure isn’t” became the standard critique. The critique now needs updating rather than retiring: the door exists. What’s behind it is a data dump and a rebuild, not a working system on the other side.
Worth stating just as plainly: the code side was never the locked half. Lovable syncs generated frontend code to GitHub, and that repository is yours. Lock-in was always about the running system: the database, auth, functions, secrets and hosting that Lovable Cloud bundles. That’s the half the July 2026 export addresses, partially.
What the export contains, per Lovable’s own documentation
Answer first: the export gives you your data; the documentation is candid that reassembly is on you. Three passages from Lovable’s Cloud docs (retrieved August 2026) define the boundary:
- On migration: “There is no one-click migration from the built-in backend (Cloud) to your own Supabase project. If you want to move, you export your Cloud data, connect a Supabase project to a new Lovable project, and rebuild the schema there.” The word doing the work is “rebuild”.
- On removal: “Remove Lovable Cloud… permanently deletes your Cloud instance and cannot be undone. Export your database and download any storage files you need before continuing.” The exit is one-way; there’s no trial separation.
- On regions: once Cloud is enabled, the hosting region “is locked and cannot be changed” and “existing projects cannot be moved across regions.” If your users grew somewhere your region isn’t, the export is the only route there.
The remix behaviour confirms the pattern from another angle: remixing a Cloud project copies “the structure of backend-related data, such as tables and Edge Functions… without any information”, generates fresh keys, and drops manually added keys entirely. Even inside the platform, structure travels and live state doesn’t.
What a working system needs that the export doesn’t carry
Answer first: five things stand between a data export and a running product, and they’re the actual scope of any migration off Lovable Cloud.
| The export gives you | A working system also needs |
|---|---|
| Your table data, as a dump | The schema rebuilt: tables, relations, constraints, indexes, and RLS policies re-created and re-tested on the new backend |
| Storage files, downloaded | Storage wired back up: buckets, access rules, and every file path your app references |
| Your frontend code (via GitHub, as before) | Every backend call re-pointed, and every place the generator hardwired a Cloud assumption found and changed |
| Auth as a living system: your users’ accounts and sessions re-established on the new backend, with a re-login or migration step you have to plan and communicate | |
| Edge functions, secrets and integrations re-created by hand: keys don’t travel, by design |
None of this is exotic engineering. All of it is work, and the size of the work scales with how much logic lives in the backend rather than the frontend. A content app with three tables is a weekend. A product with roles, payments, functions and integrations is a project, and pretending otherwise is how founders end up mid-migration with a half-working system and customers on the old one.
The honest decision framework
Answer first: the export changes when to leave, not whether the reasons to leave are real. Three situations, three answers:
Stay, and export routinely.
If the product works, growth is manageable and no compliance or diligence pressure is in sight, the rational move is to stay and make the new export function a habit: a scheduled copy of your data into storage you own converts lock-in from a cliff into a slope. Lovable has said it will keep supporting external Supabase connections; there’s no forced march here.
Leave to your own Supabase.
If your main pain is ownership and auditability rather than the platform itself, the documented path (export, new project, rebuild schema, re-point) gets you a backend you administer. Budget real engineering time for the five rows in the table above, and do the RLS policy work properly while you’re there; the incident record around generated schemas is its own story, covered in the RLS guide.
Rebuild to scale.
If the backend move is happening anyway and the product has outgrown its generated architecture (velocity down, security review unpassable, features the platform can’t express), doing the migration twice is the expensive path. A rebuild does the extraction once, onto a foundation designed for where the product is going, and the export is simply step one of it.
What each path costs
Answer first: in ranges honest enough to plan with. Routine exporting costs minutes a month and is free. A clean lift to your own Supabase, for a small app with modest backend logic, is days-to-weeks of competent engineering; published community walkthroughs and my own project experience agree the schema-and-auth rebuild dominates the time. A full rebuild of a proven product runs, in published market spans consistent with my own pricing, €50,000–150,000, and is only worth it when the structural signals are real. Pricing the decision itself is what a diagnosis is for: €7,500, fixed, one week, and it tells you which of the three situations above you’re actually in, including if the answer is “stay”.
What the diagnosis and the rebuild include, week by week, with the money-back guarantee: how the engagement works →
Questions founders actually ask
- Does the July 2026 export mean the lock-in criticism was wrong?
- No, it means Lovable responded to it, which is to their credit. The criticism described the situation accurately until July 2026, and the remaining gap (data out, system rebuilt by hand) is documented by Lovable itself, not by critics.
- Can I move my Cloud project to my own Supabase without rebuilding?
- Not per the vendor: "there is no one-click migration… you export your Cloud data, connect a Supabase project to a new Lovable project, and rebuild the schema there" (Lovable Cloud docs, retrieved August 2026). Third-party migration tools have appeared (NextLovable among them); they compress the work, they don’t remove it, and you should test any tool’s output the way you’d test your own rebuild.
- What happens to my users’ logins if I migrate?
- Plan for a re-authentication step. Account data can move with your export, but live sessions and the auth configuration are part of the backend you’re leaving. Communicate it like the product change it is: a dated migration notice beats a surprise logout.
- Is Base44’s export the same thing?
- It’s narrower. Reviews of Base44’s export (PlugThis and others, 2026) document that it covers frontend code while backend logic, database structures and auth remain on the platform, and data export runs through capped batch requests. Lovable’s July 2026 move set a better bar; the category hasn’t uniformly followed it.
- If I’m leaving anyway, why not just prompt a new app on another platform?
- Because your data, your users and your validated product logic are the assets, and a fresh generation preserves none of them. Moving platform-to-platform re-rolls the same dice on a new table. If you’re leaving because generated architecture failed you, the fix is architecture, not a different generator.