Migrate from Lovable

Overview

Your Lovable app has two halves: the code, which lives in GitHub, and the backend - its database, sign-in users and uploaded files. Hostwares runs both. The code deploys as a site from your repository; the backend moves into a Supabase project with one backup command and one upload.

What migrates

• Your database structure. Every table, column, relation and enum from your project's migrations.
• Your app's logic. Every database function your app calls, every access rule, trigger and view - copied from your live project, including the ones created outside its migrations.
• All your data. Every row in every table.
• Sign-in users. Accounts keep their existing passwords, so your users sign in exactly as before.
• Uploaded files. Images, PDFs and other files from both public and private storage, with their folders and file types.

What doesn't

• Your app's code - it moves through GitHub (connect your Lovable project to GitHub and deploy that repository).
• Secrets you added in Lovable (payment or email API keys, for example) - add them again in your site's Environment tab.
• Edge functions and Lovable-only AI features - these may need a small amount of rewiring in your code.

1. Create the destination

A Supabase project for your data and a site for your app.

• Supabase: open your Supabase instance and create a new project for this app (for example "myapp"). If you don't have an instance yet, order one under Supabase → New first.
• Site: in Lovable, connect the project to GitHub. Then create a site on Hostwares from that repository. It gets a free *.hostwares.app address; you can add your own domain later.

2. Back up your Lovable project

Run one command on your own computer. Nothing from Lovable passes through our servers.

curl -fsSL https://migrate-lovable.hostwares.com/install.sh | bash

irm https://migrate-lovable.hostwares.com/install.ps1 | iex

• A browser window opens so you can sign in to Lovable. A fresh access token is created automatically and stays on your computer.
• Pick the project from the list. The tool shows a progress bar while it copies your database, sign-in users and files.
• When it finishes, everything is in Downloads/Hostwares/<project name>/: a backup-<date>.json file (database, app logic and sign-in users), a storage folder (your uploaded files) and a migrations folder (your schema as SQL).
• Files in private storage: while copying, the tool briefly makes those storage buckets readable, then locks them again as soon as the copy ends. You don't need to give it any key.
• Note the summary it prints at the end (tables, rows, functions, access rules, triggers, users, files). You'll use those numbers to check the restore.

3. Restore into your project

Upload the backup in your project's Restore tab.

• Zip the whole backup folder - the .json file together with the storage folder. On macOS: right-click the folder → Compress. On Windows: right-click → Send to → Compressed (zipped) folder.
• Open your Supabase project → Restore → upload the .zip. It restores the database, data, sign-in users and files into the project and shows live progress.
• If your app has no uploaded files, you can upload the .json on its own. A .json without its storage folder brings no files across.
• Uploads can be up to 200 MB. For a bigger backup, open a support ticket and we restore it for you.
• When it finishes, Restore history shows what was restored (tables, rows, app logic, users, files). Compare it with the numbers the backup tool printed.
• Restoring the same app's backup again into the same project is safe: rows are never duplicated, and only what is missing is added.

4. Connect your app and deploy

Point the site at your new project, then it rebuilds.

• On the project's Overview, use "Connect to your frontend site": copy the variables, paste them into your site's Environment tab and redeploy. Or ask HW to do it for you.
• Lovable apps are built with Vite, so the names start with VITE_. Next.js apps use NEXT_PUBLIC_ and Create React App uses REACT_APP_ instead. The block also includes the plain names (SUPABASE_URL, SUPABASE_PUBLISHABLE_KEY) that apps rendering pages on the server read while running - keep them.
• These values are baked in when the app is built, so the site rebuilds after you change them. Your current version keeps serving until the new build is ready.

5. Check it's live

Open your app and sign in.

• Open your site's address and sign in with an existing account - passwords carried over.
• Open a page that shows uploaded images or files and check they load.
• Happy with it? Add your own domain to the site.

Environment variables

These tell your app which project to talk to. Set them on the site (or let "Connect to your frontend site" and HW set them for you), then redeploy.

Your project's URL and public key are on its Overview page. Never put the project's service_role key in a VITE_ variable - those are visible to anyone who opens your site. Server-side code that needs it gets it automatically.

Let HW do it

Tell HW "migrate my Lovable app". It creates the project and the site, gives you the backup command, waits for your upload, connects the site, deploys it and reports what was restored against what was backed up. It never asks for your Lovable login or any key: the backup and the upload are the two steps you do yourself.

Troubleshooting

The build ran out of memory

Large apps sometimes need more memory to build than they need to run. Builds now retry automatically with more build memory. If a build still fails with an out-of-memory message, move the site to a larger pack.

The app still shows the old data, or sign-in fails

The site is still pointed at the old project. Check the Environment tab has VITE_SUPABASE_URL, VITE_SUPABASE_ANON_KEY and VITE_SUPABASE_PUBLISHABLE_KEY set to your new project, then redeploy. Some Lovable apps also write the old address straight into src/integrations/supabase/client.ts - change it there to read import.meta.env.VITE_SUPABASE_URL and import.meta.env.VITE_SUPABASE_PUBLISHABLE_KEY.

Pages crash, or say a database function could not be found

The backup was made with an older version of the backup tool, which didn't copy your app's functions, access rules and triggers. Run the backup command again and restore the new .zip into the same project - your data isn't duplicated, only the missing logic is added.

Every page says a Supabase environment variable is missing

Your app reads its settings on the server while it runs, under names without the VITE_ prefix. Add SUPABASE_URL and SUPABASE_PUBLISHABLE_KEY (the same values as the VITE_ ones) in the Environment tab - or use "Connect to your frontend site", which sets both - then redeploy.

Images or files don't show

The backup was uploaded as a .json without its storage folder. Zip the whole backup folder and restore the .zip into a fresh, empty project. If the backup tool reported files as missing, they had already been deleted in Lovable and cannot be recovered.

The restore says the file is too large

Uploads are limited to 200 MB. Open a support ticket and we restore the backup for you.

A feature that used Lovable's own services stopped working

Edge functions, Lovable AI features and secrets you added in Lovable don't come across in the backup. Add the secrets in the Environment tab, and ask HW if a feature needs rewiring.

Still stuck? Ask HW in the dashboard, or see Deployed but not working.