How to move a Lovable Cloud site toward your own Supabase

What is and isn’t currently possible

Lovable Cloud is Lovable’s built-in backend: a database, sign-in, file storage and server functions, built on Supabase’s open-source foundation, managed by Lovable and paid for in your workspace’s credits. A project connected to your own Supabase project is a different arrangement: the same kinds of services, but in a Supabase account you own, with its own dashboard and billing.

Lovable’s documentation is direct about moving between the two: there is no automatic migration between Cloud and your own Supabase project, in either direction. What Lovable documents instead is an export of the Cloud database, connecting a Supabase project of your own to a new Lovable project, and rebuilding the backend’s structure there from the migration files in your repository. Data is imported by hand, files are downloaded and re-uploaded, secrets are re-entered, and users are carried across without their passwords, so they reset them.

In plain English: this is partly an export and partly a rebuild, not a transfer. Calling it a migration would overstate it. It’s a well-trodden rebuild, because Cloud and Supabase share the same structure, but each piece below has to be moved or recreated on its own, and some of it is developer work.

Step 1: Is your project on Cloud, or on your own Supabase?

Open the project, then the More tab, then Cloud. If you see Lovable’s own tools there, with a Database, Users, Storage and SQL editor view and credit usage, the backend is Cloud. If the view shows a Supabase project’s name and status with links to the Supabase dashboard, the backend is your own Supabase project and this guide doesn’t apply: the backend is already yours, and the only things to check are the Supabase organization’s owner and billing, per the data guide. A project has one or the other; Lovable connects a project to a single Supabase project at a time, and offers the connection only on projects that don’t have a backend yet.

What you can move vs what you may need to recreate

Before you change anything

The realistic sequence

1. Create the Supabase project. Sign up at Supabase; your first account comes with an organization you own. Create a project in it, choose a strong database password, and keep it: it’s part of the connection string. Note the project URL and the publishable key from the Connect dialog.
2. Create a new Lovable project connected to it. Lovable’s documented route is a new Lovable project, with the Supabase project connected from the More, Cloud view. Import the existing repository’s code into it, or remix; either way the frontend code comes with its supabase/migrations folder.
3. Apply the structure. Paste the migration files into the new project’s SQL editor in order, or have a developer run Supabase’s CLI (supabase link, then supabase db push). Lovable also suggests asking the agent in the new project to rebuild the schema. This creates the tables, policies and storage buckets, empty.
4. Import the data. A developer restores the exported dump into the new project using Supabase’s backup-and-restore guidance (a psql restore of the data). Check row counts against the old project.
5. Redeploy the functions and re-enter the secrets. Below.
6. Reconnect sign-in. Below.
7. Upload the files. Below.
8. Test on the new project’s address before any domain change: pages, sign-up and sign-in, forms that write, uploads, functions, payments in test mode.
9. Switch the domain to the new project or the new host, per the domain guide.
10. Only then consider Remove Cloud on the old project, after the exports are downloaded and a couple of weeks have passed.

If you’re also leaving Lovable’s hosting, the exit guide puts this backend work in sequence with the frontend move. Lovable notes that the frontend can be hosted anywhere while the backend stays on Cloud, so the two moves are independent.

Users and sign-in: the part that needs care

User accounts are rows in the database, so their emails and profiles come across in the export. Their passwords don’t, not in a usable form, and Lovable tells you to plan a password reset flow for migrated users. That means every existing user sets a new password on first sign-in at the new backend. Tell them before the switch, and make sure the reset email works from the new project.

Supabase itself documents moving the auth schema, including hashed passwords, between two Supabase projects you control, so a developer might ask whether that route applies. Lovable’s stated position is that the Cloud export does not give you passwords in a usable form, and this guide follows Lovable’s documentation rather than assuming otherwise. Users who signed in with Google or GitHub have no password to reset; they need the provider’s redirect URLs pointed at the new project and the new project’s auth settings to list your site’s address.

Storage files

Buckets and their access rules are created by the migrations, but the files aren’t in any export. Download them from the Cloud storage view and upload them to the same-named buckets in the new project, then check that the addresses your site stores for them still resolve. Supabase documents a small script that copies objects between two projects using their service keys, which a developer can adapt for a large set.

Server functions and secrets

In plain English: a server function is a small piece of code that runs on the backend rather than in the visitor’s browser, for things like taking a payment or sending an email, and a secret is a key it needs to do that. Lovable shows each function’s code in the code editor. A developer deploys them to the new project with Supabase’s CLI, and enters the secrets under the project’s Edge Functions secrets, either one by one or from a file. Lovable never shows a saved secret’s value, so each is regenerated at the service that issued it. Any function that used Lovable’s built-in AI or email features needs a provider key of your own, because those ran on Lovable-managed credentials.

Keys, variables and redirect URLs

• The frontend reads VITE_SUPABASE_URL, VITE_SUPABASE_PUBLISHABLE_KEY and VITE_SUPABASE_PROJECT_ID from the committed .env file, and supabase/config.toml carries the project id. These change to the new project’s values. On a separate host they’re entered as environment variables too.
• Supabase’s current keys are named publishable (sb_publishable_…) and secret (sb_secret_…); older projects may show the legacy anon and service-role names, which Supabase says it is retiring by the end of 2026.
• OAuth providers need the new project’s callback address; the new project’s auth settings need your site URL and redirect URLs, which Lovable updates automatically only for Cloud.
• A different backend means a different JWT secret, so anyone signed in to the old backend is signed out.

When to bring in a developer or coding agent

You can do the export, the file download, the secret inventory and the Supabase sign-up yourself. Restoring the dump, deploying functions and running the CLI are developer tasks; a coding agent with access to the repository can do them if you paste Lovable’s and Supabase’s instructions and the connection details. The password reset and the sign-in provider changes are where mistakes lock people out, so test those with a throwaway account before the switch. If the site has real users and real orders, have someone who has done a Postgres restore before check the row counts.

Checklist

Sources

The rules and product behaviour described above were checked against these pages when the guide was last updated. If something here has changed, these are the places to look.

• Cloud · Lovable
• Supabase integration · Lovable
• Advanced settings: export project data, remove Cloud · Lovable
• External deployment and hosting · Lovable
• Deployment, hosting and ownership · Lovable
• Secrets · Lovable
• Storage · Lovable
• Edge functions · Lovable
• Authentication · Lovable
• Access control · Supabase
• Backup and restore using the CLI · Supabase
• Import data · Supabase
• Migrating auth users between projects · Supabase
• Deploy edge functions · Supabase
• Edge function secrets · Supabase
• API keys · Supabase