Migrating off Lovable is one decision with four answers, because a Lovable app is five things: the code, the hosting, the domain, the Cloud backend, and the editor that changes it. Nothing in the phrase migrate off Lovable tells you which of the five you are moving.
Migrating off Lovable means choosing one of four exits: move the hosting, move the backend to your own Supabase project, run everything on infrastructure you control, or rebuild. The hosting move is about four cutovers and does not end your Lovable bill, because the database, the users and the editor all stay where they are.
Most people arrive here through one of two doors. The bill got uncomfortable, which is a credits question before it is a migration question and what Lovable actually costs per month settles it. Or the app started buckling under real usage, which is usually a load problem rather than a platform problem. Whether you have genuinely outgrown Lovable is worth settling before you pick an exit, because several of the common triggers are fixable without going anywhere. This page assumes that part is decided.
Lovable’s own documentation, checked on 15 August 2026, contains the sentence that reframes the rest. It says you are never locked in: “You can export your code, migrate your data, self-host parts or all of your stack, or move to another provider at any time.” It also says “The Lovable platform itself (the editor and AI agent) is a managed service and cannot be self-hosted or deployed inside a customer VPC.”
Your app can move to any host you like. The thing that has been writing it cannot come with you.
That is why moving an app off Lovable and moving your work off Lovable are two different jobs, and why people who finish the first one are often surprised to find they are still paying.
The four ways to migrate from Lovable, side by side
The rows below run in escalation order. Each one contains the one above it, and each one adds duties that do not end when the move does. Vendor documentation checked 15 August 2026.
| Exit | What moves | What stays on Lovable’s bill | Who can finish it |
|---|---|---|---|
| Move the hosting only | The built frontend, the domain, the deploy pipeline | The database, the users, storage, backend functions, and the editor | Someone who can connect a repository to Vercel, Netlify or Cloudflare Pages and re-run a build |
| Move the backend to your own Supabase project | Schema, indexes, policies, functions, triggers and buckets, then data rows, files and user accounts by hand | Frontend hosting, unless you move that too, and the editor | Someone who can run the Supabase CLI, send every user through a password reset, and re-point OAuth |
| Run the whole thing on infrastructure you control | Frontend and backend both, onto AWS, GCP, Azure, Docker, Kubernetes or your own machines | The editor | Someone who will own PostgreSQL operations, backups and disaster recovery from that day on |
| Rebuild on a stack you choose | Nothing automatically. The features get written again | Nothing, once the old app is switched off | A developer, for as long as the rebuild runs |
The destination list is the vendor’s own: AWS (S3 with CloudFront, ECS, EKS, Amplify), GCP, Azure, self-hosted Docker, Kubernetes and VMs, the managed platforms Netlify, Cloudflare Pages and Vercel, and managed or self-hosted Supabase for the backend. Lovable’s current stack pages conflict. Its ownership page calls every application Vite and React, while its current FAQ says apps created from 13 May 2026 use TanStack Start with server-side rendering and older apps use React and Vite. Inspect the repository before choosing the build, environment and hosting instructions. Git sync remains available for every project.
Instead of guessing at hours, count cutovers: the things that have to be re-pointed, re-issued and re-tested before the app works again. The hosting move has four, and you can check the arithmetic yourself: the build and deploy pipeline, the browser environment values that get baked into the new build, the domain with its DNS and certificate, and the authentication redirect URLs if the production domain changes. Deploying a Lovable app to Vercel walks that one.
The backend move has about ten: schema, data rows, storage objects, sign-in providers, every existing user’s password, OAuth redirect URLs, managed OAuth and token refresh, every secret value, server and edge functions, and the webhooks and scheduled jobs still calling the old URLs. Running your own infrastructure keeps that same list and adds duties that never finish. A rebuild has all of it plus the app itself.
Treat those counts as a measure of size rather than price. What each exit costs in money, whether you do it yourself or pay someone, is a separate question with a separate answer.
Which exit is wrong for you
The pages ranking for this query on 15 August 2026 each explain how to do one exit. None of them says which one you should not take. Here is that half.
-
Moving the hosting only is wrong if you are leaving because of the bill or the lock-in. It moves the cheapest, smallest piece. The database, the users, the storage and the backend functions stay on Lovable Cloud, the editor stays a managed service either way, and your monthly total barely moves.
-
Moving the backend to your own Supabase project is wrong if nobody on your side can send every existing user through a password reset and re-point your OAuth redirect URLs. Lovable’s migration guide is blunt about both: “You cannot export user passwords, so you need to trigger a password reset flow,” and “Managed OAuth configuration and automatic token refresh are only available when the backend runs on the built-in backend (Cloud).” The same guide tells you to add the new production domain to the authentication provider’s allowed redirect URLs, which is a change you make in Google’s or GitHub’s console, not in your app. What comes across and what you rebuild by hand owns that procedure end to end, including the fact that removing Cloud is permanent, and getting the database out owns the export file itself.
-
Running the whole thing on infrastructure you control is wrong if nobody answers at 3am. Lovable states the boundary plainly on its external hosting guide: “Lovable cannot monitor or debug production infrastructure it does not control.” A self-hosted backend hands you PostgreSQL operations, backups and disaster recovery permanently, which are shifts rather than tasks. For the ownership without the pager, the managed backend options are the middle position.
-
Rebuilding is wrong if the app already works and people are paying for it. It carries the largest synchronization and cutover burden, and it restarts every bug you have already found and fixed. Keep the old production app running beside the rebuild so traffic can return to it. That rollback gets harder once the two systems accept different writes, so define the data-sync boundary before cutover.
Read those four as a filter rather than a ranking. Most apps have exactly one exit still standing once you apply them honestly, and it is often not the one you were planning on.
Moving from Lovable to Replit or Bolt.new is not an exit
Wanting to migrate from Lovable to Replit, or from Lovable to Bolt.new, is a common instinct and worth being clear about. A lateral move changes the editor first. It may keep an external backend the repository already uses, or it may rebuild missing services on the destination. Before calling it an exit, compare who controls the repository, database, authentication, storage, hosting and deployment accounts in the actual destination.
The move is defensible when the destination has a capability you need and the resulting account map improves the constraint that made you leave. It does not solve lock-in when the same critical components simply move into another vendor-controlled account.
If the destination itself is the open question, the Lovable alternatives comparison does that work.
Who edits the code once you leave Lovable
The code comes out cleanly. Git sync puts it in your GitHub or GitLab repository continuously. Older projects use React and Vite. Lovable says projects created from 13 May 2026 use TanStack Start with server-side rendering. Confirm the stack in the repository before choosing what runs it.
The other surprise is what the exit does to your own working method. The editor and the AI agent are a managed service that cannot be self-hosted, so the moment the app lives somewhere else, the open question is what changes it now. Three honest answers exist. You keep prompting in Lovable and deploying elsewhere, which means you moved the hosting and kept the bill. You drive a coding tool yourself, which is what people mean when they ask about moving a Lovable app to Claude Code or Cursor, and which assumes you can read a failing build. Or a person takes the code over.
Nobody who is not a developer should meet that choice for the first time after the migration.
One trap sits inside the React and Vite branch. Environment values prefixed with VITE_ are embedded at build time rather than runtime, so pointing that app at a new backend requires a fresh build rather than a settings change. A TanStack Start project has a server runtime and must follow the environment contract in its repository. Why an environment value is baked into the build explains the exposure and redeploy rules.
Leaving does not fix the app you carry out
Whatever you move arrives with the test coverage, error reporting and failure modes it already had. In 26 production-readiness audits AxonBuild ran across June and July 2026, Reliability came out the weakest of the twelve pillars, averaging 31 out of 100 across the 21 third-party apps. In 17 of those 21, an error a user hit was recorded nowhere at all. At least 23 of the 26 had zero working automated tests, which is what makes any cutover frightening: nothing can be verified afterwards that was never verifiable before, and after the move the operational responsibility is yours too.
Common questions about migrating off Lovable
How do I move out of Lovable?
Decide which of the five parts you are moving before touching anything: the code, the hosting, the domain, the Cloud backend, or the editor. Get the code into a GitHub or GitLab repository you own first, because Git sync works at any time and nothing else is possible without it. Then take one of the four exits above and stop at the first one that solves the problem you actually have.
How do I migrate away from Lovable?
In this order: sync the code to your own Git repository, stand up the destination, move state, cut traffic over, and only then remove anything. State is the slow part, because schema and policies travel as code while data rows, storage objects and user accounts do not. Removing Lovable Cloud is permanent, so it happens last, after the destination has been tested as an application rather than as a database.
How do I migrate out of Lovable?
The same four exits, with two things you cannot take on any of them. Lovable documents that the editor and AI agent are a managed service that cannot be self-hosted, and that user passwords cannot be exported. A complete exit therefore means a new place to run the app, a new way to change the code, and a password reset for the whole user base before you switch traffic.
How do I transfer a website from Lovable?
For a marketing site with no accounts or data, this is the hosting move and the easy one: connect the repository to Vercel, Netlify or Cloudflare Pages, re-run the build, then point the domain and reissue the certificate. Lovable provides its own production hosting with custom domains and automatic SSL, so the only change is who serves the files. A site with logins, payments or stored data belongs in one of the three larger exits instead.
Can I move a Lovable app to WordPress?
Only if what you built is a brochure site. Converting a Lovable frontend into a WordPress theme moves pages and styling, and WordPress does not carry your Cloud backend, so accounts, data and payments stay behind. Most WordPress and Lovable material points the other way anyway, at using WordPress as a headless CMS behind a Lovable frontend, which is an integration rather than an exit.
Can I move a Lovable app to AWS?
Yes, and the vendor documents several AWS shapes. S3 with CloudFront or Amplify can be a frontend-only hosting move. ECS or EKS can run a frontend or a larger stack. An AWS move reaches the third exit only when the backend and database move there too. Classify it by the components moved and the AWS services operating them.
Does Lovable host websites?
Yes. Lovable’s documentation describes “Production hosting with custom domains, automatic SSL, and global delivery,” which is why many apps never leave: hosting is rarely the part that hurts. The Cloud backend and the credit meter usually are, and both belong to the second exit.
Ready to move off the builder?
We move your working app off the builder, keep what works, and set up the hosting, data, and release path needed afterward.
