Guide · AI-built apps
Moving off Lovable
Your own Supabase, your own hosting, and carrying on in Cursor or Claude Code. What moves easily, what doesn't, and when it isn't worth it.
Why migrate from Lovable at all?
Lovable is good at getting something real in front of people quickly, and it says itself that you are never locked in. People usually decide to migrate from Lovable for one of four reasons:
- They want direct access to their own database, with the SQL editor, the secret keys and the backups in their own Supabase account.
- A developer is now working on the app and wants to use their own tools rather than prompts.
- They want hosting they control, with their own monitoring, logs and deployment process.
- A customer, investor or compliance requirement means the data and infrastructure need to sit in accounts the business owns.
If none of those applies, read the last section before you start. Moving costs time, and an app that works is worth more than an app that has been moved.
Get the code into GitHub
Lovable's GitHub integration syncs your project to a repository you own, on every plan. Paid plans can also download the codebase as a zip. According to Lovable's self-hosting guide, the export contains your source files and the database migration files, but not your database data or anything users have uploaded. Those are separate jobs.
Do this first whatever else you decide. It is the copy any developer can read, and it is your insurance if anything goes wrong later.
Lovable Cloud to Supabase: the part that takes the time
If you connected your own Supabase project from the start, you can skip most of this: the database is already yours. If you used Lovable Cloud, it isn't. Supabase's own help page explains that Lovable Cloud projects run on a Supabase instance Lovable controls. They don't appear in your Supabase dashboard, you can't get the secret keys or use the SQL editor, and once Lovable Cloud is switched on the project can't be disconnected and pointed at your own Supabase instead.
So a Lovable to Supabase migration means building the backend again in a project you own and moving everything across. To migrate from Lovable to Supabase properly:
- Create a new Supabase project in your own account, in the region you want.
- Recreate the database structure from the migration files in your exported code, including the row level security policies. Check those policies as you go; this is a good moment to fix them.
- Move the data, table by table, in an order that respects the links between tables, and check it arrived before you retire anything.
- Move logins, file storage and functions. Lovable's guide is blunt that moving the PostgreSQL database alone does not move authentication, storage, realtime or Edge Functions. Plan for users having to sign in again or reset their passwords, and for uploaded files and functions being moved separately.
- Point the app at the new project with the new URL and publishable key, and test everything with real accounts before you switch.
There are third-party tools that automate parts of the Lovable Cloud to Supabase move. Some are useful; read what they need access to before you hand it over, and use a temporary key you delete afterwards.
Export Lovable to Vercel (or Netlify)
The front end is the easy bit. Lovable's guide lists Vercel, Netlify and Cloudflare Pages among the places you can host it, along with the big cloud providers. Most Lovable apps are React built with Vite, which these hosts handle without special setup: connect the GitHub repository, let it build, and add your environment variables (the Supabase URL and publishable key) in the host's settings.
Three things catch people out when they export Lovable to Vercel:
- Missing environment variables. They don't carry over from Lovable. The usual symptom is a blank page.
- Page refreshes that 404. A single-page app needs the host to send every route back to the app; otherwise refreshing a deep link fails.
- Login redirect URLs. Sign-in links and OAuth providers need the new domain added, or logins break after the move.
Newer Lovable apps built on TanStack Start run code on the server, so they need a host that runs server code rather than plain static hosting. Lovable's guide also notes you can move the front end and keep the Lovable Cloud backend for now, then move the backend later. Our guide to getting an AI-built app live goes into hosting in more detail.
Migrate from Lovable to Cursor or Claude Code
Once the code is in GitHub, carrying on in Cursor or Claude Code is mostly a matter of opening the repository. To migrate from Lovable to Cursor, or migrate from Lovable to Claude Code, the code itself doesn't change; what changes is who is deciding. Lovable decides for you. In Cursor or Claude Code, somebody has to decide what gets built, review what the AI writes and test it. That is the whole difference between AI-assisted development and vibe coding.
Two practical points. Lovable's GitHub sync works both ways, so pick one place to work: either keep building in Lovable, or switch the work to your editor, rather than editing the same files in both. And set up a proper way to run it locally and deploy it before you start changing things, so you can tell what you broke.
When not to move
Don't move just because it feels more grown-up. Stay on Lovable if the app is small, the people who use it are happy, you are still shaping it through prompts, and nobody is asking where the data lives. Most of the real risk in a Lovable app is in its database rules, and you can fix those without moving anything: our security checklist and Supabase security guide cover it.
Move when there is a reason you can name: a developer needs proper access, a customer or investor needs the data in your accounts, or the app now matters enough that you want your own backups, monitoring and deployment. If you are not sure, have someone read the code first. It will tell you whether a move is a weekend or a month.
What people ask about moving off Lovable
Sync the code to GitHub first. If your app used your own Supabase project, the database is already yours and you only need to host the front end somewhere like Vercel or Netlify. If it used Lovable Cloud, you also need to rebuild the backend in your own Supabase project and move the data, logins, file storage and functions across.
Yes, but not by flipping a switch. Supabase says a Lovable Cloud project cannot be disconnected and pointed at your own Supabase project once Cloud is enabled. You create a new Supabase project, rebuild the structure from your exported migration files, then move the data, logins, storage and functions across, following Lovable's self-hosting guide.
Sync the project to GitHub, import that repository into Vercel, and add your environment variables (the Supabase URL and publishable key) in Vercel's settings. Make sure every route serves the app so page refreshes don't return a 404, and add the new domain to your login redirect URLs. Newer apps that run server code need a host that supports it.
Plan for it. Moving the database does not move authentication by itself, so users are usually asked to sign in again or reset their passwords on the new project. Tell them before you switch, and test sign-up, login and password reset on the new setup first.
Yes. With the code in GitHub you can carry on in Cursor or Claude Code. The difference is that somebody has to decide what gets built and check what the AI writes, which is what turns a prototype into software you can rely on.
Tell us about your Lovable app
Tell us where your app is now and where you want it, and we'll tell you what the move involves.
Whether it uses Lovable Cloud or your own Supabase, roughly how many users and tables it has, and why you want to move. If staying put makes more sense, we'll say so.
What we will cover:
- Whether moving is worth it
- What moves easily and what doesn't
- What would happen to your users' logins
- Who does the move, us or you
Rather talk now? Book a call or ring 01474 639 089.
We reply within one working day.
