Let your bot move a Lovable app onto Lovable Cloud without losing data
By Šarūnas Vaitkus · about a 6-minute read
If your Lovable app runs on its own separate Supabase project, you might want everything in one place on Lovable Cloud. Your bot can export the data, make a copy of the app, rebuild the database, import everything in the right order, and compare the two apps side by side. The old app stays untouched as your rollback. You send the prompts below, in order, and it asks you before the domain moves.
A Lovable app connected to an outside Supabase project.
Your bot connected to Lovable and to that Supabase project.
About 20 minutes for checks and the final switch.
How it works
You send a prompt, the bot does the work, and you approve what matters.
Highlighted [brackets] are yours to replace. Copy keeps them in the prompt.
1
Step 1. Export everything (read-only)
Prompt to send
Export my app's data from [your Supabase project]. Don't change anything there. Save every table as a file, plus the full list of columns, types, defaults, constraints, row-level security policies and grants. Write a manifest with the row count of each table. Tell me about anything that won't export cleanly, such as file storage, user accounts or functions.
Why you're sending it
A complete, read-only export is your safety net and your checklist, and it can't break the live app.
What you'll get
A folder of data files, a schema file and a manifest with row counts.
2
Step 2. Copy the app
Prompt to send
Make a copy (remix) of my Lovable app [your app name]. Don't edit the original. Confirm the copy builds and shows the same pages, even if they're empty for now.
Why you're sending it
Working on a copy means your visitors keep using the original until the new one is proven.
What you'll get
A second app with the same interface, ready for its own database.
3
Step 3. Rebuild the database on Lovable Cloud
Prompt to send
Turn on Lovable Cloud's database for the copy. Recreate the schema from the export: the same tables, columns, constraints, row-level security policies and grants. Grant access in the same step that creates each table. Show me a side-by-side list of old and new tables and columns, and flag anything that differs.
Why you're sending it
The data only fits if the shape is the same. A side-by-side list catches a missing column before the import does.
What you'll get
A new, empty database that matches the old one, with any differences flagged.
4
Step 4. Import in the right order
Prompt to send
Import the data into the copy in dependency order: lookup tables first, then main records, then the tables that link them. Keep a map of old and new record IDs and use it for every link. Run each table in one step that fully succeeds or changes nothing. After each table, compare row counts with the manifest.
Why you're sending it
Links between tables break if you import in the wrong order or IDs change on the way.
What you'll get
A full import, an ID map and row counts that match the export.
5
Step 5. Fill the gaps
Prompt to send
Compare a sample of 20 records field by field between the old and new apps. Fill in any columns that came through empty and fix any that came through in the wrong format, for example lists saved as plain text. List every fix.
Why you're sending it
Row counts can match while fields are still empty or garbled. A sample check finds that.
What you'll get
A list of fixed fields and a clean sample.
6
Step 6. Check the apps side by side
Prompt to send
Open the old and new apps side by side in a real browser. Check the home page, a few detail pages, search, filters and any admin page. Take screenshots of each pair and list every difference, however small.
Why you're sending it
You want proof from the screens your visitors use, not just the database.
What you'll get
Paired screenshots and a list of differences to fix before the switch.
7
Step 7. Move the domain
Prompt to send
When I say go, publish the copy and move [your domain] to it. Tell me exactly what DNS or domain settings will change before you do it. Afterwards, check the domain loads the new app over a secure connection and that a few pages work.
Why you're sending it
This is the moment visitors switch over, so you decide when, and you see the change first.
What you'll get
The domain on the new app, with a check that it loads securely.
8
Step 8. Keep the old app as your rollback
Prompt to send
Leave the old app and its Supabase project running but unlinked from the domain for [a period you choose, for example two weeks]. Write down how to switch the domain back. After that period, remind me, and only then suggest what to pause or remove.
Why you're sending it
If something odd shows up a week later, switching back takes minutes.
What you'll get
A rollback that stays ready, and a reminder before anything is removed.
All in one (optional)
Prefer one prompt? Send this instead.
Prompt to send
Move my Lovable app [your app name] from its outside Supabase project to Lovable Cloud, in this order: a read-only export with a manifest, a copy of the app, a matching schema on Lovable Cloud, an import in dependency order with an ID map, a field-by-field sample check and fixes, a side-by-side check in the browser, a domain move when I say go, and the old app kept as a rollback. Pause after each step to show me what you did. Ask me before changing DNS, publishing, deleting or pausing anything, or spending money.
What your bot will always ask you first
Moving the domain or changing DNS.
Publishing the new app.
Pausing or deleting the old app or database.
Upgrading a plan or spending money.
Sending anything externally.
It bundles its questions, so you're not pinged all day.