Guide

    How to move your Lovable project's database to your own Supabase account

    Last updated 19 October 2026

    Lovable's built-in backend, Lovable Cloud, gives every project a database, authentication and file storage that Lovable runs for you. Most teams never need to move it. You might, if you need the database under your own account for compliance, data residency, your own backups, or to leave Lovable entirely. This guide follows the sequence in Lovable's own documentation, with practical notes added.

    Before you start

    When your backend runs outside Lovable, its availability, backups, monitoring, row-level security, sign-in providers, secrets and security scanning become your responsibility. Lovable's documentation also notes that managed OAuth configuration and automatic token refresh are only available on Lovable Cloud.

    Keep the app running on Lovable Cloud the whole time. You point it at the new backend only at the end.

    What moves automatically and what does not

    • Database schema, including tables, indexes, RLS policies, functions and triggers: automatic, through the SQL migration files in your repository.
    • Storage buckets and their access policies: automatic, through the same migrations.
    • Table data: manual. Export it from Lovable and import it.
    • User accounts: included in the full database export with their password hashes, so users keep their passwords. Signed-in users will need to sign in again.
    • Sign-in providers such as Google or GitHub: manual. Set them up again.
    • Secrets and API keys, for example Stripe: manual.
    • Storage files: manual. Download and upload them.
    • Edge functions and scheduled jobs: manual. Deploy them with the Supabase CLI and recreate schedules.
    • Lovable app connectors and AI features: they run through Lovable and are not exported. Replace them with your own integrations.

    Step-by-step migration

    1. Connect the project to GitHub with Git sync so you have the code, including supabase/migrations/ and supabase/functions/.
    2. Create a new Supabase project on your own account. Note its URL, project ID and public key.
    3. Apply the schema. Link the Supabase CLI to the new project and apply the migration files in their recorded order.
    4. Export the data from Lovable. Request a full database export from More → Cloud → Overview → Advanced settings, or export single tables as CSV from More → Cloud → Database.
    5. Restore the export into the new project. Check what the export contains first: if it already includes the schema, do not create the same objects twice.
    6. Configure sign-in. Enable each provider again and add your site and preview URLs to the redirect URLs.
    7. Copy storage files into buckets with the same names.
    8. Set secrets, deploy edge functions and recreate scheduled jobs.
    9. Replace any Lovable app connector or AI calls with your own integrations.
    10. Point a test deployment at the new backend through its environment variables. Leave the live Lovable project unchanged.
    11. Test sign-in, payments, file uploads, every edge function and every form on the test deployment.
    12. Switch: restore a final, fresh export, update .env and supabase/config.toml in the project, and move traffic.
    # Example: apply the schema with the Supabase CLI
supabase link --project-ref your-new-project-ref
supabase db push
supabase functions deploy

    Common mistakes

    • Testing against an old export, then switching with stale data. Always restore a final export just before the switch.
    • Forgetting secrets, so edge functions fail silently after the move.
    • Missing redirect URLs, so sign-in breaks only in production.
    • Assuming RLS policies were copied without checking them. Test that one user cannot read another user's rows.

    Want it done for you?

    Two options. Escape Pod is our self-service tool: scan your project for free, see what will move, and migrate the database, auth users, RLS policies and edge functions to your own Supabase project. Or our Supabase Migration service handles it end to end in 3 to 5 business days, with 30 days of support afterwards.

    Try Escape PodSupabase Migration service

    Sources