Migration guide
How to move a Lovable app to your own server
The code is the easy part. What traps most people is everything the app leans on that never lived in the repository in the first place.
The usual version of this: the app works, users are on it, and then you need a real domain, a backup you control, or a buyer asks where it runs — and it turns out the answer is “inside somebody else’s account.”
What Lovable actually gives you
More than people expect. Lovable can sync your project to your own GitHub repository, and what lands there is an ordinary front-end project — usually React with Vite. You can clone it, install dependencies and build it locally. Nothing exotic, no proprietary compiler.
So if all you have is a static front end with no backend, you are close to done: build it, put the output behind any host, point DNS at it. Most people are not in that situation, because the moment an app has logins or saves anything, it has a backend — and on Lovable that backend is Supabase.
The four pieces that have to move
A migration is not one job, it is four, and they fail in different ways.
- The front end. The React build. Genuinely straightforward — this is the part everyone assumes is the whole task.
- The database. Postgres underneath Supabase: your tables, your rows, and the row-level security policies that decide who can read what. The policies matter as much as the data.
- Authentication. Your existing users, and specifically their password hashes. Get this wrong and every user is locked out on cutover day.
- Storage and server-side functions. Uploaded files live in object storage, not in the database. Any server-side functions run on the vendor’s runtime and need somewhere new to run.
Two honest paths
Path A — run Supabase yourself
Supabase is open source and ships a self-hosted stack. You stand it up on your own server, restore your database into it, and point the app at the new URL. The application code barely changes, because it is still talking to the same interfaces.
This is the shortest route, and it preserves auth cleanly — your users and their hashes come across with the rest of the database. The cost is that you now run several services instead of one, and they are yours to keep alive, patch and back up.
Path B — replace Supabase with a plain backend
Keep the front end, put ordinary Postgres behind it, and write a small server that owns the database access. Fewer moving parts, and nothing vendor-shaped left in the stack.
The catch is auth. Moving password hashes into a different auth system is the part that quietly goes wrong, and if it cannot be done cleanly your users get a forced password reset — survivable, but it is a conversation you want to have before cutover, not during.
Row-level security also needs re-thinking rather than copying: rules that the database used to enforce now have to be enforced by your server, and “we’ll add that later” is how data leaks between accounts.
Where migrations actually go wrong
- Storage gets forgotten. A database dump does not contain uploaded files. The app comes up looking healthy and every avatar and attachment is a broken link.
- Secrets were only ever in the vendor’s dashboard.API keys for payments, email and third-party services are not in the repository. Inventory them before you cut over, not after something stops working.
- Nobody tested the restore. A backup you have never restored is not a backup. Do it once, on purpose, before you need it.
- DNS was flipped before the new stack was verified. Bring the new environment up on a temporary hostname, click through it as a real user, and only then move the domain.
- Webhooks still point at the old URL. Payment providers and integrations keep calling the vendor’s endpoint until you go and change them.
Before you cut over
- Full database dump taken, and restored somewhere at least once
- Storage bucket contents copied and spot-checked
- Every secret and API key accounted for outside the vendor dashboard
- A real login tested end to end with an existing user account
- TLS working on the new host before DNS moves
- A rollback you could execute in ten minutes
Or have it done
This is a day of work if you have done it before and a long weekend if you have not. We do it for a living: your code in your repository, your database on your server, your domain and certificates in your account, plus a pipeline so the next deploy does not need us.
From $600, typically finished within a day. If we look at your app and think it cannot be moved cleanly, we tell you that instead of taking the job.