Lovable Cloud has no transfer button. Here is how you leave properly.

What you already own, and what you do not.

Start by being precise about where your app actually lives, because the parts that feel locked in are not the parts that are. Lovable syncs your source code to GitHub automatically: the frontend, your database schema migrations, your Edge Functions, and your Row Level Security policies. That repository is yours today, no permission required. If you have a GitHub connection, you already have the blueprint of the entire application.

What is not in that repository is everything the running backend is holding right now. Lovable Cloud is a Supabase instance, and three things exist only inside it: the rows in your tables, the objects in your Storage buckets, and your authenticated users. A migration is really a plan to move those three things onto a Supabase project you control. The code comes along for free.

The reason you cannot simply flip a switch is documented plainly in Lovable's own FAQ: there is no one-click transfer from Lovable Cloud to Supabase. What Lovable gives you instead are the pieces. An official database export, storage downloads that are separate from it, and a Remove Lovable Cloud button that permanently deletes the instance once you have moved out. Lovable's own guidance frames the exit in three phases, and this guide follows the same shape: own your data, own your hosting, then cut the cord. The order matters twice over, because each phase leaves you with a working app rather than a half-migrated one, and because the final step cannot be undone.

Own your data: schema, then rows, then files.

Create your own Supabase project first, on any plan. Then rebuild the structure from the migrations Lovable already pushed to your GitHub repo. With the Supabase CLI, linking and pushing recreates every table, RLS policy, function, and trigger in your new project:

supabase link --project-ref YOUR_NEW_PROJECT_REF
supabase db push

That gives you an empty copy of the correct schema. Now the rows. Once you have a direct Postgres connection string to the Lovable-managed database, a data-only dump and restore moves the content without touching the structure you just pushed:

supabase db dump --db-url "$LOVABLE_DB_URL" -f data.sql --use-copy --data-only
psql \
  --single-transaction \
  --variable ON_ERROR_STOP=1 \
  --command 'SET session_replication_role = replica' \
  --file data.sql \
  --dbname "$YOUR_DB_URL"

The session_replication_role = replica line tells Postgres to hold off on foreign-key checks and triggers while the copy loads, so the data lands in any order without tripping over itself. If you would rather restore schema and data together into a truly empty project, the full three-pass dump sequence is in our backups guide.

If you do not have a direct connection string, you no longer need one to get the rows out. Lovable ships an official export: in your project, go to the Cloud tab, then Overview, then Advanced settings, and under Export project data start a database export. Lovable emails you a temporary download link when it is ready. The export covers the full database, structure and data together, is limited to 5 GB, and you can request one every 24 hours. For a quick partial move you can also export individual tables as CSV from the Database tab. Whichever route you take, the shape of what you are moving is exactly what is above.

One thing no database dump carries: your Storage files. A dump copies the metadata rows that describe each object, not the objects themselves. Download the files from the source buckets and upload them into the matching buckets on your project as a separate step, and check that your bucket names and public/private settings match before you point the app at them.

Your users: the password catch that surprises everyone.

This is the step that turns a clean migration into a support incident, so plan it before you start. Supabase Auth stores a bcrypt hash of every password in the encrypted_password column of the auth.users table. If you can copy auth.users and auth.identities into your own project, your users keep their logins with the same email and password and never notice the move. Reuse the same JWT secret in the new project and even their existing sessions stay valid.

The catch on Lovable Cloud is that you generally cannot reach the auth schema to read those hashes out, which is exactly why Lovable states plainly that passwords cannot be transferred. So assume they will not come across, and design for it. Import your users by email address, then trigger a password-reset email to every user at cutover so each one sets a new password on first sign-in. The mechanics are a single admin call per user against your new project:

supabase auth admin create-user --email "user@example.com" --email-confirm
# then, at cutover, send each user a recovery link so they set a new password

The reset flow is the only migration step that touches your customers directly, so treat it as a launch, not a footnote. Send the reset emails as a deliberate, announced event, warm the support inbox for the questions that follow, and never let users discover the change by finding themselves logged out with no explanation.

Own your hosting, then cut the cord.

1. Point the app at your Supabase. Replace the backend config Lovable injected with your own project's values: the project URL and the publishable key in the browser, the secret key server-side only, never shipped to the client. While you are in there, rotate any key that ever appeared in client-side code, because moving house is the right moment to change the locks. Our exposed-keys runbook covers what to rotate and how.
2. Deploy the frontend somewhere you own. The frontend is already in your GitHub repo, so deploy it to Vercel, Netlify, or your own host. Lovable's own guidance is explicit that once you self-host the frontend, publishing through Lovable stops and you take over the develop-to-deploy flow. That is the point: your users now hit infrastructure you control.
3. Cut the cord. With your own Supabase and hosting live, and a sign-in and a write tested against the new backend, use Remove Lovable Cloud under the project's advanced settings to switch the old backend off. It permanently deletes the Cloud instance and cannot be undone, which is exactly why it is the last step and not the first: your export and your storage downloads must already be safe before you touch it.

Before you call the migration finished, run the checks the move does not do for you. A fresh Supabase project does not enable Row Level Security for you, so confirm it is on for every table (our RLS guide has the one-command check). Automated backups are now your responsibility, not the platform's, so set them up the same day you cut over, per the backups guide. And test one sign-in and one write against the new backend before you send the announcement. If a managed Supabase project still feels like someone else's server and you are tempted to run the stack yourself, read the self-hosting guide first: it is a real option for a real requirement, and a permanent job either way.