Van Lovable Cloud naar je eigen Supabase: wat er meegaat en wat niet

Lovable Cloud is de backend die Lovable zelf voor je regelt: database, inloggen, bestanden en serverfuncties, zonder dat je een Supabase-account hoeft aan te maken. Onder de motorkap is het Supabase. Alleen staat het project op het account van Lovable, niet op het jouwe. Je kunt niet in het Supabase-dashboard, je krijgt geen service role key en geen directe databaseverbinding. Zolang je bouwt is dat handig. Zodra er klanten op zitten, wil je dat dat anders is.

Waarom je eraf wilt

• Eigendom: je klantgegevens staan in een project dat je niet zelf beheert en alleen via Lovable bereikt.
• Toegang: geen SQL Editor, geen backups op je eigen voorwaarden, geen koppeling met tools die een directe databaseverbinding nodig hebben.
• Kosten en afhankelijkheid: je betaalt via Lovable voor gebruik dat je anders rechtstreeks bij Supabase afneemt, en je hosting hangt aan je Lovable-abonnement.
• Verder bouwen buiten Lovable: wil je met een developer of met een andere tool verder, dan moet de backend ergens staan waar die bij kan.

Lovable zegt het zelf in de documentatie: er is geen migratie met één klik van Cloud naar je eigen Supabase. Het kan wel, en Lovable heeft er inmiddels een eigen exportroute voor, maar het is een verhuizing met een paar losse dozen.

Wat er meegaat, en wat je met de hand doet

Lovable biedt onder Cloud, Overview, Advanced settings een export van je data. Dat is een volledige dump van je database. Volgens de documentatie van Lovable zit dit erin, en dit niet:

• Gaat mee: tabellen, data, RLS-policies en je gebruikers, inclusief hun wachtwoordhashes. Niemand hoeft een nieuw wachtwoord aan te maken.
• Gaat niet mee: sessies. Iedereen moet na de overstap één keer opnieuw inloggen, want het nieuwe project tekent sessies met eigen sleutels.
• Met de hand: bestanden in storage. Downloaden uit Cloud en uploaden naar dezelfde buckets in Supabase.
• Met de hand: edge functions. De code staat in je repository onder supabase/functions; die deploy je met de Supabase CLI.
• Met de hand: secrets. API-sleutels die je in Lovable hebt ingesteld zitten niet in de export.
• Met de hand: inlogproviders zoals Google, redirect-URL's en geplande taken.
• Vervangen: AI-functies. Zolang je op Cloud zit lopen modelaanroepen via de AI-gateway van Lovable; daarna heb je een eigen account bij OpenAI, Anthropic of Google nodig.

Let ook op de grenzen van de export: je kunt één keer per 24 uur exporteren en er zit een maximale omvang op. Bij een grote database loopt het via de support van Lovable.

De volgorde die werkt

De gouden regel: laat je app op Cloud draaien tot de nieuwe kant aantoonbaar werkt. Pas dan zet je de schakelaar om.

• 1. Koppel je project aan GitHub, als dat nog niet zo is. Daarin staan je code, je migraties in supabase/migrations en je edge functions.
• 2. Maak een Supabase-project op je eigen account, in een EU-regio als je klanten in Nederland zitten. Bewaar het databasewachtwoord.
• 3. Maak een export in Lovable en download hem, samen met alle bestanden uit storage.
• 4. Zet de dump terug in je nieuwe project met de Postgres- of Supabase-tools.
• 5. Upload de bestanden naar dezelfde buckets, deploy de edge functions, zet de secrets en de inlogproviders opnieuw.
• 6. Zet de nieuwe Supabase-URL en publishable key in je app, op een testomgeving, en test.
• 7. Doe vlak voor de overstap een laatste export, zodat je geen data mist van de dagen ertussen, en zet dan je domein om.
• 8. Haal Cloud pas weg als alles draait. Dat verwijdert de oude omgeving definitief, inclusief exports die nog in Cloud-storage stonden.

Zo controleer je of het gelukt is

• Tel per tabel de rijen in het oude en het nieuwe project. Ze moeten gelijk zijn.
• Vergelijk het aantal gebruikers in Authentication.
• Log in als een bestaande testgebruiker met zijn oude wachtwoord.
• Log in als twee verschillende gebruikers en controleer dat ze elkaars gegevens niet zien.
• Open een paar geüploade bestanden en kijk of de links in je app nog kloppen.
• Doe een handeling die een edge function aanroept, en een die een e-mail verstuurt.

Die vierde check is geen formaliteit. De policies verhuizen mee, maar of ze ooit goed waren is een andere vraag. Een verhuizing is het moment om dat na te lopen, want daarna heb je voor het eerst echt toegang. Hoe je dat doet staat in waarom kunnen mijn gebruikers elkaars gegevens zien. En maakt je app na de verhuizing nieuwe tabellen aan, let dan op de wijziging van Supabase op 30 oktober.

Hulpmiddelen van derden

Er zijn inmiddels tools die beloven alles in één keer over te zetten. Sommige werken prima, maar je geeft ze tijdelijk toegang tot je hele database met klantgegevens. Bekijk wie erachter zit en wat de tool precies doet voordat je dat doet. De officiële export van Lovable heeft dat probleem niet.

Zelf doen of laten doen

Een kleine app met een paar tabellen, geen bestanden en geen edge functions verhuis je met deze lijst prima zelf in een middag. Het wordt een ander verhaal met storage, meerdere edge functions, inloggen via Google of betalingen via Stripe, want dan moet alles tegelijk omgaan zonder dat een klant het merkt.

Die verhuizing doe ik als vast blok, vanaf € 2.250 exclusief btw: export, nieuw project op jouw naam, bestanden, functies, secrets, een controle van de policies en de overstap zelf. Wat de andere blokken kosten staat op Lovable-app laten afmaken. Wil je ook je frontend van lovable.app af, dan staat dat deel in kan ik mijn Lovable-app exporteren en zelf hosten.

Twijfel je of het nu al moet, begin dan met de gratis vibecode-scan. Ik kijk naar je project en zeg eerlijk of verhuizen nu loont of nog even kan wachten.