How do I host my Lovable app myself?
You can host a Lovable app yourself: sync the code to a GitHub repository you own, deploy it from there to a host such as Vercel, Netlify or Cloudflare, and, if you want the data under your name too, move the Lovable Cloud backend to a Supabase project in your account. Lovable documents all three steps. You do not have to rewrite the app; Lovable's own docs call the move "a deployment change rather than a rewrite".
The three parts move separately, and most of the work is in the third. The code comes out in minutes. The frontend takes an afternoon once you know which kind of Lovable app you have. The backend (database, user accounts, files, server functions, secrets, AI features and connected services) is where things break, because some of it does not export at all.
You can also stop halfway: move the frontend and keep Lovable Cloud, or move everything and keep building in Lovable through GitHub. Below is each step, what does not come with you, and when staying put is the better call.
In founders’ words
“Switching was not as easy as turning something off in Lovable and turning it on somewhere else.”
“I am a non-technical founder working on building a tool in Lovable and I've had feedback that institutions with strict security protocols would not consider purchasing as they do not trust Lovable in terms of security.”
“I've done the lovable to Vercel + supabase a couple of times, even managing to keep it syncing via the Git integration.”
The three parts of a Lovable app, and which ones you move
Lovable's docs describe every app as three independent parts. The code lives in Lovable and can sync to GitHub, GitLab or Bitbucket. The frontend, the pages people load, is served by Lovable hosting at your lovable.app address or your custom domain. The backend and data run on Lovable Cloud, which is built on Supabase.
Decide first what problem you are solving, because it decides how much you move. If a customer or investor wants the code in your account, syncing to GitHub is enough. If you need your own domain setup, hosting region or build pipeline, move the frontend. If the issue is who holds your customers' data, the credit meter on your database, or a security review that asks where records live, you are moving the backend, and that is the real project.
- Code only: Git sync. Free on every plan, minutes.
- Code and frontend: deploy from GitHub to a host you choose. Lovable Cloud keeps serving data, AI features and connectors.
- Everything: the frontend move plus Lovable Cloud to your own managed or self-hosted Supabase. Lovable says those are the only backend destinations it supports.
Export Lovable code to GitHub
Can you export Lovable code? Yes. Turn on Git sync in the project and Lovable creates a new private repository in your GitHub (or GitLab or Bitbucket) account. Git sync works on every plan, including Free; downloading the code as a zip file needs a paid plan. You cannot point Lovable at a repository you already have: it always creates a new one.
Sync runs both ways on one branch, usually main. Lovable commits each change it makes, and anything pushed to that branch shows up back in Lovable. That is what lets you keep building in Lovable after the app is hosted elsewhere. Lovable's docs warn against force-pushing, rebasing or squashing commits on the synced branch, because edits made only in Lovable can be lost.
The repository holds the code and the database migration files. It does not hold the records in your database or the files people uploaded. Those come out through the backend steps below.
Deploy a Lovable app to Vercel, Netlify or Cloudflare
First find out which kind of Lovable app you have, because the steps differ. Apps created from May 13, 2026 use a framework called TanStack Start, which runs code on a server. Older apps are React and Vite, which build to plain files. Open package.json in the Code tab: if it lists @tanstack/react-start, you have the newer kind. Or ask Lovable in chat which stack the project uses.
Older React and Vite apps go on any static host. Connect the repository, set the build command to npm run build, the output folder to dist and Node.js to version 22, and add the environment variables (VITE_SUPABASE_URL, VITE_SUPABASE_PUBLISHABLE_KEY and VITE_SUPABASE_PROJECT_ID). Add the rewrite that sends every address to index.html (a vercel.json file on Vercel, a _redirects file on Netlify or Cloudflare Pages), or any page other than the home page will show a 404 when someone opens it directly.
Newer TanStack Start apps need a host that runs the server part. Lovable's docs say Vercel, Netlify and Cloudflare Pages pick the right setup automatically from the repository, with the same build command and Node.js 22, plus the server-side Supabase variables. Following an old guide that only adds a vercel.json rewrite is a common reason a recent Lovable app shows 404s on Vercel. Such an app also cannot run from file storage or a CDN alone; a container or your own server works.
- Variables that start with VITE_ are baked into the build. Change one and you have to rebuild, not just restart.
- Add the new domain to the allowed redirect addresses for sign-in (Google, Apple, email links), or logins will bounce to the old address.
- Your lovable.app address keeps serving the version you last published there, and Lovable's Publish button keeps publishing only to Lovable. Decide which address customers use and point your custom domain at the new host last.
How to migrate Lovable Cloud to Supabase
Lovable says there is no one-click migration from Cloud to your own Supabase project. The route is an export, a restore and a reconnect. In Cloud's advanced settings, Export project data produces the full database, structure and records, including user accounts with their password hashes, so users keep their passwords. It does not include uploaded files, server function code or secrets. The limits are a 15 GB database, a 5 GB export file, and one export every 24 hours. The file is a PostgreSQL backup archive, not something you paste into the SQL editor.
Lovable's guide gives the order: create the destination Supabase project, apply the migration files from your repository, restore the data, set up sign-in providers again, copy storage files by hand, set secrets and deploy the server functions, point a test copy of the app at the new backend, check everything, and only then switch. Measure how long the export and restore take on the test run, because that sets how long you pause writes on the day.
Do not remove Cloud from the project until the new backend has run on real traffic for a while. Lovable's docs say removing it "permanently deletes your Cloud instance and cannot be undone". Moving the database on its own is not enough either: Lovable points out that a database move does not bring sign-in, file storage, realtime updates or server functions with it.
What breaks when you move a Lovable app off Lovable
Most moves fail on the things that were never in the code. Go through each of these before switch day.
- Connected services. Lovable's app connectors are not exported. Each one becomes your own integration with that provider.
- AI features. While the app uses Cloud, model calls run through Lovable's AI gateway and its credits. After the backend moves, they need your own account with an AI provider.
- Secrets. API keys and webhook secrets stored in Lovable are not in the export. Re-enter each one at the new host, and rotate any that were ever pasted into a prompt.
- Sign-in. Google, Apple and email sign-in are set up again at the destination, with new redirect addresses. Signed-in users have to sign in once more. Lovable's managed OAuth and automatic token refresh only exist on Cloud.
- Files. Uploaded images and documents are copied separately, into storage buckets with matching names and permissions.
- Payments. Your Stripe account is already yours, but the webhook address moves with the server code. Test a payment on the new setup before switching.
- Billing on Lovable. Lovable's docs say a code export or a domain change "does not cancel anything". Your plan and any Cloud usage continue until you change them.
Then there are the jobs Lovable was doing that nobody sees. Its own docs list what you take on when you leave entirely: build and release pipelines, servers and certificates, databases, backups and access controls, sign-in and data isolation, secrets and integrations, AI provider accounts and spending limits, monitoring and security reviews. None of them is exotic. Each needs an owner before customers depend on it.
Can you keep editing in Lovable after the move?
Yes, if you want to. Keep the repository connected through Git sync and let the new host deploy from it: Lovable edits and previews, and the other host serves the live app. Lovable's docs describe exactly this setup. If the backend stays on Cloud, AI features and connectors keep working too.
If the backend moves, update the project's environment file and Supabase settings to the new project as the last step, and Lovable keeps building against your own Supabase. A setup that works: Lovable for screens and quick changes, a coding agent such as Claude Code or Cursor for the rest, the repository as the one source of truth, and one tool editing at a time. What you cannot do is run Lovable's editor itself on your own servers; the docs say it cannot be self-hosted.
When you may not need to move
Lovable's own advice is to move parts "only when you hit a real constraint, not a hypothetical one", and for many apps that is right. If the app has few users, nobody pays yet, and no customer has asked where their data lives, turn on Git sync so a copy of the code is in your account, keep a recent database export, and stay. That covers most of the risk at almost no cost.
Move when there is a concrete reason: customers who need to know where their records are held, a security review Lovable Cloud cannot answer, a database bill tied to your build credits, terms you cannot accept, or an app that has to keep running while nobody is building. If the backend has to move and customers are already on the app, plan it as a project with a test run and a fallback. If you want a second opinion on whether to move at all, that is a good use of the free call below.
| Part of your app | How it moves | What to know |
|---|---|---|
| Code | Git sync to GitHub, GitLab or Bitbucket | All plans; zip download on paid plans; two-way on one branch |
| Frontend, older React and Vite app | Any static host: build with npm run build, serve dist | Needs the rewrite to index.html; VITE_ variables are fixed at build time |
| Frontend, TanStack Start app (from May 13, 2026) | A host that runs server code: Vercel, Netlify, Cloudflare Pages, a container or a server | Not file storage or a CDN alone |
| Database and user accounts | Export project data, restore into your Supabase project | Users keep passwords; 15 GB database limit; one export a day |
| Uploaded files | Copied by hand into matching storage buckets | Not in the database export |
| Server functions and secrets | Function code from the repository; secrets entered again | Secrets are never exported |
| AI features and connectors | Replaced with your own provider accounts | They run through Lovable until replaced |
| Domain and lovable.app address | Point your domain at the new host last | lovable.app keeps serving the last version published there |
Questions
Can I export Lovable code?
Yes. Git sync puts the code in a private repository in your own GitHub, GitLab or Bitbucket account on every plan, including Free, and keeps it in sync. Paid plans can also download a zip. The export is the code and migration files, not your data or uploaded files.
What's better, Lovable Cloud or Supabase?
They are the same technology: Lovable Cloud is built on Supabase. The difference is who holds the account. On Cloud, Lovable runs it and bills usage in credits from the same balance you build with. On your own Supabase project, you hold the account, the backups and the bill, and you do the setup and upkeep Lovable was doing. Cloud is fine for a young app; your own project is better once customers depend on the data.
Do my users have to reset their passwords after the move?
No. Lovable's export includes user accounts with their password hashes, so users keep their passwords. They do have to sign in again once, and Google, Apple and other sign-in options have to be set up again at the new project.
Does moving cancel my Lovable plan?
No. Lovable's docs say a code export or a domain change does not cancel anything. Your subscription and any Cloud usage continue until you change them, so cancel or downgrade only after the new setup has run on real traffic.
Can I run Lovable itself on my own servers?
No. The Lovable editor and agent are a managed service that cannot be self-hosted. The apps you build with it can be hosted anywhere.
Why does my Lovable app show a 404 on Vercel?
For an older React and Vite app, the host is missing the rewrite that sends every address to index.html; add a vercel.json with that rewrite. For an app created from May 13, 2026, the app runs server code, and the fix is a deployment that runs it, not a rewrite file. Check package.json for @tanstack/react-start to see which one you have.
First look, $750. After a free call, we read your whole product and tell you what is finished, what is not, and what to do first.
Setup, $3,000 fixed. We make it ready for real customers, in accounts you own.
Partner, $2,500 a month. We review what your coding agent writes and keep the checks and tests current. Month to month.