Move Lovable Cloud to your own Supabase project
Move Lovable Cloud to Supabase with checks for ownership, exports, auth, storage, functions and the final write-freeze.
Faisal Karkoh · 17 Oct 2026 · 9 min read
Lovable Cloud is useful when the team wants a backend quickly. The migration question usually appears later: the app is working, but the team now needs direct Supabase dashboard access, billing control, backup visibility and a clearer export path.
The practical answer is to move the backend, not necessarily the whole app. You can keep using Lovable for app iteration while replacing Lovable Cloud with a Supabase project owned by the team. Treat the move as a manual backend migration with a planned write freeze, not as a one-click setting change. If the project is not yet connected to an owned Supabase project, the setup trade-offs are covered in more detail in the Lovable and Supabase production setup guide.
Evidence note: based on Lovable and Supabase documentation accessed on 2026-10-17. No live migration, pg_restore run, dashboard workflow or production cutover was tested for this article.
The practical decision is backend ownership
Lovable’s Cloud documentation describes Lovable Cloud as its built-in backend for database, authentication, storage, realtime and functions, using Supabase’s open-source foundation. That does not make it a Supabase project owned by the customer.
The ownership difference matters operationally. Supabase’s troubleshooting documentation explains that the underlying instance for Lovable Cloud is provisioned and managed by Lovable, so it does not appear in the team’s Supabase dashboard and does not work with the team’s Supabase credentials.
Connecting an owned Supabase project is different. Lovable’s Supabase integration documentation says teams connect their own Supabase project when they want direct ownership of the backend, their own Supabase account and billing, and full access to the Supabase dashboard. The same page says the integration is available on all plans, but also states that switching from Lovable Cloud to Supabase is not automatic and that there is no one-click migration. For the broader backend choice, the Supabase review for AI builders explains where Supabase fits well and where the operational responsibility starts.
That makes the decision less about technology branding and more about operations:
- Move if backend ownership, Supabase dashboard access, direct billing and future portability are now important.
- Stay on Lovable Cloud if the current managed backend is sufficient and the team does not need to take on migration and cutover risk.
- Plan a broader app migration separately if the team also wants to move hosting, repository ownership or deployment away from Lovable.
First confirm what backend the project is using
Before planning a migration, confirm whether there is anything to migrate. Supabase’s guide to identifying the Lovable backend says to open the Cloud settings area from the Lovable editor to see which backend the project is currently connected to.
If the project is using Lovable Cloud, the backend will not appear in the team’s Supabase dashboard. That is the migration case covered here.
If the project is already connected to a Supabase project owned by the team, do not frame the work as a Lovable Cloud migration. The ownership problem is already solved. The remaining work is normal Supabase operations: access control, billing, backups, RLS, auth providers, environments and deployment configuration.
Use one inventory for the whole backend, not only the database
The common failure mode is treating this as a database copy. The database is central, but it is not the whole backend. Build the inventory before requesting an export.
For the illustrative scenario below, assume a small product team built an app in Lovable using Lovable Cloud. They still want to use Lovable for front-end and app iteration, but now need the backend in their own Supabase account for dashboard access, direct billing, backups and future exportability. This scenario is illustrative, not observed migration results.
| Area | What to record before export | Why it can block cutover |
|---|
| Database | Tables, row counts, indexes, relationships, RLS policies, functions, triggers and sequences. | A restore can appear successful while inserts fail because policies, triggers or sequences are wrong. |
| Migrations | Whether migration files live under supabase/migrations/ or drizzle/migrations/. | Lovable’s migration guidance says Supabase migrations should be applied chronologically, while Drizzle order follows drizzle/migrations/meta/_journal.json. |
| Auth | Providers, redirect URLs, email settings and at least one test user with a known password. | Users may keep passwords after restore, but active sessions do not carry over and providers must be configured again. |
| Storage | Buckets, file paths, public/private access patterns and media references in database rows. | Lovable’s database export does not include storage files. |
| Functions and jobs | Edge Function code, secrets, scheduled jobs, webhooks and external app or AI connector calls. | The export does not include Edge Function code or secrets, and background writes after export can create missing records. |
Check export eligibility early. Lovable’s advanced settings documentation says Cloud exports can be created only while the backend is running; paused projects must be resumed first. It also documents export limits: databases using up to 15 GB of storage, export files up to 5 GB, and one export request every 24 hours.
If the database exceeds those limits, or if the 24-hour export cadence does not fit the cutover window, the team should escalate the migration plan before committing to a simple backup-and-restore path.
Create the Supabase destination before moving data
Create the destination Supabase project in the correct Supabase organisation and region. Record the project ID, project URL and publishable or anon key, but do not point production traffic at the new project yet.
At this stage, the destination is a prepared backend, not the live backend. The safe sequence is to move schema first, verify it, and only then restore data. Lovable’s deployment and hosting guidance describes the managed Supabase migration sequence as creating the destination project, moving schema, restoring or exporting data, configuring sign-in, copying storage files, setting secrets and functions, testing, then switching.
Apply migrations in the documented order. If the repository has supabase/migrations/, apply those migrations chronologically. If it has drizzle/migrations/, follow the order in drizzle/migrations/meta/_journal.json, as described in Lovable’s external deployment and hosting documentation. For teams using AI coding tools around database changes, the Cursor Supabase migration workflow is a useful companion because it keeps schema, RLS and generated types under Git review.
Stop if schema checks fail. Missing tables, wrong ordering, existing object conflicts, missing RLS policies or failed trigger/function creation should block the data restore. Restoring rows into a destination whose schema is only partly correct creates harder problems than fixing schema first.
Restore data, then move what the export does not include
Lovable’s advanced settings documentation says the full database export contains structure and data, including user accounts and password hashes. It also says the export does not include files in storage, Edge Function code or project secrets.
The restore path matters. Lovable’s external deployment guidance says the full database export is a PostgreSQL custom-format .backup archive with zstd compression and is restored with a pg_restore-based workflow. It is not a SQL file to paste into the Supabase SQL editor.
After a successful restore into Supabase, Lovable says users keep their passwords. Signed-in users still need to sign in again, and sign-in providers must be configured again. That means auth verification needs a real account, not only a schema inspection.
Use the test user prepared earlier to verify the auth path. A passing check should confirm that the user can sign in again with the expected password after provider settings and redirect URLs are configured. A failing check should stop the switch, even if tables and row counts look correct.
Move the non-database parts separately:
- Copy storage buckets and files, then verify that screens using uploaded media still resolve the expected paths.
- Deploy Edge Function code separately and configure the required secrets in the destination project.
- Recreate scheduled jobs, webhooks and external integrations.
- Check AI connector calls or app automation flows that read from or write to the backend.
A database restore can succeed while uploads, background jobs or function calls fail. Cutover should wait until those paths pass in the destination environment.
Understand the billing change without inventing a cost model
Moving to an owned Supabase project also moves backend billing visibility to Supabase. This is not enough information to compare total Lovable Cloud cost with total Supabase cost, because the Lovable Cloud usage inputs for this decision are not included here. The verified Supabase billing inputs are still useful for ownership planning.
| Supabase billing input | Verified detail as of 2026-10-17 | Operational meaning |
|---|
| Free plan | Supabase pricing lists USD $0/month within Free limits: 500 MB database size, 1 GB file storage, 5 GB egress, 50,000 monthly active users and 2 active projects. Free projects pause after 1 week of inactivity. | Useful for prototypes or very small projects, but pause behaviour and limits may not fit production. |
| Pro plan baseline | Supabase Pro starts at USD $25/month per organisation plan. The first project is included; additional projects start from USD $10/month. | Baseline direct Supabase billing starts from USD $25/month before overages or extra project charges. |
| Compute credit | Paid plans include USD $10/month in compute credits, enough to cover one Micro instance listed at USD $10/month. | The included compute credit can offset the first Micro instance, subject to the current pricing terms. |
| Overage variables | After Pro allowances: database disk over 8 GB per project is USD $0.125/GB, file storage over 100 GB is USD $0.0213/GB, egress over 250 GB is USD $0.09/GB, and Edge Function invocations over 2 million are USD $2 per 1 million. | These are variables to monitor after migration, not a forecast without real usage data. |
The cost decision is therefore about billing ownership and visibility, not a guaranteed saving. Use actual database size, storage, egress, active users and function invocation data before projecting the bill.
Test, freeze writes and switch only after final verification
The final cutover risk is the write window. Lovable’s migration guidance states that records written after the export are not included. Unless the team has built an incremental copy process, pause user writes, scheduled jobs, webhooks and integrations before the final export.
Before changing production, point a separate test deployment at the new Supabase backend. Lovable recommends this approach so the test deployment talks to the new backend while users still use the old one.
Run the verification as a cutover gate, not as a best-effort checklist:
- Confirm the Lovable Cloud backend is running before the export. If it is paused, resume it first.
- Confirm export eligibility against the 15 GB database storage limit, 5 GB export file limit and 24-hour request cadence.
- Apply schema migrations before importing data. Stop on missing objects, ordering issues or RLS differences.
- Restore the
.backup archive through a pg_restore-based workflow, not through the SQL editor. - Compare table presence, row counts, relationships, sequence behaviour and record creation in the destination project.
- Test sign-in with a real migrated user. Expect users to sign in again after the switch.
- Verify reads, writes, uploads, Edge Functions, scheduled jobs, webhooks and integrations from the test deployment.
- Freeze writes before the final export unless an incremental copy process exists.
Do not remove Lovable Cloud immediately after the first successful restore. Lovable’s advanced settings documentation warns that removing Lovable Cloud permanently deletes the Cloud instance and cannot be undone, and says to export the database and download any storage files needed before continuing. If this migration is part of a wider launch hardening pass, use the Lovable production checklist to catch non-database issues such as domains, secrets, auth paths and release readiness.
The next action is simple: open the Lovable editor, confirm the backend type in Cloud settings, and decide whether the ownership gain justifies a controlled manual migration with a verified final write freeze.