What happened to Lovable

What it is and why it matters

In April 2026 The Register reported a researcher's disclosure about Lovable, and Lovable then explained the incident on its blog: between February and April, because of a problem in its backend, chats and code of public projects could be seen by other users. Lovable says private projects were not affected and that the problem is fixed. If you have a project there, read their post.

I have nothing against Lovable. This story just reminded me how much it matters to know where your project lives and who holds its keys. If it lives inside a platform, the platform's security is your security. If it lives in a folder of yours, with your own keys, the mistakes are yours, and at least you can fix them.

The thing is, a project isn't just the code: there's the data, the users' accounts, the uploaded files, the keys, the domain. Each piece leaves through a different door, and if you forget one, you find out when a user can't get in anymore.

Below is how to get everything out. I use Lovable's menus, but the logic works for any platform. And it's useful even if you stay: having your own copy is common sense.

One rule before anything else: don't delete anything until the new one works.

1. The code

On Lovable: Project settings → Git → GitHub. You connect your account and have it create the repository: Lovable creates it as private and keeps it synced both ways, what you change in Lovable goes to GitHub and vice versa.

The sync follows a single branch, usually main. While it's on, do your tests on a separate branch and you won't touch the project inside Lovable.

If your plan has it, the same menu also has “Download codebase”: a zip of all the code. Good as a backup copy, but it doesn't update.

Then you clone the repository to your computer, from the “Code” button on the repo's page on GitHub. From here on, it's a folder of yours.

2. The database

The code carries the structure of the database, not the data. The structure lives in the migrations: SQL files, usually in the supabase/migrations folder, that recreate tables, columns and access rules. The data, meaning the actual rows, you export separately.

For schema and data, with Lovable's built-in backend (Lovable Cloud) you use the database export from the advanced settings: More → Cloud → Overview → Advanced settings → Export data. The link arrives by email. It's a Postgres backup archive, not an SQL file to paste: you restore it with pg_restore. If instead you have the database connection string, you use pg_dump. On Supabase you find the string under the “Connect” button on the project dashboard, and its guide uses the supabase db dump command.

You import it into a Postgres or Supabase of your own, new and empty.

3. The users

Login accounts don't travel with the tables: if you only move the data, the users stay behind.

The full Lovable Cloud export, on the other hand, includes them, with the passwords stored in scrambled form. If you restore it into a Supabase project, users keep their password. Two things don't come over, though: the sessions, so everyone will have to log in again, and the settings of the sign-in methods, like “Sign in with Google,” which you set up again on the new one.

If you're coming from a different route and the passwords can't be carried over, prepare a “reset your password” email to send on the day of the switch.

4. Uploaded files

Photos, documents, avatars: they're not in the database and they're not in the code. On Lovable Cloud you find them in More → Cloud → Storage. Download them and upload them again to the new storage, into buckets (the storage's “folders”) with the same names.

Then count the files before and after.

5. The keys

Secret variables don't come out with the code or with the database export. And on Lovable secrets can't be read back, only replaced: you get the value from the service that gave it to you.

Make a list of all of them: database, APIs, payments, email. Put them in your .env on your computer and in the settings of the new hosting. Private keys never go in the code or in git, and never in a variable that starts with VITE_: those end up in the browser, so only public values there.

Then regenerate them: new keys, old ones revoked. A key that stays valid on a platform you no longer use is a door left open.

6. Domain and login

Point the domain to the new hosting, following your host's instructions. The lovable.app address stays with Lovable and keeps showing the last version you published there.

Then update the login redirect URLs: the new address has to be added to the ones your login system allows. If you use “Sign in with Google” or similar, update it there too. If you forget, the login breaks right on the new domain.

With Claude Code, inside the folder

Open the terminal in the project folder and start Claude Code (cd into the folder, then claude). It reads the files on its own. I give it these requests, in this order.

Read this project and give me a list of everything that depends on the platform it comes from: variables, services, URLs, server-side functions.

This is your map. Server-side functions are the ones that run outside the browser: in Lovable projects with Supabase they usually live in supabase/functions and have to be deployed separately on the new backend.

I add the next one myself: it gives you the list of keys from step 5 without having to hunt for them by hand.

Give me a list of all the environment variables the project uses: where they're read, which ones end up in the browser and which ones must stay secret. Don't write the values.

Run it locally with my new database and tell me what's missing.

This is where the forgotten keys and the empty tables show up. Claude Code asks your permission before changing files or running commands, depending on the permission mode you chose: read what it's about to do before you say yes.

Check that no key is written in the code or in the git history.

If it finds one in the history, deleting the file isn't enough: it stays in the old commits. You regenerate that key, period.

7. Publish, test, then switch off the old one

When everything works locally, publish on a hosting you control. Then test the things that break first:

1. The login: sign in with an account that already existed and create a new one.
2. A file upload, and that it opens again.
3. Payments, if you have them, in test mode.

Only then switch off the old one.

Common mistakes

• Deleting the old project as soon as you have the repository. Keep it running until login, files and payments work on the new one.
• Thinking the repository is the whole project. The code carries the structure; data, users, files and secrets each come out on their own.
• Importing the data into a database that's already in use. Start from a new, empty Postgres.
• Copying the old keys over to the new one and calling it done. Regenerate them and revoke the old ones.
• Forgetting the redirect URLs. Add the new domain to the ones your login allows before you move it.

Checklist

• Repository on GitHub, private, cloned to the computer
• Structure and data in the new database, empty before the import
• Login tested with an old account and a new one
• Files downloaded, uploaded again and counted
• Keys listed, regenerated, old ones revoked
• Domain and redirect URLs updated
• The old one switched off last

Frequently asked questions