Lovable added Export, Pause, and Remove buttons to Lovable Cloud this month, and for the first time, leaving is a supported action instead of something you had to work around. Before this, adding Cloud to a project was close to a one-way door. Lovable’s own documentation still splits Cloud users from Supabase-integration users into separate instructions, because the two setups leave differently. What the new buttons give you, and what they quietly don’t, decides how much this month’s announcement actually helps you.
There isn’t one answer to “how do I move off Lovable Cloud,” because founders asking that question are usually asking three different things.
The three moves people call “moving off Lovable Cloud”
Moving off Lovable Cloud is one of three different moves: a frontend-only exit that keeps Cloud as the backend, a backend swap to your own Supabase project, or a full exit off the managed-backend model, and each costs a different amount of work.
Most of what follows is written for the second path, because it’s the one the new buttons were built for and the one with the most ways to lose something you didn’t back up first. Picking the destination is a separate decision from making the move, and which Lovable alternative to move to scores the six most-named ones on auth, database defaults, deploy path, and export.
Do you actually own what’s inside a Lovable app?
The honest answer is: partly, and the parts you own depend on choices you made earlier, not on anything the Remove button does for you. If you connected a GitHub repo, your frontend code and edge function source already live in git, under your account, independent of Lovable. If you didn’t, that code exists in exactly one place until you go get it.
Your database is a separate question. Lovable’s export feature gives you “your full database, both structure and data,” inside the size and frequency limits the next section spells out. Downloading it gives you real ownership of your rows and schema, but not of the three things a database depends on to work the way it did inside Lovable. That blind spot is what the rest of this post is about.
What the export carries, and what it leaves behind
The database export gives you a full copy of your tables, columns, schema, and rows, capped at 5GB and limited to one export every 24 hours. It leaves behind your storage files, your edge function code, and your project secrets, each spelled out as an exclusion in the same documentation and each sitting in its own place you have to go get it from. The export is also only worth as much as the restore that proves it loaded: how to export a Lovable database and prove the export is complete walks the whole path, including the two-account test on the new project.
Your export has your data. It doesn’t have your secrets, and it doesn’t have the code that decided who got to see it.
Removing Lovable Cloud is explicit about the stakes: the confirmation dialog makes you check two boxes acknowledging that Cloud features stop working and unexported data may be gone, then type the project’s display name to proceed. That friction is doing you a favor. It’s the last screen where “I’ll grab that later” is still an option.
The capture-before-delete checklist
Do these in order, before the Remove button, not after:
- 01 Run the database export and confirm the download link actually opens.
- 02 Download every file in your storage buckets individually; the database export won't reach them.
- 03 Copy every secret value out of the secrets panel into a password manager, not a text file on your desktop.
- 04 Confirm your edge function source lives in a connected GitHub repo, or copy the function code out by hand if it doesn't.
- 05 Import the dump into a scratch project and confirm it loads before you trust it.
- 06 Only then check both confirmation boxes, type the project name, and remove the instance.
Step five is the one people skip, and it’s the one that turns a fine plan into an unrecoverable mistake. An export you haven’t restored into a live database is a hopeful guess that it works, not a tested backup.
Why the move forces a security recheck
An RLS policy that exports cleanly as text is no evidence it does its job on the new project. I audit apps for a living, and RLS gaps turned up in 9 of 21 third-party apps in the AxonBuild corpus, almost always on a table that had a policy attached, just not one that checked what it needed to.
The corpus behind that number is 21 third-party apps AxonBuild has audited. A policy that copies over cleanly and a policy that actually stops a stranger from reading another customer’s row look identical in a schema dump. The only way to tell them apart is to log in as two separate accounts and try.
The same goes for secrets. 6 of 21 apps in the corpus shipped a real secret somewhere it shouldn’t have been, three of them permanently stuck in git history. One I recovered during an audit was a live LLM-provider key an early commit had written into the app’s own config file; the project had long since switched to a .env and deleted the file, and the full history still handed back a working credential. If any of the values you copied out of Lovable’s secrets panel ever sat in a shared doc, a support ticket, or a screen-share, moving day is when you rotate them at the provider, not when you paste them into the new project’s environment variables unchanged.
Edge functions carry their own version of this. Of the 14 apps in the corpus that ship an AI feature, 12 had a confirmed way for someone who isn’t a customer to drain the owner’s model budget: a route that calls a paid model with nothing checking who’s asking. An edge function that was open like that inside Lovable stays exactly as open on whatever host you move it to, because moving code doesn’t add the auth check nobody wrote the first time. Why AI coding tools ship security holes by default covers why that gap is so common in the first place.
Once the new Supabase project is live, give it a real staging environment before your first customer becomes the person who finds the next migration bug, and treat every schema change the way you’d treat one on a database you’d never migrated at all: with a rollback plan and a tested restore, not a hope that the new host handles it the way Lovable did. The data-loss patterns that hide in an AI-built app don’t care whether the database is a week old or three years old.
When moving off Lovable Cloud is the wrong call
Not every app needs this. If you have no customers yet and the only complaint is Cloud’s pricing or a feature you’d rather build without Lovable’s editor in the way, the frontend-only path from the table above gets you most of what you want for an afternoon’s work, and the export-and-delete checklist doesn’t apply to you at all. If the trigger is a security worry instead, settle whether Lovable is safe first, because a leak that lives in your own tables migrates with the data. Rebuilding a backend you’re happy with, on a schedule nobody’s forcing, is a bad trade against actual product work.
The calculation changes once something real is on the line: paying customers, data you’d have to explain losing, or a platform decision (a pricing change, a policy shift, a feature you need that Cloud doesn’t offer) that’s making the choice for you rather than you making it. At that point the Lovable Cloud migration stops being optional, and the checklist above is the difference between a clean move and a support-ticket-shaped one.
Common questions about moving off Lovable Cloud
Do I own my Lovable app?
You own the pieces you’ve captured. Code is fully yours if you connected a GitHub repo, because it already lives in git under your account; the database becomes yours the moment an export lands on your disk; storage files, edge function code, and secrets stay inside Lovable Cloud until you copy each one out. Ownership here describes what you’ve exported, not what the dashboard shows.
What happens when I remove Lovable Cloud?
The instance is permanently deleted, and Lovable makes you acknowledge that twice: two confirmation checkboxes plus typing the project’s display name. Anything not already captured, database changes since your last export, storage files, function code, secrets, goes with it. There is no undo and no grace-period restore. The 60-day grace window people have read about applies to a deleted workspace, not to a deleted project and not to credits, and whether Lovable has a grace period splits the three cases apart.
Should I move off Lovable Cloud before launching?
Only if a platform constraint is already forcing the decision. A migration adds its own risks on top of whatever the app already carries, and whether the app is ready to launch at all is the question that decides more. An app that isn’t ready moves its unreadiness with it.
Where the audit fits
None of the steps above tell you whether the app was production ready inside Lovable before you started moving it. That’s a separate question, and I’ve already answered it at length for Lovable specifically. What these steps tell you is narrower and just as important: whether the move itself introduced a gap that wasn’t there before. A fresh Supabase project with an RLS policy nobody’s tested, a secret pasted in unrotated, an edge function that’s exactly as open as it always was, all of that is new risk the migration created, not risk the app already had.
That’s also why migration is a natural moment for a fixed-scope audit of whatever the generator left behind. A Beyond the Demo Audit picks up exactly where this checklist stops: it walks the new project’s trust boundaries with real accounts instead of a read of the schema, and tells you which of the six items above are actually done versus which ones only look done. You built the first version fast enough to have this problem in the first place. Moving it is a reasonable place to find out what came along for the ride, and what didn’t.
Don't guess where you stand.
The free 2-minute Beyond the Demo Scorecard estimates where you stand across 12 readiness areas and shows what to check first.
