How to export a Lovable project and run it without Lovable

Sooner or later most people building on Lovable want their code somewhere they control. Sometimes it is for a backup. Sometimes a developer is joining. Sometimes the app has outgrown what a builder is good at, and it needs its own hosting, background jobs or a proper deployment process.

I have moved a Lovable project off the platform and onto a client's own accounts, and I rebuilt another, PropVPS, into a production platform. Getting the code out is the easy part, and Lovable makes it easy on purpose. What catches people out is everything the download does not contain.

What are the two ways to export a Lovable project?

Git sync connects the project to a repository on GitHub, GitLab or Bitbucket. It is a two-way sync: changes made in Lovable are pushed to the repository, and changes pushed to the active branch come back into Lovable. Syncing to github.com is available on every plan.

Download codebase gives you a ZIP file. You will find it in Project settings under Git, or at the bottom of the file tree in the code editor. It needs a paid plan, and it is a snapshot: nothing stays in sync afterwards.

If a developer will ever touch the project, use Git sync. A repository gives you history, branches and a way back when something breaks. A ZIP gives you a folder.

1. Connect your Git provider

   In Project settings, open Git and connect your GitHub account or organization. Let Lovable create the repository, rather than making one first.

2. Open the repository

   Use the link in the same panel to view it on GitHub. Your whole project is there, with a commit for each change Lovable made.

3. Clone it

   Copy the repository address and clone it to your machine, or download a ZIP from GitHub's Code button if you only want a copy.

Lovable documents both routes in its Git sync guide.

What do you actually get, and what is missing?

You get a standard Vite and React project, written in TypeScript and styled with Tailwind. There is no proprietary framework, so any front-end developer can read it on the first day.

What you do not get is the part Lovable was running for you.

This is why an exported app so often shows a blank page or a wall of errors on the first run. The code is fine. It is looking for a backend that is not there yet.

How do you run it on your own machine?

Install Node.js, open the project folder, install the dependencies and start the development server. The README in the repository gives the exact commands.

Then point it at a backend. Find where the app creates its database client, which in Lovable projects is usually a small file under src/integrations, and look at the address and public key it uses. Move both into environment variables, so that your local copy, previews and production can each talk to a different backend. Any key that must stay secret belongs on the server side, never in a value that ships to the browser.

How do you move the backend?

This is the step that takes care. A Lovable project usually keeps its data either in Lovable's built-in backend or in a Supabase project you connected. Either way it is a Postgres database with login and file storage around it, and Lovable's ownership and portability guide confirms that schemas and data can be exported.

Work through it in this order.

1. Create your own backend project, in an account your company owns rather than a contractor's.
2. Move the schema first, then the data. Check that every table arrived with its access rules, not only its columns.
3. Recreate login. Email settings, social sign-in providers, and above all the redirect addresses, which still point at the old Lovable URL.
4. Move the secrets. Payment, email and AI keys go into your host's settings. Rotate any key that has ever appeared in front-end code.
5. Deploy the server functions and point any webhooks, such as Stripe's, at their new addresses.
6. Copy uploaded files and check which storage buckets are public.

Where can you host it?

Because it is a standard front-end project, almost anywhere: Vercel, Netlify, Cloudflare Pages, or a server of your own. Lovable describes the options in its guide to hosting outside Lovable.

Three things need attention on any host.

• Routing. It is a single-page app, so the host must send every path to index.html. Without that, refreshing any page other than the home page returns a "not found" error.
• Environment variables. Set them in the host's dashboard, separately for preview and production.
• The domain. Point the DNS records at the new host, wait for the certificate, and only then remove the domain from Lovable.

If search traffic matters to you, this is also the point to ask whether a client-rendered app is the right shape for your public pages. On PropVPS the customer portal is a React app, while the marketing site runs on Next.js with a headless CMS, which serves complete pages to search engines.

Should you keep using Lovable afterwards?

Often, yes. Exporting is not leaving. With Git sync in place, a founder can keep shaping screens in Lovable while an engineer works on payments, security and background jobs in the repository.

It works as long as two rules hold. Decide which parts of the code each person owns, and treat the repository as the source of truth, so every change is reviewed before it reaches customers.

When is it worth bringing in an engineer?

The export itself rarely needs one. The move usually does when any of these is true: the app takes payments, it holds personal or sensitive data, it needs work that runs longer than a page request, or real customers are already using it and downtime would cost you.

That is the work I do under prototype to production: keep the screens and flows that work, and rebuild the parts that handle money, data and secrets. If you are deciding what has to change before launch, start with what actually has to change in a Lovable prototype.