How to Move a Lovable App to Your Own Backend (Step by Step)

To move a Lovable app to your own backend, you export the database (with auth users and their password hashes), restore it into the new backend, copy storage files, redeploy the edge functions with their secrets, then point the app's VITE_SUPABASE_URL and key at the new project and rebuild. If your Lovable project already uses your own Supabase project, the move is simpler: a migration tool can copy everything over a live connection. This guide covers both starting points, with the exact steps for moving to StitchDB, a hosted backend that speaks the same APIs as Supabase.

Lovable facts below come from Lovable's own documentation as of November 2026. Check their pages before you start, because the menus in builders change often.

#First, find out where your data lives

Open your project in Lovable and check which backend it uses:

• Lovable Cloud (the built-in backend, the default for new projects). You see the Database, Users and Storage views in the editor, and you have no Supabase project of your own.
• Your own Supabase project, connected through Lovable's Supabase integration. The project shows up in your Supabase dashboard and Supabase bills you.

The rest of the plan depends on this.

#Before you touch anything

1. Connect GitHub. Lovable syncs your code both ways with a GitHub repository; you will need the code outside Lovable. Lovable's docs say Git sync is available on all plans, while the codebase zip download needs a paid plan.
2. List what the app uses. Look in the repository for supabase/migrations/, supabase/functions/ and supabase/config.toml. Note every secret your functions read (Deno.env.get(...)), every OAuth provider you enabled, and any scheduled jobs.
3. List Lovable-only features. App connectors and AI features in your app run through Lovable and keep working only while the project uses the built-in backend. So do managed Google auth and SAML SSO. Each needs your own replacement, for example your own Google OAuth client ID.
4. Create the destination. Sign up and create an empty StitchDB project. The import refuses a project that already has tables, users or files.

#Route A: your Lovable app already uses your own Supabase project

This is the short route. StitchDB's Import from Supabase wizard reads your project through the Supabase Management API and copies:

• your schemas, tables, data, views, functions, triggers and RLS policies,
• auth users with their password hashes, so nobody has to reset a password,
• buckets, stored files and storage policies,
• cron jobs and the tables your app listens to with Realtime,
• Auth settings (site URL, redirect URLs, e-mail templates) and each sign-in provider's client ID,
• every edge function's code, deployed with its JWT setting.

Steps:

1. In the new project's Studio, open Database › Import from Postgres. Import from Supabase is the first tab.
2. Create a personal access token in your Supabase account, paste it and choose Find projects. Pick the project Lovable created.
3. Enter the project's database password. The Management API cannot read it; if you do not have it, reset it in the Supabase dashboard (this signs out other tools that use the old password).
4. Choose Check project. The check shows the Postgres version, size, tables, users, files, functions and secret names, plus anything that needs attention.
5. Fill in the secret values the wizard lists as NAME= lines, then Start live copy.

A live copy keeps the new database in sync with the old one, so your app keeps running on Supabase while the copy catches up. When Studio says Caught up, go to the switch-over below. If StitchDB cannot use the direct connection (it is IPv6 unless you have Supabase's IPv4 add-on), it falls back to a one-time copy and tells you so; stop writes before you start it.

#Route B: your app runs on Lovable Cloud

Lovable Cloud has no direct database connection to copy from, so you go through Lovable's export.

#1. Export the database

In Lovable, open More › Database › Manage › Settings and choose Export data, then in the Database card Export › Start export. Lovable e-mails you when it is ready, and you download the file from More › Storage. Lovable allows one export every 24 hours.

The file is a Postgres custom-format .backup archive with zstd compression, not plain SQL. You need a pg_restore build with zstd support. Look inside first:

pg_restore --list your-export.backup | head -50

Lovable's guide says users and their password hashes are in this export, so users can keep their passwords. Sessions do not carry over: everyone signs in once more.

#2. Restore it somewhere StitchDB can import from

Lovable's own guide restores the archive into a Supabase project. That is also the easiest bridge to StitchDB, because the Import from Supabase wizard then moves everything, including auth users, in one pass:

1. Create a temporary Supabase project and apply your supabase/migrations/ files in timestamp order.
2. Restore the data from the archive, following Lovable's instructions for schemas, roles and extensions that already exist. Test on a fresh project, and do not add --clean without reviewing it.
3. Run Route A from that project.

If you restore into a plain Postgres 12+ server you control instead, use the Import from Postgres tab with its connection string. That path is documented for the database part, so check the wizard's report for anything left over.

#3. Copy storage files

The database export does not include files. Download them from More › Storage in Lovable, then upload them into buckets with the same names. The S3-compatible endpoint works with ordinary tools (S3 access):

aws s3 cp ./avatars s3://avatars/ --recursive --profile stitchdb \
  --endpoint-url https://<project-ref>.p.stitchdb.com/storage/v1/s3

S3 access keys skip storage policies, so keep them on your machine and delete the key when the copy is done.

#4. Edge functions and secrets

Lovable does not export secrets. Copy each folder from supabase/functions/ into stitchdb/functions/, then deploy and set the secrets again:

npm install -g stitchdb-cli
stitchdb login
stitchdb init
stitchdb link --project-ref <project-ref>
cp -r supabase/functions/* stitchdb/functions/
stitchdb secrets set --env-file .env.production
stitchdb functions deploy

Functions that read the old variable names keep working: StitchDB passes the project URL and keys both as STITCHDB_* variables and under the names the Supabase stack uses. Recreate scheduled jobs that did not come over, and make sure the old and new copy never run the same job twice.

#The switch-over (both routes)

1. Point a test build at the new backend. Lovable's guide lists VITE_SUPABASE_URL, VITE_SUPABASE_PUBLISHABLE_KEY and VITE_SUPABASE_PROJECT_ID for the browser. Set the first two to your StitchDB values; browser variables are embedded at build time, so rebuild.

VITE_SUPABASE_URL=https://<project-ref>.p.stitchdb.com
VITE_SUPABASE_PUBLISHABLE_KEY=<anon key from Settings > API>

2. Test the paths that matter: sign-up, sign-in with each provider, reads and writes as two different users, uploads and every function.
3. Update OAuth providers. Add https://<project-ref>.p.stitchdb.com/auth/v1/callback as a redirect URL in each provider's console, next to the old one, and enter the client secrets under Authentication › Sign-in methods.
4. Freeze writes for a minute (maintenance mode), choose Switch over for a live copy, or take the final export and restore for Route B.
5. Deploy the production build and move your custom domain.
6. Keep the old backend for a while. Download and verify your exports before deleting anything; removing a Lovable database deletes it permanently.

#After the move

• Open Advisors and Exposure check in Studio. They list tables without RLS, views that bypass it and policies that let anyone write (advisors). Code generated by an app builder often needs a review here; see common mistakes in AI-generated RLS policies.
• Put the schema under version control: stitchdb db pull writes the current schema as your first migration.
• You can keep editing the front end in Lovable through GitHub sync. Backend changes now go through migrations instead of Lovable's backend tools.

#FAQ

#Do my users have to reset their passwords?

No, in both routes. Password hashes are part of Lovable's database export, and StitchDB's import copies auth users with their hashes. Users only sign in again because sessions are not copied.

#Can I export my data from Lovable Cloud at any time?

Yes, from the database settings, once every 24 hours. You get a Postgres custom-format archive. Single tables can also be exported as CSV from the table view.

#Can I keep building in Lovable after moving the backend?

The code, yes, through GitHub sync. Lovable's backend features (the in-editor Database view, managed auth, app connectors) only work with its built-in backend.

#How long does the move take?

For a typical app: an hour or two of preparation, the export or live copy, and a switch-over of minutes. The live copy route in StitchDB switches over in seconds once it has caught up.

Ready to move? Read the import guide and the compatibility notes, then create your project.