How to move your app off Lovable and onto your own Supabase (a free tool that does it for you)

You built something real on Lovable, and now you want it to be yours in the fullest sense, which usually means one of two things: you’d like to stop paying for Lovable every month for an app that’s already built, or you want to turn it into a proper mobile app for the App Store and Google Play and you’ve realised that Lovable on its own isn’t going to get you there.

Either way, the answer starts in the same place, which is getting your app and its database out of Lovable and onto accounts in your own name. I built a free tool that does most of that for you, and this article explains what it does, step by step, and what it deliberately leaves to you.

Can you leave Lovable and keep your app?

Yes. Lovable is pretty open about this: you aren’t locked in. Its GitHub sync is on every plan, and it puts your app’s full code into a repository you own. That code is ordinary React, and the backend underneath it, whether it’s Lovable Cloud or a Supabase project you connected yourself, is Supabase, which is open source and something you can run yourself.

So leaving isn’t the hard part. The hard part is that a Lovable app is wired to the Lovable project it grew up in. Its database lives in Lovable’s backend, its design sits in a folder of migration files inside the web app, and the app’s code points at an address and a key that belong to that hosted project. To own the whole thing you have to untangle those, and that’s the part people put off, because it’s fiddly and the cost of getting it wrong is a broken app.

What the free tool does, step by step

The tool lives in Kealy Studio, which is a free account and runs everything on your own computer through VS Code. It’s a single sheet with five steps, and the second one is the step that does the work in one go.

1. Put your Lovable app on GitHub. In your Lovable project you open Project settings, then Git, then GitHub, and connect your account. Lovable makes a private repository with your code in it. The sheet walks you through this and checks that your computer is signed in to the same GitHub account.

2. Bring it to this computer. You pick that repository from a list, confirm the folder it goes in, and press one button. Then, while you watch, Kealy Studio:

• downloads your app from GitHub and installs what it needs;
• disconnects it from Lovable by removing its link to Lovable’s repository, so nothing you do in the copy goes back to Lovable, while your git history stays exactly where it was;
• adds a backend of your own beside it, a folder that holds your database’s design from now on (and a small Python API for later, when your app needs one);
• has Claude Code move your database over and rewire the app. Claude copies your migrations into the new backend, in their original order, on top of the few tables a mobile app needs (a user row per account, and a devices table for push notifications). It keeps every one of your tables, columns, policies and functions with exactly the same names, because that’s what lets your data import cleanly later. It moves any edge functions you have, takes Lovable’s database folder out of the web app, points the app at the new database through environment variables instead of Lovable’s hard-coded address, checks that the app still builds, and commits both folders with a plain message.

3. Start your new database. Your database runs on your computer first, inside Docker, built from the migrations Claude just put together. If Postgres refuses one of them, which can happen with an older project, the error goes straight back to Claude, which fixes the migration and tries again. Then you open the app on the dashboard and press the power button.

4. Bring your data and your users across, which I’ll come to below, because it’s the part that deserves your attention.

5. Put it online. Publish creates a fresh GitHub repository of yours (not Lovable’s), your live Supabase project, your backend on Google Cloud and your web app on Cloudflare, one step and one button at a time, all in your own name.

What actually changes in your code?

Very little, on purpose. The rule the tool gives Claude above all others is that your app must keep behaving exactly as it did on Lovable, so it isn’t refactoring anything, renaming anything or adding features. What changes is where things live and how the app finds its database:

	On Lovable	After the move
Your code	A repository Lovable keeps in two-way sync	The same code and history, disconnected from Lovable
The database’s design	supabase/migrations inside the web app	supabase/migrations in your own backend folder, shared with the mobile app later
Where the app finds its database	Lovable’s hosted address and key, often committed to the repo	Two environment variables, filled in on your computer and set for you at publish
Edge functions	Inside the web app	In your backend folder
Your data and users	In Lovable’s backend	Still there, until you bring them across
Who pays for what	Lovable	You, directly: Supabase, Google Cloud and Cloudflare all have free tiers

The one small extra is that Lovable runs its preview server on port 8080, which is the port your new backend uses, so the tool moves the web app to 5173. Newer Lovable projects built on TanStack Start, which has been Lovable’s default since May 2026, get the same treatment on their server side too.

Does my data come with it?

No, and I want to be really clear about this, because it’s the thing that catches people out. What comes across is your app and the design of your database: every table, every column, every rule about who can read what. What’s in the database, the rows and the user accounts, stays on Lovable until you bring it over.

If your app doesn’t have real users yet, that’s the end of it. You’ve got a working copy on a database you own, and you carry on building.

If it does have data you want to keep, the simple route is CSV. In Lovable you open your project’s database, export each table as a CSV file, and then in Supabase Studio, which is Supabase’s own table editor and opens from the sheet, you import each file into the table with the same name. Because the tool kept every table and column exactly as it was, the files go straight in. The one thing to watch is the order: tables that other tables point at go first.

What happens to my users and their passwords?

User accounts don’t travel in CSV files, and any row that belongs to a user needs that user to exist first. With the CSV route, people who signed in with Google can simply sign in again on the new app, and people who used an email and password would need to reset their password.

There is a way round that. Lovable’s full database backup includes your users’ accounts along with their password hashes, so a careful restore can bring everyone across without a single reset. It’s also the point where moving stops being a ten-minute job and starts being something to plan: which data, in what order, how your users find the new app, and when you switch over.

If your Lovable app is already live with real people on it, that’s genuinely where I’d suggest we talk before you switch anything over. You can book an hour with me from inside the studio and we’ll plan the move together. Either way, the tool never touches your Lovable app, so your users carry on as normal until you decide.

Why move off Lovable at all?

There are two reasons I hear most often. The first is cost and ownership: an app that’s built doesn’t need an AI app builder’s monthly subscription to keep running, and once it’s in your own GitHub, Supabase and Cloudflare accounts, the only bills are the hosting ones, which for a small app usually sit inside free tiers. You also stop depending on one company’s roadmap and pricing for something you’ve put months into.

The second is mobile. Lovable builds web apps, and the App Store and Google Play want native ones. I’ve written a whole article on turning a Lovable app into a real mobile app, and the short version is that wrapping your website in a native shell is quick but risky with Apple’s review, while building a proper React Native app with Expo, on the same database, is the reliable route. That’s exactly why the tool puts your database into a backend folder of its own: so that a mobile app can sit beside your web app and share it, with the same tables and the same accounts.

What do you need on your computer?

A Mac or a Windows PC, VS Code, and Claude Code signed in with your own Claude subscription, which is what does the reading and rewiring. The studio sets the rest up for you as you go: Git and Node when you first connect, Docker when you start your database, and the GitHub sign-in in step one. Nothing about your app runs on Kealy Studio’s servers, and nothing is held in my name.

How long does it take?

The move itself takes about ten minutes, most of it Claude reading your app before it changes anything, plus a few more the first time Docker downloads the database. Bringing data across depends on how much of it there is; for an app without users there’s nothing to do.