Moving Off Lovable Cloud: What the Export Leaves Behind

Moving off Lovable Cloud means standing up your own Supabase project and pointing the app at it. Your schema, indexes, RLS policies, database functions, triggers and storage buckets come across. Your data rows come across only through the supported database export, which carries structure and data; the code migrations alone leave them behind. Storage files, auth providers, secret values and user passwords do not come across at all and need their own route. Removing Cloud is permanent, with no undo.

The move means three different things depending on where you draw the boundary: moving only the frontend, moving the backend to your own Supabase project, or replacing the Supabase-shaped backend entirely. The first option can leave the database untouched. The second is a multi-track migration across database data, storage, authentication, code, and credentials. The third is an application rewrite around a different authorization and service model.

Choose the boundary before exporting anything. It prevents a common planning error: treating a database file as though it contains the whole app.

What the Lovable Cloud backend includes

Lovable Cloud is the built-in backend that ships with a Lovable project. As of 5 August 2026, Lovable’s Cloud documentation groups it into twelve tools:

• AI
• Emails
• Database
• Users (authentication)
• Storage
• Secrets
• Jobs (scheduled tasks)
• Edge functions
• SQL editor
• Logs
• Usage
• Advanced settings

The first eight are things you move, rebuild, or drop. The last four are the controls you use while doing it. Use the list as a completeness check on the dependency inventory further down: if a live workflow touches one of these and it does not appear in your inventory, the inventory is short.

The three exits from Lovable Cloud

Lovable’s current ownership documentation treats code, frontend hosting, and backend data as independent parts, and it names the frontend destinations directly: Netlify, Cloudflare Pages, Vercel, AWS Amplify, and object storage behind a CDN. A frontend-only move is therefore a valid exit from Lovable hosting, but it is not an exit from Lovable Cloud. The backend still runs there and must remain available.

For most teams that want direct database control without rebuilding every backend service, a managed Supabase project is the closest destination. Lovable’s current external-hosting and migration guide uses it as the reference because the built-in backend relies on Supabase-compatible authentication, storage, realtime, edge functions, and row-level security.

What moves automatically and what you rebuild by hand

This is the answer most people arrive wanting, and it is the line that decides how long the move takes. As of 5 August 2026, Lovable’s external-hosting and migration guide draws it like this.

The left column travels because it lives in your supabase/migrations files, which are code you already have. The right column is state, and state does not ride along in a migration file.

One item the same guide calls out separately: managed OAuth configuration and automatic token refresh only exist while the backend runs on Cloud. Move the backend and you own the OAuth app registrations and the refresh behaviour that went with them.

Decide whether the migration solves the actual constraint

Moving infrastructure has a clear cost: a second system must be configured, tested, monitored, and kept recoverable. The move is justified when it resolves a constraint you can name, such as direct database access, a required region or compliance boundary, unsupported backend behavior, or an ownership requirement from a customer.

Two published facts turn a vague constraint into a real one. As of 5 August 2026, Lovable’s Cloud documentation says Cloud runs in three regions (Americas, Europe, and Asia Pacific), that Lovable preselects the region closest to you when Cloud is enabled, and that the region is locked afterwards: it cannot be changed, and projects cannot be moved between regions. Admins on Business and Enterprise workspaces can enforce a required default region for every new project, which removes the choice from members. So if a customer contract needs data in a specific region and the project was created in the wrong one, migration is the only route, not a preference.

Cost and quota are the other honest trigger. The same documentation says Lovable includes monthly Cloud grants on the Free, Pro, and Business plans and meters Cloud usage in run credits alongside AI features. Two more limits from Lovable’s Advanced settings documentation bite during the move itself: the database export is capped at 5 GB and one request every 24 hours, and storage usage keeps accruing while a project is paused, because the data stays in place. Pausing is not a way to stop the meter.

A vague concern about “lock-in” is not yet a migration plan. Record the current blocker, the destination feature that removes it, acceptable downtime, the rollback point, and who will operate the new backend. If the destination creates more operational work than the original constraint warrants, keep Cloud and move only the frontend or delay the change. The comparison behind that call, who holds the keys on Lovable Cloud versus your own Supabase, is worked through separately. And if the trigger is a security worry rather than a hosting one, settle whether Lovable is safe first, because a leak that lives in your own tables migrates with the data.

The Lovable alternatives comparison helps with the product decision. This article owns the migration boundary and the items that must be captured before Cloud removal.

What you can capture, recreate, and verify

As of 5 August 2026, Lovable’s Advanced settings documentation says its database export contains structure and data, is limited to 5 GB, and can be requested once every 24 hours. The same page excludes storage files, edge function code, project secrets, and usable user passwords.

Your export has your data. It doesn’t have your secrets, and it doesn’t have the code that decided who got to see it.

That produces three different migration verbs:

The full database-file procedure lives in the Lovable export and restore guide. Keep it separate from this decision map so that exact restore commands can follow the artifact format Lovable provides.

Build a dependency inventory before changing the source

Start from running behavior rather than the dashboard menus. List every business workflow and trace which backend dependency it uses. A payment flow, for example, can involve a browser variable, a server secret, an edge or server function, a webhook endpoint, database tables, email delivery, and a scheduled reconciliation job.

1. 01 Record the source project ID, region, database version, custom domains, auth methods, redirect URLs, and current traffic path.
2. 02 Export the database, download it from Cloud storage, and store an encrypted copy outside the Cloud instance.
3. 03 Download every storage bucket and retain object paths, visibility, metadata, and access-policy expectations.
4. 04 Sync or download the complete codebase, then locate database migrations, server routes, edge functions, shared modules, and scheduled jobs.
5. 05 Inventory secret names and the code paths that read them; values cannot be retrieved from Lovable after they are saved.
6. 06 List external systems that call into the app, including OAuth providers, payment webhooks, email providers, DNS, workers, and monitoring.
7. 07 Define a source write freeze, destination verification window, cutover signal, and rollback condition.

This inventory earns its place because it joins resources by workflow. A list of tables cannot tell you that a Stripe webhook still points at the old function or that a private object path depends on a bucket policy you did not recreate.

Lovable Secrets require regeneration or provider-side retrieval

Do not write “copy secrets out of Lovable” into the runbook. Lovable’s Secrets documentation says values are write-only: after a secret is saved, Lovable shows its name and creation date but never reveals the value again.

For a user-created credential, look first in the approved password manager or in the provider account that issued it. Generate a replacement when the original cannot be retrieved, when rotation is available, or when the old value has crossed an untrusted system. Install the destination value, deploy, test, and then revoke the source value. Where a provider permits overlapping credentials, that order avoids a needless outage.

Lovable-managed SUPABASE_* and LOVABLE_* values are reserved. The new Supabase project and other destination services issue their own values. They are configuration inputs to replace, not source secrets to extract.

Use code search to complete the inventory. Typical lookups include Deno.env.get(...), process.env..., and framework-specific environment APIs. Search for webhook URLs and project IDs too. A secret-name list does not expose a hard-coded endpoint or a worker deployed outside Lovable.

Code capture depends on the project’s generation

Lovable supports Git sync, and its current GitHub documentation also describes a codebase download from the code editor on paid plans. Capture the repository before removing Cloud, then verify that generated migrations and backend code are present.

Do not assume every Lovable project has the same runtime. Lovable’s current FAQ says projects created from 13 May 2026 use TanStack Start with server-side rendering; older projects use React and Vite. Older apps commonly place edge functions under supabase/functions. Newer apps can have server-side routes and a different deployment boundary. Inspect package.json, build scripts, generated directories, and the official deployment guidance for that exact project.

The distinction also affects environment variables. Vite-prefixed values are embedded into browser code at build time and must be public. Backend credentials belong in the destination’s server-side secret store. Environment variables by framework and host explains the exposure and redeploy rules.

The destination wiring, exactly

Create the destination Supabase project first, save its project reference, URL, and publishable key, then wire the app to it. As of 5 August 2026, Lovable’s external-hosting and migration guide gives this order.

Point the frontend at the new project. For a Vite-era project these are the three keys a Lovable-generated app reads, and all three are public browser values; a TanStack Start project (created from 13 May 2026) may read them on the server as well, so check your build scripts and any server routes before copying this:

VITE_SUPABASE_URL=https://your-new-project-ref.supabase.co
VITE_SUPABASE_PUBLISHABLE_KEY=your-new-publishable-key
VITE_SUPABASE_PROJECT_ID=your-new-project-ref

Then change the project reference the tooling uses, in supabase/config.toml:

project_id = "your-new-project-ref"

Then apply the schema. The files in supabase/migrations run in chronological order, by the timestamp in each filename, and they run before any data goes in. From the repository root:

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

supabase db push applies the migrations to the linked project. supabase functions deploy pushes the edge functions. Their secrets are a separate step in the destination project, because no secret value ever comes out of Lovable.

Data comes after the schema, never with it. Single tables can move through Cloud tab, Database, Export CSV. The whole database moves through the full export in Advanced settings, and the Lovable export and restore guide covers that artifact and its restore commands. This section owns the wiring; that one owns the file.

One variable does not belong in the list above. SUPABASE_SERVICE_ROLE_KEY is a server-only value that bypasses row-level security. It belongs in the destination’s server secret store, and never in a VITE_-prefixed variable, a browser bundle, a shared document, or a migration vendor’s web form.

How long it takes and what usually breaks

Budget a working session, not an afternoon of clicking. For a small app (a handful of tables, no storage buckets, no edge functions), the data phase is realistically a couple of hours once the destination project exists. Add time for every storage bucket you have to download and re-upload, every edge function and its secrets, and every external service whose callback URL has to change. The frontend host swap is the fast part, usually under an hour, because it is a repository connect and a build command.

The delay is rarely the migration itself. It is usually one of these five:

None of these lose data on their own. All of them lose an afternoon, and the last one loses it in public.

Authentication is its own cutover

Lovable’s supported database export does not preserve user passwords in a usable form. Plan a reset flow and test it before switching traffic. Recreate each sign-in provider, update OAuth redirect URLs, verify email templates and delivery, and test expired and revoked sessions.

The two tables people try to export by name here are auth.users and auth.identities. Their rows tell you who exists and which provider each account signed in with, which is worth having for reconciliation. What they do not hand you is a password you can install on the new project. So every existing account needs a working reset path on the destination before you move traffic, and the accounts that signed in through a provider need that provider reconfigured, not reset.

Supabase can preserve password hashes during a native migration of the full auth schema between projects. Lovable’s export documentation still says its supported artifact does not provide usable passwords. A third-party tool that obtains privileged source database access is using a different path, and its password-continuity claim does not change what the standard export contains.

Treat credential-extracting migration helpers as hostile, high-risk software until an independent review proves otherwise. Review the exact source and release, run it from a controlled machine, avoid hosted forms, and give it only the access needed for this transfer. Remove any deployed helper afterward and rotate every source and destination credential it handled. A convenience form is not an acceptable place for a service-role key or database password merely because the migration vendor asks for one.

Verify the destination as an application

Database row counts are necessary and incomplete. Test each dependency from the same interfaces customers and external services use.

1. 01 Compare exact critical-table counts at a documented snapshot time, plus constraints, indexes, functions, triggers, extensions, and RLS state.
2. 02 Run sign-up, reset, email/password sign-in, OAuth, sign-out, session refresh, and revoked-session tests.
3. 03 Use two accounts to test cross-user reads and writes through the public API.
4. 04 Upload and retrieve private and public storage objects, including signed URLs and ownership rules.
5. 05 Call every server route or edge function with valid, invalid, duplicate, and unauthenticated requests where relevant.
6. 06 Send real test events through payments, email, AI providers, webhooks, schedules, and any external workers.
7. 07 Confirm logs, alerts, backups, and restore ownership exist in the destination.
8. 08 Search for the old project URL, ID, keys, callback URLs, and webhook endpoints before cutover.

Keep the source unchanged until this pass is clean. A rollback plan should name the traffic switch, the maximum divergence allowed after the write freeze, and the exact condition that sends traffic back.

After cutover, give it a real staging environment before the next schema change. The new production database should not become the place where migration scripts are tried for the first time.

Why the move forces a security recheck

An RLS policy that exports cleanly as text is no evidence it does its job on the new project. In the AxonBuild review corpus from mid-2026, RLS gaps turned up in 9 of 21 third-party apps in the AxonBuild corpus, almost always on a table that had a policy attached, just not one that checked what it needed to. A policy that copies over cleanly and a policy that actually stops a stranger from reading another customer’s row look identical in a schema dump. The only way to tell them apart is to log in as two separate accounts and try, which is why the two-account test sits in the verification list above.

The same goes for credentials. 6 of 21 apps in the corpus shipped a real secret somewhere it shouldn’t have been, three of them permanently stuck in git history. One I recovered during an audit was a live LLM-provider key an early commit had written into the app’s own config file; the project had long since switched to a .env and deleted the file, and the full history still handed back a working credential. If any credential you’re reinstalling ever sat in a shared doc, a support ticket, or a screen-share, moving day is when you rotate it at the provider, not when you install the old value into the new project unchanged.

Edge functions carry their own version of this. Of the 14 apps in the corpus that ship an AI feature, 12 had a confirmed way for someone who isn’t a customer to drain the owner’s model budget: a route that calls a paid model with nothing checking who’s asking. A function that was open like that inside Lovable stays exactly as open on whatever host you move it to, because moving code doesn’t add the auth check nobody wrote the first time. Why AI coding tools ship security holes by default covers why that gap is so common.

How to disable, pause, or remove Lovable Cloud

There is no button labelled disable. Lovable gives you two controls that do the job, and they are not close substitutes: pause and remove. To disable Cloud is to pick one of them, so decide which one before you open the tab.

As of 5 August 2026, Lovable’s Advanced settings documentation puts both under Cloud tab, Overview, Advanced settings. Removal is self-serve and gated: two acknowledgement checkboxes, where the second only unlocks after the first, then the project’s display name typed exactly. It permanently deletes the Cloud instance and cannot be undone. The built-in database, storage, authentication, and backend functions go with it.

Pause is the reversible one. While a project is paused the backend is unavailable and the deployed app cannot read or write, but the data stays where it is, and it only comes back when you click Wake up on the paused project card. Because the data stays in place, storage usage keeps accruing. A pause can support a controlled test that the app no longer depends on Cloud. It is not a backup, and it is not a way to stop the meter.

Two traps sit in the removal step:

So do not disable Cloud, by either route, while it is still the rollback target, while exports remain only in its storage, or while any workflow still uses its URL.

The exit is complete when the source is no longer a dependency, not when the destination dashboard looks populated.

Common questions about moving off Lovable Cloud

Do I own my Lovable app?

Lovable’s terms decide legal ownership; the export decides what you actually hold. In practice you hold the pieces you’ve captured. Code is fully yours once it lives in a synced repo or a downloaded copy under your account; the database becomes yours the moment an export lands on your disk; storage files stay inside Lovable Cloud until you download each bucket. Secret values never come out at all, so ownership there means holding the provider account that can issue replacements. Custody describes what you’ve exported rather than what the dashboard shows. If the exit has you comparing builders, what Base44 hands back by comparison is measured on the same axis.

Can I transfer a Lovable project to another account?

Not directly between two separate accounts. As of 16 August 2026, Lovable’s project documentation describes the transfer as an in-workspace action, Project settings, Transfer ownership, then a workspace member, and Lovable’s FAQ adds that the new owner has to be a full workspace member already, not a collaborator and not a pending invite. So the route to another person is to invite them into the workspace first, then transfer. Since then the same documentation has added a Move workspace action (Project settings, Move workspace, or Transfer to workspace on the project card) that moves a project into another workspace with its history and settings; a project lives in one workspace at a time (read 5 September 2026). For a different login email the FAQ points at a second route instead: create the new account and remix the projects into it, which produces an independent copy rather than a move. Neither route is a Cloud migration. The backend, its data and its write-only secrets stay with the project, so changing the owner does not give the new account a Supabase project of its own.

What is the Lovable Cloud storage limit?

Lovable does not publish a fixed storage cap for Cloud. As of 5 August 2026 the documented hard numbers sit on the database export: 5 GB per export, and one export every 24 hours. Storage itself is metered as usage against the monthly Cloud grants and run credits that vary by plan, and it keeps accruing while a project is paused, because the data stays in place.

Can you undo removing Lovable Cloud?

No. Removal is permanent, with no undo and no grace-period restore. The 60-day grace window people have read about applies to a deleted workspace, not to a deleted project and not to credits, and whether Lovable has a grace period splits the three cases apart.

Do I need to contact Lovable support to disconnect Cloud?

No, not as of 5 August 2026. Lovable’s own documentation describes removal as self-serve: Cloud tab, Overview, Advanced settings, Remove Lovable Cloud, then two acknowledgements and the project’s display name. Some widely read migration guides tell readers to request a formal Cloud disconnect through support, which does not match the current documented flow. Check Advanced settings first and only open a ticket if the option is genuinely missing for your project.

Can I move back to Lovable Cloud after migrating?

No. Lovable’s Cloud FAQ says migration from Supabase to Cloud is not supported, so there is no path that imports your own Supabase project back into a Cloud instance. Combined with removal permanently deleting the Cloud instance, the exit is one-way in two separate senses. Treat the decision as final and verify the destination before you remove anything.

Can I host a Lovable frontend elsewhere and keep Cloud?

Yes. Lovable documents frontend and backend hosting as separate choices. Configure the external deployment for your project’s actual stack and keep the frontend pointed at the existing Cloud backend. Cloud remains an operational dependency.

Can I copy secret values from Lovable into Supabase?

No. Lovable secret values are write-only. Inventory their names, obtain an approved existing value from its original owner when available, or generate a replacement at the provider. Test the destination value before revoking the source credential.

Will moving to Supabase fix weak RLS policies?

No. Policies and functions can migrate with the same authorization mistake they had at the source. Test user A against user B’s records through the public API, then use the Supabase RLS best-practices guide to review the policy boundaries.

Should I remove Cloud as soon as the import succeeds?

No. Verify authentication, storage, server behavior, integrations, monitoring, and rollback first. The import proves only that the destination accepted an artifact.

Do I need to move off Lovable Cloud before launch?

Only when Cloud prevents a requirement the launch actually has. A migration introduces new failure paths and operational ownership. Resolve whether the Lovable app is ready for production independently from the hosting decision.