Migrate Lovable to Supabase: moving off Lovable Cloud without losing users, files or secrets

To migrate Lovable to Supabase, take the database export before changing anything: the file can be at most 5 GB, and Lovable allows one request every 24 hours. It carries your tables and user accounts with password hashes, not storage files, edge function code, secrets or sign-in settings. Capture those, then point the app at a Supabase project you own.

Migrate off Lovable: four exits, and the triggers a move actually fixes

Migrating off Lovable has four exits, in escalating size: move only the frontend hosting, move the backend to a Supabase project you own, run everything on infrastructure you control, or rebuild. Pick by the constraint you can name, because three of the five usual triggers are not fixed by moving.

Lovable’s ownership docs split an app into three independent parts (code, frontend, and backend with its data), and the frontend and the backend can each move on their own; for the backend, the supported destinations are managed Supabase and self-hosted Supabase. The smallest exit is to move the app to your own hosting and leave the backend where it is, and deploying a Lovable app to Vercel walks through one host for that. The table runs from that smallest exit to the largest.

The run-everything exit has its own general order, which self-hosting an exported app on your own server covers step by step. Wanting to migrate from Lovable to Replit or Bolt.new is a lateral move rather than a Lovable exit: it trades one builder’s billing and export rules for another’s. If the aim is to migrate from Lovable for good, the choice is between the four rows above.

Five triggers, and the three a move does not fix

Most moves start with a symptom, and the symptom decides whether moving helps. The table puts each common trigger next to its usual cause; the first three rows are the ones a move usually leaves where they were.

When the enterprise ask is the app itself inside the customer’s environment, self-hosting a Lovable app for an enterprise customer is that exit in detail. What moving does not fix is everything that travels with the code: the same tests, the same error reporting and the same failure modes arrive at the new host. Moving also adds duties Lovable was doing for you, such as deployments, backups and certificates, and the release path a startup has to own sets those out as one pipeline. If the open question is money, what a Lovable migration costs prices the move itself.

What has to be true before you migrate Lovable to Supabase

A Lovable to Supabase migration carries the schema, policies, functions and buckets in your migration files, and the database export carries the rows and the user accounts with their password hashes. Storage files, secret values, sign-in provider settings and scheduled jobs each need their own step, and a check that proves they arrived.

The first three columns below follow Lovable’s external hosting and migration guide as it reads in October 2026. The last column is ours: the check we would want to see pass before calling a layer moved.

Two parts of the current setup do not move at all. Managed OAuth configuration and automatic token refresh exist only while the backend runs on Lovable Cloud, and app connectors and in-app AI calls keep running through Lovable until you replace them with your own provider accounts. The Cloud region is locked once Cloud is enabled, and existing projects cannot move between regions, so a contract that needs your data in another region makes the move mandatory rather than optional.

Lovable Cloud backend: the tools to inventory

The Lovable Cloud backend shows eleven areas in its Cloud view: Emails, Database, Users, Storage, Secrets, Jobs, Edge functions, SQL editor, Logs, Usage and Advanced settings; your app’s AI features sit in their own section of the More menu. Seven of the eleven, plus AI, are things to move or replace: emails, the database, users, storage, secrets, jobs and edge functions. The other four are the controls you use while you do it. Recount the areas in Lovable’s Cloud documentation on the day you plan.

The Lovable Cloud storage limit is not one number. Database storage starts at 8 GB, can only be increased, and can be changed up to four times in 24 hours; files upload at up to 2 GB each by default, adjustable to 5 GB. A total cap on file storage is not stated in Lovable’s Cloud docs. Lovable includes monthly Cloud grants on Free, Pro and Business plans and measures Cloud usage as part of run credits. Storage usage continues while a project is paused, because the data stays in place. The export limits are the ones in the first paragraph, plus one more: Lovable exports databases that use up to 15 GB of storage.

Lovable Cloud to Supabase migration tools: what they copy, and what to keep out of them

Four outside options for this move are named here, each in its own words. Staticbot says it reads Lovable’s official Cloud Data export directly: you point it at your GitHub-synced repository and a target Supabase project, and it restores the schema, RLS policies, triggers, data and the full auth schema with password hashes. Dreamlit describes a free, open-source exporter for tables, user accounts and storage files that works through a temporary migrate-helper edge function you add to the Cloud project, and its last steps tell you to remove that function and delete the secret API key you gave it. Nextlovable and lovablemigration sell the move as a service.

Our guidance for any helper that needs privileged access to either database: review the exact release you run, run it from a machine you control, and never paste a service role key, a secret key or a database password into a hosted form. Afterward, remove whatever it deployed and rotate every credential it touched. Password continuity is no longer a reason on its own to hand over that access, because Lovable’s own export now includes the password hashes. Supabase also documents moving the full auth schema, hashes included, between Supabase projects.

Before the cutover: capture everything and own every account

The week before the cutover is for capture and ownership: an export on your own disk, every storage bucket downloaded, the code in a repository you control, every secret name listed with the code that reads it, and every provider account moved into your name.

The export lands in the project’s own Cloud storage and arrives as an emailed link, and it cannot be downloaded after Cloud is removed, so the copy that counts is the one on your machine. Work through the list in this order:

1. 01 Record the project's region (the Database location row in Advanced settings), custom domains, sign-in methods and redirect URLs
2. 02 Export the database and save the file outside Lovable, on a disk and in a backup you control
3. 03 Download every storage bucket and keep the object paths; several files download as one zip archive
4. 04 Sync the code to a repository you control with Git sync, and check package.json for @tanstack/react-start to learn which stack the project uses
5. 05 List every secret name and the code that reads it
6. 06 List every outside system the app talks to: OAuth providers, payment webhooks, email, DNS, app connectors and AI features
7. 07 Set the write freeze, the cutover signal and the rollback condition, and time a test export and restore, because those times set how long writes stay paused

Projects created from May 13, 2026 (June 22, 2026 on Enterprise workspaces) run on TanStack Start and older ones on React and Vite, and on cutover day a TanStack Start project also reads a set of server-side variables.

Secrets: regenerate them, never copy them

Lovable secrets are write-only. The Secrets view lists each name and its creation date; after you save a value, it can never be viewed again in Lovable, only replaced or deleted. Names that start with SUPABASE_ or LOVABLE_ are reserved and filled in by Lovable, so the new Supabase project issues its own SUPABASE_ values, and a LOVABLE_ key for built-in AI gives way to your own provider account. Lovable’s Secrets docs say what to do when a key is lost: generate a new one at the service that issued it.

For each credential you created yourself, take the value from the provider or your password manager, or generate a replacement. Install it at the destination, deploy, test, and only then revoke the old one. The list of names from the capture step does double duty here, because an urgent rotation becomes harder when nobody knows which services depend on a key. The order per provider is in how to rotate API keys safely.

Move every account into your name

AI-built apps are often wired to accounts the builder created, and the business does not control what it does not own. Before cutover day, the new Supabase project, the hosting account, the domain registrar and the payment and email providers should each sit in an account the business owns, with the owner role.

If the step you need is to transfer a Lovable project to another account, Lovable offers three routes. Inside a workspace, Project settings, Project actions, Transfer ownership hands it to a member who is an owner, admin or editor; on Business and Enterprise plans you can also send the request to a Lovable account outside the workspace. Move workspace carries the project, with its history and settings, into another workspace. A remix into a new account copies the code and the database structure but not the records. None of the three gives you a Supabase project of your own: the backend stays with the project. The wider inventory, for when someone else set the accounts up, is in when a developer owns your hosting account.

Keep a restorable copy of the old database

The export on your disk is the rollback point, and it deserves a restore test before anything depends on it. Lovable’s file is a PostgreSQL custom-format .backup archive with zstd compression, not a SQL file you can paste into the SQL editor. Restore it into a scratch Supabase project before cutover day with a pg_restore build that supports zstd, since one without it can list the archive but not restore its data. Then count rows on the critical tables, and note how long the export and restore took: Lovable’s guide says those times set the length of the final write pause. Retention and an off-site copy for the new database are in the database backup checklist for startups.

Cutover day: the Lovable app migration in order

Cutover day runs in a fixed order: create the Supabase project, push the schema, restore the data and user accounts, set up sign-in, copy storage files, set secrets and deploy functions, test a separate deployment, then switch traffic while the old backend still answers. Sessions do not carry over, so everyone signed in signs in once more.

The steps below migrate Lovable Cloud to Supabase in the sequence Lovable’s guide gives, with the commands from its CLI section.

1. Create the destination project and note its URL, project ID and publishable key. Supabase’s Connect dialog shows the project URL and publishable key; Settings, API Keys lists every key.
2. Push the structure from the repository root with the commands below. A project whose migrations sit in drizzle/migrations/ applies them in their recorded order instead, because those files do not run through supabase db push.
3. Restore the data, user accounts included. Single tables can come out as CSV from the table’s view under More, Cloud, Database; the whole database comes from the full export, and exporting a Lovable project’s code and database holds the restore commands for that file.
4. Enable each sign-in provider and update the redirect URLs.
5. Copy storage files into the matching buckets. A Supabase Free project caps uploads at 50 MB, against up to 5 GB on Lovable, so check your largest file first.
6. Set each function’s secrets with supabase secrets set NAME=value, deploy the functions, recreate any scheduled job the restore did not bring, and replace app connector and AI calls.
7. Point a separate test deployment at the new backend through its environment variables, rebuild it, and leave the Lovable project unchanged until it passes.
8. Pause writes, take the final export, restore it, update .env and supabase/config.toml in the Lovable project, and move traffic.

npx supabase login
npx supabase link --project-ref your-new-project-id
npx supabase db push
npx supabase functions deploy

Drop npx if you installed the CLI with Homebrew. supabase db push needs the project linked first, and it records each migration in a history table once it applies, so a second run skips what already went in; the Supabase CLI reference also documents a --dry-run flag that lists the changes without applying them. Data goes in after the schema, never with it.

For the browser, a Lovable project reads three values, which Lovable’s guide prints like this for the .env file:

VITE_SUPABASE_PROJECT_ID="your-new-project-id"
VITE_SUPABASE_PUBLISHABLE_KEY="your-new-anon-key"
VITE_SUPABASE_URL="https://your-new-project-id.supabase.co"

A TanStack Start project also carries SUPABASE_PROJECT_ID, SUPABASE_PUBLISHABLE_KEY and SUPABASE_URL in the same file for its server code, and both stacks embed the browser values at build time, so every change needs a rebuild. The project ID also goes into supabase/config.toml as project_id. Records written after your export are not in it, which is why the final copy waits for the write freeze.

Missing supabase environment variable(s): supabase_service_role_key

The error reads: Missing Supabase environment variable(s): SUPABASE_SERVICE_ROLE_KEY. Connect Supabase in Lovable Cloud. It means code asked for the service role key and found nothing. On Lovable Cloud that name is reserved: Lovable fills it into the Edge Function environment, where functions can read it, and the Secrets view never shows its value, so a clone on your laptop or on a new host has nothing to read.

The fix depends on the exit. While the backend stays on Cloud, Lovable’s docs place the key in the Edge Function environment, so code that needs it runs there. On your own Supabase project, take the key from Settings, API Keys, and note that Supabase now calls service_role the legacy key: it is deprecating the anon and service_role keys by the end of 2026 in favor of publishable and secret keys. Supabase’s API keys docs say a secret key bypasses every Row Level Security policy and must never go into a browser, a shipped application or source control. In practice that rules out a VITE_ variable, a shared document and a migration vendor’s web form; the server-side secret store is the only home for it.

Authentication is its own cutover

The export carries user accounts with their password hashes, so users keep their passwords when you restore it into a Supabase project. The parts around the accounts do not travel. Sign-in provider settings and the project’s API keys are configured again at the destination, and each OAuth app (in Google’s console or GitHub, for example) needs its redirect URLs pointed at the new project URL. Sessions do not carry over, because the new project signs them with its own keys.

Supabase’s guide to moving auth users between projects describes the same hash-preserving route between two Supabase projects, and adds that existing tokens stop working when the new project’s JWT secret differs. Supabase links each sign-in method to the user as an identity that records its provider (email, phone, OAuth or SAML), so a count of identities per provider on both projects shows whether every way in came across. Test sign-in with a migrated account on every provider, a password reset, and an expired and a revoked session before traffic moves. Keep a reset flow ready anyway: Lovable’s guide says to fall back on one if the destination cannot restore the exported accounts.

The first week after: test the moved app as an application

The first week after a Lovable migration is for testing the app the way customers use it: two accounts trying each other’s data, sign-in and password reset, file uploads, every function and webhook, and a restore of the new database into a separate project.

A row count proves the rows arrived. Everything else on this list proves the application works, and each check is one you can run, fail and keep evidence for:

1. 01 Compare row counts on the critical tables with the export's snapshot time, then constraints, indexes, functions, triggers and RLS state
2. 02 Run sign-up, password reset, sign-in with a migrated account on each provider, sign-out, session refresh and a revoked session
3. 03 Sign in as user B and read and update user A's records through the public API: the read should come back empty and the update should change nothing
4. 04 Upload and fetch a private and a public file, signed URLs included
5. 05 Call every function with valid, invalid, duplicate and unauthenticated requests
6. 06 Send a test-mode event through payments, email, AI providers, webhooks and scheduled jobs
7. 07 Restore the new database into a separate project and check representative records

On the two-account check, an empty result is what a working policy returns, while a permission error points at a missing table grant rather than a policy doing its job. The full walk-through is in how to test Supabase RLS with two accounts.

The Production Hardening Sprint verifies three of these layers the same way. Deliverable 1.4 is verified by running read and write tests as anonymous users, different roles, and separate tenants. For deliverable 4.7, the check is to restore a backup into an isolated environment and check representative data integrity. The check for 7.11 is to deploy a fresh clone to staging through the pipeline with no step that depends on the generating tool.

Why the move forces a security recheck

A policy that exports cleanly as text is no evidence that it works on the new project. In our audits, 9 of the 21 third-party apps had row-level security gaps. Those 21 came from audits we ran in June and July 2026 and were picked rather than sampled at random, so read the count as a reason to test, not as a rate for Lovable apps in general. In the same audits, 6 of the 21 shipped a real secret, and three of the audited apps had one permanently in git history.

In one of our audits, an early version of a command-line AI tool wrote the live AI-provider key into its own config file and committed it. The project later moved to a .env file and deleted the config, but the key stayed readable in several past commits and was recovered by a full-history secret scan. The report’s fix was to rotate the key, because deleting the file is not a fix.

A key deleted from today’s files is still a working key in the history. Moving day is when every credential that ever sat somewhere shared gets rotated at its provider, not reinstalled unchanged in the new project.

What to do if the cutover fails

A failed cutover is reversible only while Lovable Cloud still exists. Keep it running, unchanged, until the destination passes every check, because removing Cloud deletes the instance permanently and the exports stored inside it go with it.

Write the rollback condition before cutover day: the traffic switch you will flip back, the most writes you accept losing after the freeze, and the signal that sends traffic back. If that signal fires, point traffic and the .env values back at the old backend while Cloud still answers.

To disable Lovable Cloud there are two controls, pause and remove, both under More, Cloud, Overview, Advanced settings. Pause keeps the data, makes the backend unavailable so the published app cannot read or write until you click Wake up, and storage usage keeps accruing. Remove asks you to tick two boxes and type the project’s display name, then permanently deletes the Cloud instance; exports saved in Cloud storage can no longer be downloaded afterward. The move is also one-way for now, because Lovable does not currently support migrating from Supabase back to Cloud.

How to disable Lovable Cloud safely is mostly a question of timing: only after the first week’s checks pass, only with every export and bucket on your own disk, and only when no workflow still calls its URL. Lovable’s Advanced settings docs hold the current click path. What else tends to break on the way out of a builder, such as logins, files and GitHub sync, is in what breaks when you migrate off a builder.

Where the sprint fits

If you need a vendor to migrate your Lovable prototype to a real backend because a launch, an investor review or a customer’s security review depends on it, the move is usually one part of a bigger job. That job includes moving every service the product depends on (database, hosting, payments, email, AI, domain) into an account the founder owns, and keeping the application in a version-controlled repository and on a hosting account the founder controls, deployable through a documented pipeline, independent of the tool that generated it. We do that job through the published 123-point scope. Before you set a cutover date, spend 30 minutes on a free audit: on a video call we walk through your Lovable setup with you and weigh up the exit you are leaning toward.

Your app’s current framework and hosting setup are our starting point, and we refactor or replace components where the production work requires it. Hosting, paid tools, and API usage remain in your accounts.

Common questions about leaving Lovable Cloud

Does supabase db push run migrations in a transaction?

Supabase’s CLI reference does not say whether supabase db push wraps each migration in a transaction. What it does say is that a migration is written to the history table only after it applies successfully, and that later pushes skip the ones already recorded. So if a push stops partway, check the destination for missing tables before loading any data, and use supabase migration repair only to bring the history table back in line with what actually exists.

What are the environment variables used in Supabase?

A Supabase app needs its project URL and a key: the publishable key in anything that reaches a user’s device, and a secret key only on a server. A Lovable app names them VITE_SUPABASE_URL, VITE_SUPABASE_PUBLISHABLE_KEY and VITE_SUPABASE_PROJECT_ID for the browser, with unprefixed SUPABASE_ copies for a TanStack Start server. Inside Supabase’s edge runtime, SUPABASE_SERVICE_ROLE_KEY still exists but carries the legacy key.

Can Lovable create a backend?

Yes. Lovable Cloud is its built-in backend, with a database, storage, authentication, realtime and functions, and Lovable manages that infrastructure for you. The tables, accounts and files it creates stay on that managed backend until you export them and move them yourself.

How do I remove a Lovable account?

Go to Account settings, Account, Danger zone and select Delete account. Lovable first asks you to hand over or delete any workspace where you are the only owner, then finalizes the deletion after a 30-day grace period in which you can log back in and cancel; after that the account and its data are permanently removed. Download every project’s database export and storage files first.