lovablePublished on 10/26/2026 · Heartscale team

How to leave Lovable: code, database and domain, step by step

Leaving Lovable is not a single button. It is three moves: the code, the database and the address. This guide follows Lovable’s official documentation (Deploying and hosting outside Lovable) and walks through each step.

Before you start: what leaves and what stays

Lovable says you own the code and the data you create, and that both can be exported (Deployment, hosting and ownership). But not everything comes along:

Leaves with you: the code (front end and functions), the database with its data, user accounts with their passwords, and uploaded files.
Stays behind: Lovable’s editor and AI agent, which do not run outside the platform.
Needs a replacement: app connectors and AI features that run through Lovable. They are not exported.

Another point from the docs: every part you take out becomes yours to maintain, secure and update. If cost is the reason for leaving, add maintenance time to the math.

Also decide whether you are moving only the site (the front end) or the backend as well. You can migrate only the front end and keep the database on Lovable Cloud for a while.

Step 1: get the code

There are two paths (GitHub and Deploying outside Lovable):

Git sync, on every plan. Under Project settings → Git, connect GitHub. Lovable creates a new repository, private by default, and syncs in both directions. It does not connect to an existing repository and syncs only one branch at a time, usually main.
Download codebase, on paid plans. It downloads a .zip of the code at that moment.

Prefer Git sync. It keeps the history and lets the new server deploy on every push.

Neither path brings the database data or the files your users uploaded. That is step 6.

Step 2: find out which stack you have

Open the repository’s package.json.

Does it include @tanstack/react-start? Then it is TanStack Start, the template for projects created from May 13, 2026 onward. It needs a running server, not just static files.
It does not? Then it is the older template, React + Vite. The build outputs static files to the dist/ folder, and any static hosting will serve them.

This difference changes everything from here on. Many guides online were written before TanStack Start and only cover the static case.

Step 3: run the build

Commands from Lovable’s docs:

React + Vite

npm ci
npm run build
# output in dist/

TanStack Start, for your own server or a container

npm ci
NITRO_PRESET=node-server npm run build
node .output/server/index.mjs
# listens on port 3000; PORT and HOST change that

If the repository only has bun.lock, use Bun, or generate and commit a package-lock.json before running npm ci. Use Node 22.

Step 4: set the environment variables

The values are in the project’s .env file. Variables starting with VITE_ are baked into the code at build time: if you change one, you have to build again.

In the browser: VITE_SUPABASE_URL, VITE_SUPABASE_PUBLISHABLE_KEY and VITE_SUPABASE_PROJECT_ID.
On the server (TanStack Start): SUPABASE_URL, SUPABASE_PUBLISHABLE_KEY, SUPABASE_PROJECT_ID and the functions’ secrets. The secrets are not in the repository. You will recreate them.

Step 5: put it on the server

Static site (React + Vite) on a VPS: copy dist/ to the server and configure Nginx to send every route to index.html:

location / {
  try_files $uri $uri/ /index.html;
}

Then add HTTPS, for example with Certbot.

TanStack Start: run the Node server from step 3 behind a reverse proxy that handles HTTPS. try_files does not apply here: the server handles the routes.

Docker: Lovable suggests a two-stage build, with node:22-alpine to build and nginx:alpine to serve dist/.

If you would rather have a dashboard than configure everything by hand, Coolify installs on a Linux VPS, deploys from GitHub and handles HTTPS.

Step 6: migrate the Lovable Cloud database

If the app uses Lovable Cloud, the supported destination is a Supabase project, either managed or self-hosted (Deployment, hosting and ownership). The order the docs suggest:

Create a new Supabase project and note its URL, ID and publishable key.
Apply the migrations in order: supabase/migrations/ (by the date in the file name) or drizzle/migrations/ (by _journal.json).
Export the data: More → Database → Manage → Settings → Export data. The file is a PostgreSQL .backup, not SQL. Restore it with pg_restore into a test project first. Do not use --clean without reading what it does: it drops objects.
Set up the login providers and redirect URLs again.
Copy the files from More → Storage into buckets with the same names.
Recreate the secrets and deploy the Edge Functions with npx supabase functions deploy.
Recreate the scheduled jobs. Do not let the same job run against both databases.
Point a test copy of the app at the new database and check it.
At cutover, update .env and the project_id in supabase/config.toml.

What the export includes and what it does not (Database backups):

Includes: database schema and data, user accounts and password hashes. Users keep their passwords. Anyone logged in at the moment of the switch has to log in again.
Does not include: storage files, Edge Function code, secrets, login provider settings and API keys.
Limits: databases up to 15 GB, files up to 5 GB and one export every 24 hours. A larger database requires contacting support.

The .backup contains password hashes and personal data. Store it somewhere safe and delete stray copies afterwards.

Step 7: test before you switch the traffic

The docs list four tests:

Open an internal route directly by its address and reload. A 404 error means the index.html fallback or the server is missing.
Log in and out of the app. A redirect error is usually the new URL missing from the login’s list of redirect URLs.
Read, write and upload a file.
On TanStack Start, open a server-rendered page and call a server function.

Step 8: switch the domain

Point the domain at the new server, following your provider’s DNS and certificate instructions. The lovable.app address keeps serving the last published version, and the Publish button keeps publishing only on Lovable.

Step 9: replace what stops working

Outside Lovable, these stop working (Deploying outside Lovable):

app connectors and AI features that run through Lovable;
chat connectors (MCP servers), which only exist in the project chat;
managed OAuth and automatic token refresh, which depend on Lovable’s backend.

Search the code for calls to these features and replace them with your own integrations. Lovable also does not monitor or debug a server that is yours.

Step 10: wrap up the move

Plan the final data copy. Pause user writes, jobs, webhooks and integrations. Run the last export, copy the changed files, restore, and only then switch.
Time the export and restore during the test, so you know how long the app will be down.
Unpublish the app on Lovable when you no longer want lovable.app online.
Before you remove the Lovable Cloud database, download and check the exports and the files. Removal deletes the database, backups, accounts and files, and cannot be undone (Lovable Cloud).
Remember that exporting the code cancels nothing. Your Lovable subscription and Lovable Cloud usage continue until you change your plan.

How long it takes

It depends on the size of the database, the number of integrations and how many Lovable features the app uses. A static site without a database is the simplest case: steps 1 to 5, 7 and 8. An app with login, files, functions and payments calls for a full test before cutover. Start with step 2: the stack tells you almost everything about the size of the job.

Order a Heartscale diagnostic

We have already migrated clients off Lovable, Wix and Tray. At Heartscale, the diagnostic maps what your app uses from Lovable, the size of the database, the integrations that need a replacement and the security risks that come along with the move. You receive a report with the migration plan and a fixed price.

The diagnostic costs US$ 79 and is credited toward the migration if you go ahead. We only work on apps whose owners can prove they own them.

Order the diagnostic for my app