--- title: "Migrating from Lovable Cloud to your own Supabase | Lovable Field Guide" description: "There is no one-click Lovable Cloud to Supabase migration. The honest manual runbook: export, schema, RLS, edge functions, storage, secrets, auth and rollback." lang: en json-ld: | { "@context": "https://schema.org", "@graph": [ { "@type": "WebSite", "@id": "https://prerenderlovable.com/#website", "url": "https://prerenderlovable.com", "name": "The Lovable Field Guide", "description": "A working journal on Lovable SEO: getting apps built with Lovable indexed, ranked and cited, plus the migration and integration work that comes with it.", "publisher": { "@id": "https://prerenderlovable.com/#organization" }, "inLanguage": "en" }, { "@type": "Organization", "@id": "https://prerenderlovable.com/#organization", "name": "The Lovable Field Guide", "url": "https://prerenderlovable.com" }, { "@type": "BlogPosting", "@id": "https://prerenderlovable.com/blog/lovable-cloud-to-supabase#article", "headline": "Migrating from Lovable Cloud to your own Supabase", "description": "There is no one-click Lovable Cloud to Supabase migration. The honest manual runbook: export, schema, RLS, edge functions, storage, secrets, auth and rollback.", "datePublished": "2026-09-11T00:00:00.000Z", "dateModified": "2026-09-11T00:00:00.000Z", "inLanguage": "en", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://prerenderlovable.com/blog/lovable-cloud-to-supabase" }, "author": { "@type": "Organization", "name": "The Lovable Field Guide", "url": "https://prerenderlovable.com" }, "publisher": { "@id": "https://prerenderlovable.com/#organization" }, "keywords": "lovable cloud to supabase, migrate off lovable cloud, lovable cloud migration, export lovable cloud database, move lovable database to supabase", "articleSection": "Migration" }, { "@type": "BreadcrumbList", "@id": "https://prerenderlovable.com/blog/lovable-cloud-to-supabase#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://prerenderlovable.com/" }, { "@type": "ListItem", "position": 2, "name": "Migration", "item": "https://prerenderlovable.com/migration" }, { "@type": "ListItem", "position": 3, "name": "Migrating from Lovable Cloud to your own Supabase", "item": "https://prerenderlovable.com/blog/lovable-cloud-to-supabase" } ] }, { "@type": "FAQPage", "@id": "https://prerenderlovable.com/blog/lovable-cloud-to-supabase#faq", "mainEntity": [ { "@type": "Question", "name": "Is there a one-click migration from Lovable Cloud to Supabase?", "acceptedAnswer": { "@type": "Answer", "text": "No. Lovable's Supabase integration documentation states plainly that there is no one-click migration from the built-in backend (Cloud) to Supabase or the other way around. The move is manual: export your data, create your own Supabase project, recreate the schema and policies, redeploy functions, re-upload storage objects and re-enter every secret." } }, { "@type": "Question", "name": "Can I migrate from my own Supabase back into Lovable Cloud?", "acceptedAnswer": { "@type": "Answer", "text": "No. As of September 2026 Lovable's Cloud documentation says migration from Supabase to Cloud is not supported. Plan the Cloud-to-Supabase direction as one-way." } }, { "@type": "Question", "name": "Do my users keep their passwords after migrating off Lovable Cloud?", "acceptedAnswer": { "@type": "Answer", "text": "Plan for no. Migration write-ups report that Lovable does not export password credentials in a form that keeps sign-in working, and that the recommended path is a password reset for every user. Test with a throwaway account whose password you recorded before you commit to a cutover date." } }, { "@type": "Question", "name": "Are edge functions included in the Lovable Cloud database export?", "acceptedAnswer": { "@type": "Answer", "text": "No. The database export contains your data and nothing else. Function source comes out with your codebase through Git sync or a ZIP download, and you deploy it to your own Supabase project yourself with the Supabase CLI. Function secrets are not included either and must be re-entered." } }, { "@type": "Question", "name": "Is removing Lovable Cloud reversible?", "acceptedAnswer": { "@type": "Answer", "text": "Treat it as permanent. Removal does not move any data for you, so it belongs at the very end of a migration, after you have verified row counts, row-level security, a real sign-in, every function and a sample of storage objects against the new backend." } }, { "@type": "Question", "name": "Can I keep using the Lovable editor after moving to my own Supabase?", "acceptedAnswer": { "@type": "Answer", "text": "Yes. Leaving Lovable Cloud is not the same as leaving Lovable. Lovable supports projects that connect to your own Supabase project: a workspace owner links a Supabase organization, then individual projects connect to a Supabase project inside it." } } ] }, { "@type": "HowTo", "@id": "https://prerenderlovable.com/blog/lovable-cloud-to-supabase#howto", "name": "Migrate a Lovable Cloud backend to your own Supabase project", "step": [ { "@type": "HowToStep", "position": 1, "name": "Export the Cloud data", "text": "In the Lovable editor's Cloud tab, under Overview then Advanced settings, run the export. Open the archive and confirm what it actually contains before you plan around it." }, { "@type": "HowToStep", "position": 2, "name": "Create and connect your Supabase project", "text": "A workspace owner or admin links a Supabase organization to the Lovable workspace, then anyone with edit access connects a Lovable project to a Supabase project inside that org." }, { "@type": "HowToStep", "position": 3, "name": "Recreate schema, RLS and triggers", "text": "Link the Supabase CLI to your project and apply the migration files from your repo, or restore a SQL dump with ON_ERROR_STOP=1. Then query pg_tables and pg_policies to confirm row-level security came across." }, { "@type": "HowToStep", "position": 4, "name": "Restore data and count it exactly", "text": "Run an exact count(*) on both sides for every table that matters. Dashboard estimates from pg_stat_user_tables drift after bulk loads." }, { "@type": "HowToStep", "position": 5, "name": "Redeploy edge functions", "text": "Function source comes out with your code export. Deploy each one with supabase functions deploy, then invoke it against the new project and read the response body." }, { "@type": "HowToStep", "position": 6, "name": "Re-upload storage objects", "text": "Copy every object from the source bucket to the destination using its full path, then find and replace any signed URLs stored in your database rows." }, { "@type": "HowToStep", "position": 7, "name": "Re-enter every secret", "text": "Lovable secrets are write-only and cannot be exported. Re-issue each credential at its source provider and install it on the destination with supabase secrets set." }, { "@type": "HowToStep", "position": 8, "name": "Plan the password reset", "text": "Test sign-in with a throwaway account whose password you recorded before export. Expect to send every user a password reset and write that email before cutover day." }, { "@type": "HowToStep", "position": 9, "name": "Repoint the invisible infrastructure", "text": "Re-create scheduled jobs, issue fresh OAuth credentials with the new callback URL, update every inbound webhook endpoint, and fix hardcoded project URLs in the repo." }, { "@type": "HowToStep", "position": 10, "name": "Verify, then remove Lovable Cloud", "text": "Work through the verification checklist first. Removal is permanent and moves no data, so do it last." } ] } ] } --- [Skip to content](#main) [Lovable Field Guide ](/) [SEO](/seo)[Migration](/migration)[Integrations](/integrations)[All posts](/blog) [Start here](/blog/lovable-seo) [SEO](/seo)[Migration](/migration)[Integrations](/integrations)[All posts](/blog) 1. [Home](/) 2. / [Migration](/migration) 3. / Migrating from Lovable Cloud to your own Supabase # Migrating from Lovable Cloud to your own Supabase There is no one-click Lovable Cloud to Supabase migration. The honest manual runbook: export, schema, RLS, edge functions, storage, secrets, auth and rollback. Published September 11, 2026 · 14 min read There is no one-click migration from Lovable Cloud to your own Supabase project, and there is no migration back. Lovable’s own Supabase integration page says it: there is no one-click migration from the built-in backend to Supabase or the other way. The Cloud page adds that migration from Supabase to Cloud is not supported at all. So this is a manual job, it is one-way, and the order you do it in decides whether it hurts. This is the hardest migration in the Lovable ecosystem, harder than [getting your code out of Lovable](/blog/lovable-migration), because code is the one layer that actually exports cleanly. Everything else (rows, users, buckets, secrets, scheduled jobs, OAuth callbacks) either comes out in pieces or does not come out at all. **The short version:** 1. Export your Cloud data. Verify the file before you plan anything around it. 2. Create your own Supabase project and link it at the workspace level first. 3. Recreate schema, then row-level security, then triggers and functions. 4. Restore data. Compare exact row counts. 5. Redeploy edge functions by hand: they are not in the database export. 6. Re-upload storage objects. Signed URLs stored in your rows are dead. 7. Re-enter every secret from the source provider. Nothing in the secret store exports. 8. Tell your users they will need to reset their passwords. 9. Repoint cron jobs, OAuth redirect URIs and inbound webhooks. 10. Verify everything, then, only then, remove Lovable Cloud. ## What Lovable Cloud actually is[#](#what-lovable-cloud-actually-is) Cloud is the managed backend bundled with Lovable hosting: database, authentication, storage, realtime and edge functions, with no infrastructure setup. Lovable’s documentation describes it as built on Supabase’s open-source foundation, and Lovable’s docs say it is enabled by default for your workspace. Here is the part that catches people. Being built on Supabase’s foundation does not give you Supabase. You get no Supabase account, no organization, no project, no dashboard login. Everything happens inside the Lovable editor’s Cloud tab: a database viewer for tables, records, security policies and backups, a SQL editor, users and auth, storage buckets, secrets, jobs, edge functions, logs and usage analytics. There is no `db..supabase.co` you can point `psql` at and no project ref you can hand to the Supabase CLI. That architectural detail is the whole reason the migration is manual. You are not moving a project between two accounts on one platform. You are reconstructing a backend on a platform you now have credentials for, from artifacts a platform you do not have credentials for hands you. Which stack are you on? Lovable changed its default stack on 13 May 2026, from React + Vite to TanStack Start with server-side rendering on Cloudflare Workers. On the older stack, server logic lives in separately deployed edge functions. On the new stack, it lives in the app as TanStack server functions created with `createServerFn`. Check `package.json` before you start, if you see `@tanstack/react-start`, “redeploy your edge functions” means something different for you, and some of your server logic ships with the frontend instead. ## The official path, and where field reports disagree with it[#](#the-official-path-and-where-field-reports-disagree-with-it) Lovable documents exactly one Cloud-to-Supabase route: export your Cloud data, create a **new** Lovable project, connect a Supabase project to that new project, and rebuild the schema there. Note the catch: you end up with a new project. Your original project’s history, chat context and published URL stay behind. Remixing a Cloud project does not help either; a remix of a Cloud project is just another Cloud project. At least one third-party migration guide describes a different shape: remove Lovable Cloud from the existing project and then connect your own Supabase to that same project. If that works it is obviously the better outcome, because you keep the project. But it is not the path Lovable’s own docs describe, and the removal step is irreversible, so you would be betting the project on third-party reporting. As of September 2026 I would treat the new-project route as the supported one and ask Lovable support in writing before relying on the in-place swap. Gotcha Whichever route you take, removing Lovable Cloud comes **last**. Removal is reported to be permanent and it does not move any data for you. Anything still living only in Cloud when you press that button is gone. ## Pre-flight checklist[#](#pre-flight-checklist) Do all of this before you export anything. - **Get your code out first.** [Git sync](https://encited.com/blog/lovable-export-to-github) or a [ZIP download](https://encited.com/blog/how-to-download-your-lovable-project-code-without-github). Your edge function source, migration files and client config all live here. If you have not done this, start with [downloading your Lovable code](/blog/download-lovable-code). - **Measure your database.** Third-party migration write-ups report a 5 GB ceiling on Cloud exports and a limit of one export request per 24 hours, with Lovable directing anyone above the cap to support. That throttle is the important half: a botched export costs you a full day before you can retry. - **Inventory your secrets by name.** You cannot read their values (see below), so the inventory is a list of names plus which provider issues each one. - **List every storage bucket** and roughly how many objects each holds. - **List every scheduled job**, every OAuth provider, and every third party that sends you a webhook. - **Create a throwaway user account and write the password down.** This is your auth canary. After the restore, try to sign in as that user against the new project. It is the only honest test of whether credentials survived. - **Rehearse.** Restore into a scratch Supabase project first. Because of the 24-hour export throttle, you want your restore script debugged before the export you actually cut over with. Tip Do not ask the Lovable agent to migrate your database entity by entity. Every message costs credits, and a backend of any size turns into a long, expensive conversation. Once your code is synced to Git, do the schema work locally with `psql` and the Supabase CLI, or with your own coding agent against the repo. It is faster and it is not billed per message. ## Step 1: export the Cloud data[#](#step-1-export-the-cloud-data) Since July 2026 there is an official export action in the Lovable editor under the Cloud tab, in Overview → Advanced settings, alongside pause and remove. Export, then **open the file before you plan anything around it**. Lovable’s docs do not spell out the archive format in a way I can verify as of September 2026, and your restore strategy depends entirely on what you actually got: a SQL dump restores differently from per-table CSVs. Check specifically: - Does it include the `auth` schema, or only your `public` tables? - Are row-level security policies, triggers and database functions in there, or only table data? - Are storage **objects** included, or only the `storage.objects` metadata rows? Whatever is missing from that list is work you now own. In practice, plan on the export being data (it contains no application code whatsoever) and on everything else being rebuilt from your repo by hand. ## Step 2: create your Supabase project and connect it[#](#step-2-create-your-supabase-project-and-connect-it) Connecting your own Supabase to Lovable is a two-level flow, and people trip on the first level because it happens at the workspace level. 1. A workspace **owner or admin** links a Supabase **organization** to the Lovable workspace. This makes it available to everyone in the workspace. 2. Anyone with edit access then connects a specific Lovable **project** to a Supabase **project** inside that linked org. Individual team members do not each need their own Supabase account once the org is linked. If you are a developer without workspace-admin rights, step 1 is not yours to do, and finding that out mid-migration is a bad time. Once connected, Lovable writes SQL migrations for you: it writes the SQL, shows it to you, and asks for approval before running it, and the migration files are saved into your project code. That last detail matters: your schema becomes version-controlled artifacts in the repo rather than clicks in a dashboard you cannot see. ## Step 3: recreate schema, RLS and triggers, in that order[#](#step-3-recreate-schema-rls-and-triggers-in-that-order) Order matters because policies reference tables and triggers reference functions. ``` # Link the CLI to your own project (project ref is in the Supabase dashboard URL). supabase link --project-ref abcdefghijklmnopqrst # Apply the migration files Lovable wrote into your repo. supabase db push # Or, if you are restoring a plain SQL dump, stop at the first error # rather than discovering half a schema later. psql "$DST_DB_URL" -v ON_ERROR_STOP=1 -f schema.sql ``` Then prove the security model came across, because this is the layer that fails silently and expensively: ``` -- Every public table should have rowsecurity = true. select tablename, rowsecurity from pg_tables where schemaname = 'public' order by tablename; -- And RLS enabled with no policies is a locked door, not a secure one. select schemaname, tablename, policyname, cmd, roles from pg_policies where schemaname = 'public' order by tablename, policyname; ``` Tables with RLS enabled and no policies reject everything; enabled-with-a-permissive-`true`\-policy tables allow everything. Both look identical from a row count. Test with two real accounts (user A must not be able to read user B’s rows) before you go anywhere near cutover. ## Step 4: restore data and count it properly[#](#step-4-restore-data-and-count-it-properly) After the restore, do not trust the dashboard’s table sizes. Postgres’s cheap counts are estimates: ``` -- Fast but approximate. Fine for spotting a table that restored as empty. select relname, n_live_tup from pg_stat_user_tables order by relname; ``` For anything that matters (users, orders, anything you would have to apologize for losing) run an exact `count(*)` on both sides and diff the numbers. Estimates drift after bulk loads and will happily tell you a table is fine when it is short by thousands of rows. ## Step 5: redeploy edge functions by hand[#](#step-5-redeploy-edge-functions-by-hand) The database export contains no deployed server code. Your function source comes out with your codebase; the deployment and its configuration do not come out at all. Those are two different artifacts from two different places, and the second one is manual. ``` # Deploy each function to your own project. supabase functions deploy send-contact-email --project-ref abcdefghijklmnopqrst # Confirm what is actually live, rather than what you meant to deploy. supabase functions list --project-ref abcdefghijklmnopqrst ``` Two traps here. The first is verification theater. A function that deploys is not a function that works: it still needs its secrets, its database grants and its CORS headers. Invoke every single one against the new project and read the response body as well as the status code. Second comes replication back into Lovable. If you create temporary helper functions during the migration and your project is Git-synced, those helpers can flow back into Lovable and end up deployed somewhere you did not intend. Delete scratch functions from the repo when you are done with them. ## Step 6: re-upload storage, and hunt down dead signed URLs[#](#step-6-re-upload-storage-and-hunt-down-dead-signed-urls) This is the most deceptive step in the whole migration, because the database restore reports success, your row counts match, and your app still shows broken images. What happens is that rows containing object paths restore perfectly while the objects themselves were never copied. Every linked file returns 404. Storage objects have to be downloaded from the source and uploaded to the destination as a separate operation. Recent Supabase CLI versions have gained storage commands, so check `supabase storage --help` on your installed version first. If it is not there, script it: ``` // Node script, run with SUPABASE keys in the environment. // The DESTINATION side is straightforward: your own project, your own // service-role key. The SOURCE side is the constraint: Lovable Cloud does // not hand you a service-role key, so `srcDownload` below has to be whatever // read path you actually have: objects included in the official export, or an // authenticated download route through your own deployed app. Resolve that // question before you schedule a cutover. import { createClient } from '@supabase/supabase-js' const dst = createClient(process.env.DST_URL, process.env.DST_SERVICE_ROLE_KEY) // `prefix` is the folder you listed, '' at the bucket root and otherwise // ending in a slash, e.g. 'avatars/'. `storage.list()` returns `name` // relative to that prefix, so the destination key has to be rebuilt. async function copyBucket(bucket, prefix, files, srcDownload) { for (const file of files) { const key = `${prefix}${file.name}` const blob = await srcDownload(bucket, key) // returns a Blob const { error } = await dst.storage.from(bucket).upload(key, blob, { contentType: file.metadata?.mimetype, upsert: true, }) if (error) throw new Error(`${bucket}/${key}: ${error.message}`) } } ``` Whatever you use to enumerate the source objects, remember that Supabase’s `storage.list()` is not recursive and pages at 100 entries by default. Walk each prefix and paginate explicitly, or you will migrate the first page of every folder and nothing else. And upload to the full object path, not to the `name` the listing hands back: that name is relative to the prefix you listed, so uploading it raw flattens `avatars/user-1.png` to `user-1.png` and every path stored in your restored rows still 404s. Then deal with the second half of the problem: signed URLs that your application wrote into the database. A signed URL carries a `token=` query parameter and is scoped to the project that issued it. Every one of those tokens is dead the moment you leave, and no amount of file copying revives them. ``` -- Generates one probe query per text column in public, so you can find -- stored signed URLs instead of guessing which column holds them. select format( 'select %L as col, count(*) from %I.%I where %I like ''%%token=%%'';', table_schema || '.' || table_name || '.' || column_name, table_schema, table_name, column_name ) from information_schema.columns where table_schema = 'public' and data_type in ('text', 'character varying'); ``` Run the generated statements, and for every column that returns hits, decide on a strategy: store the object **path** and sign on read, or backfill freshly signed URLs from the new project. Storing paths is the right long-term answer, and the migration is the cheapest moment you will ever get to make that change. Finally, verify by fetching a real sample of objects over HTTP. Row counts in `storage.objects` prove nothing about whether bytes exist. ## Step 7: re-enter every secret[#](#step-7-re-enter-every-secret) Secrets in Lovable are write-only. The secrets view lists a name and a creation date and never a value: once saved, a value cannot be read back by anyone, including you. So there is nothing to export, and no tool can export it for you. Which means the migration step is not “copy the secrets.” It is “re-issue the secrets.” Go to each provider (Stripe, Resend, your AI vendors, your OAuth apps) generate a fresh credential, and install it on the destination. Find what your code actually expects by grepping the export rather than trusting memory: ``` # Every environment variable your Deno edge functions read. grep -rhoE "Deno\.env\.get\(['\"][A-Z0-9_]+['\"]\)" supabase/functions | sort -u # Then search the whole repo for the secret names from your pre-flight # inventory, so you catch reads the pattern above misses. grep -rn "STRIPE_SECRET_KEY\|RESEND_API_KEY\|LOVABLE_API_KEY" . --exclude-dir=node_modules ``` On the TanStack Start stack there is no Deno function directory to grep and no readable env file: secrets arrive as Cloudflare Workers bindings injected at request time. As of September 2026 Lovable’s docs do not publish the project layout for the new stack, so search for your secret _names_ rather than guessing an access pattern. Install them against your own project: ``` supabase secrets set --env-file ./supabase/.env --project-ref abcdefghijklmnopqrst supabase secrets list --project-ref abcdefghijklmnopqrst ``` Two specifics worth calling out. Do not commit that `.env` file: secret values never left Lovable by design, and the migration is the exact moment people accidentally put them in Git. And any Lovable-issued key baked into your code, such as a `LOVABLE_API_KEY`, is a credential for a platform you are leaving: replace it with the equivalent from your new provider. The failure mode here is silence. The app builds, the homepage loads, and a specific code path breaks days later when someone finally triggers the checkout or the password-reset email. Invoke every path that touches an external service before you call this done. ## Step 8: your users’ passwords do not survive[#](#step-8-your-users-passwords-do-not-survive) Nobody warns about this until it has already happened. Migration write-ups consistently report that Lovable does not export password credentials in a form that keeps sign-in working, and that the recommended path is a password reset for every user. Treat that as the default outcome and plan how you’ll tell your users as well as the technical work. What to do about it: - **Test it empirically.** That throwaway account from the pre-flight checklist, whose password you wrote down: try to sign in as it against the new project before cutover. Do not test with a fresh account you create on the destination; that proves nothing. - **If the restore throws errors on `auth.identities`**, one published migration guide reports that running the restore a second time fills in what the first pass could not. A separate trap list names foreign-key ordering on `auth.identities` as a known problem, though neither source connects the two explicitly. Worth trying on a scratch project before you conclude the auth data is unrecoverable. - **Write the reset email before cutover day.** Say what happened in one sentence, give them the reset link, and do not make it sound like a breach. - **Expect a support spike** in the 48 hours after cutover, and staff for it. Warning Some third-party migration tools advertise password preservation. They generally achieve it by deploying helper functions that extract credential hashes, which bypasses the platform’s standard export mechanism. That is a security decision with real consequences (you are moving password hashes through a third party’s tooling) so make it a deliberate decision. ## Step 9: the invisible infrastructure[#](#step-9-the-invisible-infrastructure) This is everything that is neither code nor rows and will break anyway. It fails silently, and often nobody notices for days. What Why it breaks What to do Scheduled jobs A job that calls an edge function still holds the old project’s address, so scheduled work keeps hitting a backend you are about to delete Re-create each job against the new project; on your own Supabase, confirm with `select jobname, schedule, command from cron.job;` OAuth providers Migration write-ups report that Cloud handles social sign-in through its own libraries rather than through Supabase directly, so those configurations do not come with you Create fresh OAuth credentials at Google, Apple or Microsoft, and add the new project’s callback URL as an authorized redirect URI Inbound webhooks Stripe, Twilio, GitHub and anything else still POST to the old function URLs. Email sent through Lovable’s Resend connector is the exception: that connector cannot receive webhooks through Lovable in the first place Update every endpoint in each provider’s dashboard, and re-create signing secrets where the endpoint changed Hardcoded project URLs Old base URLs pasted into components, tests, or documentation `grep -rn "supabase.co" src supabase` and fix every hit Realtime channels Subscriptions point at the old project’s socket endpoint Confirm the client config picks up the new URL and key, and watch a channel actually receive an event Schedule a deliberate post-migration audit a week out. Declaring victory on day one is how a cron job that has been failing quietly since Tuesday gets discovered by a customer. ## Step 10: verify, then cut the cord[#](#step-10-verify-then-cut-the-cord) Removal is last. Every item here should be ticked before you touch it. - Exact row counts match on every table that matters. - RLS retested with two different accounts, and user A cannot read user B’s data. - A real sign-in succeeded against the new project: using the existing canary account. - Every edge function invoked against the new project with its response body read. - A sample of storage objects fetched over HTTP and rendered in the app. - Zero rows containing stale `token=` signed URLs, or a backfill job that handles them. - Every scheduled job re-created and observed running once. - Every OAuth provider tested end to end with a real account. - Every webhook sender updated and a test event received. - Custom domain and DNS pointed at whatever is serving the app now. Only then remove Lovable Cloud. ## Your rollback plan[#](#your-rollback-plan) Be honest about what rollback means here: there is no undo button, so rollback is really “abort before the irreversible step.” Until you remove Cloud, your original backend is still live and still serving. That is your rollback. If verification fails at any point in steps 3 through 9, you stop, you leave Cloud running, and you fix the destination at your own pace. Nothing is lost because nothing has been deleted. After removal, your position is much weaker. What you actually have is the export archive, your Git history, and whatever you documented. So: keep the export file somewhere durable and off the laptop. Tag the repo at the pre-migration commit. Write down the schema version, the export date, and every secret name you re-issued. And keep the old export until the new backend has survived a full billing cycle and a real traffic peak. One more point that changes the risk calculus and that plenty of people miss: leaving Lovable Cloud is not the same as leaving Lovable. You can keep the editor, the agent and the hosting while pointing the project at a Supabase project you own and can log into. If you are weighing this decision rather than executing it, the [Lovable Cloud versus your own Supabase comparison](/blog/lovable-cloud-vs-supabase) covers the tradeoffs, and [what self-hosting a Lovable app actually involves](/blog/self-host-lovable-app) covers the frontend half of the same question. ## What to do next[#](#what-to-do-next) Pick one of two paths today. If you have not migrated yet and the project is young: stop and decide now whether you want Cloud at all. This is effectively a one-time decision at project creation, and the cheapest migration is the one you never run. Already committed to moving? Rehearse first. Create a scratch Supabase project, run a full restore against it, and work through steps 3 to 9 with nothing at stake. The 24-hour export throttle means the real run is close to single-shot, and the only way to make a single-shot operation safe is to have already done it once. Found something wrong or out of date? Lovable changes fast and we'd rather fix a guide than let it rot. Disclosure: the team behind this guide also builds Encited, mentioned above. On this page - [What Lovable Cloud actually is](#what-lovable-cloud-actually-is) - [The official path, and where field reports disagree with it](#the-official-path-and-where-field-reports-disagree-with-it) - [Pre-flight checklist](#pre-flight-checklist) - [Step 1: export the Cloud data](#step-1-export-the-cloud-data) - [Step 2: create your Supabase project and connect it](#step-2-create-your-supabase-project-and-connect-it) - [Step 3: recreate schema, RLS and triggers, in that order](#step-3-recreate-schema-rls-and-triggers-in-that-order) - [Step 4: restore data and count it properly](#step-4-restore-data-and-count-it-properly) - [Step 5: redeploy edge functions by hand](#step-5-redeploy-edge-functions-by-hand) - [Step 6: re-upload storage, and hunt down dead signed URLs](#step-6-re-upload-storage-and-hunt-down-dead-signed-urls) - [Step 7: re-enter every secret](#step-7-re-enter-every-secret) - [Step 8: your users’ passwords do not survive](#step-8-your-users-passwords-do-not-survive) - [Step 9: the invisible infrastructure](#step-9-the-invisible-infrastructure) - [Step 10: verify, then cut the cord](#step-10-verify-then-cut-the-cord) - [Your rollback plan](#your-rollback-plan) - [What to do next](#what-to-do-next) [More on Migration](/migration) - [Getting your code out of Lovable: the full guide](/blog/lovable-migration) - [How to download your code from Lovable](/blog/download-lovable-code) - [Lovable Cloud vs your own Supabase: how to choose](/blog/lovable-cloud-vs-supabase) - [Lovable GitHub sync: how it really works](/blog/lovable-github-sync) - [Migrating from Lovable Cloud to your own Supabase](/blog/lovable-cloud-to-supabase) - [Moving a Lovable project to a different repo](/blog/move-lovable-project-to-another-repo) - [Running an exported Lovable app on your machine](/blog/run-exported-lovable-app-locally) - [Self-hosting a Lovable app, and what you lose](/blog/self-host-lovable-app) ## Frequently asked questions Is there a one-click migration from Lovable Cloud to Supabase? No. Lovable's Supabase integration documentation states plainly that there is no one-click migration from the built-in backend (Cloud) to Supabase or the other way around. The move is manual: export your data, create your own Supabase project, recreate the schema and policies, redeploy functions, re-upload storage objects and re-enter every secret. Can I migrate from my own Supabase back into Lovable Cloud? No. As of September 2026 Lovable's Cloud documentation says migration from Supabase to Cloud is not supported. Plan the Cloud-to-Supabase direction as one-way. Do my users keep their passwords after migrating off Lovable Cloud? Plan for no. Migration write-ups report that Lovable does not export password credentials in a form that keeps sign-in working, and that the recommended path is a password reset for every user. Test with a throwaway account whose password you recorded before you commit to a cutover date. Are edge functions included in the Lovable Cloud database export? No. The database export contains your data and nothing else. Function source comes out with your codebase through Git sync or a ZIP download, and you deploy it to your own Supabase project yourself with the Supabase CLI. Function secrets are not included either and must be re-entered. Is removing Lovable Cloud reversible? Treat it as permanent. Removal does not move any data for you, so it belongs at the very end of a migration, after you have verified row counts, row-level security, a real sign-in, every function and a sample of storage objects against the new backend. Can I keep using the Lovable editor after moving to my own Supabase? Yes. Leaving Lovable Cloud is not the same as leaving Lovable. Lovable supports projects that connect to your own Supabase project: a workspace owner links a Supabase organization, then individual projects connect to a Supabase project inside it. Read next ## Keep going - ### [Lovable Cloud vs your own Supabase: how to choose](/blog/lovable-cloud-vs-supabase) Lovable Cloud vs Supabase is close to a one-way door. The documented tradeoffs, the credit pool that bills your hosting, and what switching later really costs. - ### [Getting your code out of Lovable: the full guide](/blog/lovable-migration) A Lovable migration is really three migrations: frontend, backend, hosting. What each export path moves, which one-way doors break sync, and the safe order. - ### [How to download your code from Lovable](/blog/download-lovable-code) Two routes to download Lovable code (a ZIP from the code editor and Git sync) the plan gate on both, and the backend pieces neither one exports. - ### [Self-hosting a Lovable app, and what you lose](/blog/self-host-lovable-app) How to self host Lovable app code on Vercel, Cloudflare Pages or Netlify: build settings, SPA rewrites, and the crawler pre-rendering you leave behind. The Lovable Field Guide A working journal on Lovable SEO. SEO - [SEO hub](/seo) Migration - [Migration hub](/migration) Integrations - [Integrations hub](/integrations) © 2026 The Lovable Field Guide. Independent guides to shipping Lovable apps. [RSS](/rss.xml) [Sitemap](/sitemap.xml) [About](/about)