Jak przenieść aplikację z Lovable Cloud do własnego Supabase

Lovable Cloud czy własny Supabase: co wybrać?

Lovable Cloud to wbudowany backend Lovable: baza danych, uwierzytelnianie, storage, funkcje edge i AI, zbudowany na otwartoźródłowych fundamentach Supabase i opłacany z kredytów Lovable. Podłączenie własnego projektu Supabase oznacza, że to Państwo mają konto, klucze i rachunek. Żadna opcja nie jest zła. Pasują do różnych etapów.

Warto zostać na Cloud, dopóki Państwo wciąż ustalają, czym jest produkt: to najszybszy sposób, by w ogóle mieć backend. Migrować warto, gdy potrzebne jest coś, czego Cloud nie daje, na przykład bezpośredni dostęp inżynierów do bazy, własne kopie zapasowe i odtwarzanie do punktu w czasie, konkretny region ze względu na zgodność, umowa powierzenia przetwarzania danych we własnym imieniu albo po prostu brak uzależnienia od dostawcy w systemie źródłowym.

Co obejmuje eksport z Lovable Cloud, a czego nie?

Zaawansowane ustawienia Lovable pozwalają wyeksportować, wstrzymać lub usunąć Cloud. Według dokumentacji Lovable eksport zawiera pełną bazę danych – strukturę i dane – oraz konta użytkowników ze skrótami haseł. Nie zawiera plików w storage, kodu Edge Functions ani sekretów projektu, a ustawienia dostawców logowania i klucze API trzeba skonfigurować ponownie w miejscu docelowym. Działa dla baz zajmujących do 15 GB, plik eksportu może mieć najwyżej 5 GB, a eksport można zlecić raz na 24 godziny.

Podczas migracji ważne są jeszcze dwie kontrolki. Wstrzymanie Cloud zatrzymuje bazę danych, uwierzytelnianie, storage i funkcje edge, więc zatrzymuje się też wszystko, co wysyła e-maile, przyjmuje płatności lub wywołuje AI, a storage jest nadal rozliczany. Usunięcie Cloud trwale kasuje instancję i nie można go cofnąć. Prosimy niczego nie usuwać, dopóki nowa konfiguracja nie działa przez jakiś czas na produkcji.

Jak krok po kroku przenieść się z Lovable Cloud do Supabase?

1. 01

   Utworzyć i zabezpieczyć nowy projekt

   Utworzyć projekt Supabase we własnej organizacji, w potrzebnym regionie, w planie z kopiami zapasowymi. Włączyć uwierzytelnianie wieloskładnikowe dla wszystkich z dostępem do panelu.

2. 02

   Wyeksportować i zaimportować bazę danych

   Wyeksportować z zaawansowanych ustawień Lovable i przywrócić eksport w nowym projekcie Supabase. Od tej pory utrzymywać schemat jako wersjonowane migracje, aby dało się go odbudować z kodu.

3. 03

   Przenieść to, czego eksport nie obejmuje

   Skopiować buckety i pliki ze storage, ponownie wdrożyć Edge Functions z kodu oraz utworzyć nowe sekrety i klucze API. Każdy stary klucz traktować jako wycofany, zamiast go kopiować.

4. 04

   Połączyć Lovable z nowym backendem

   Dokumentacja Lovable opisuje podłączenie własnego projektu Supabase do nowego projektu Lovable. Należy to zrobić i przed przełączeniem uzgodnić, jak zespół będzie tam dalej pisać prompty.

5. 05

   Ponownie podłączyć uwierzytelnianie

   Skonfigurować ponownie dostawców logowania (Google, e-mail) w nowym projekcie i przetestować na prawdziwym koncie. Lovable zaznacza, że użytkownicy zalogowani w chwili przełączenia będą musieli zalogować się ponownie.

6. 06

   Ponownie sprawdzić reguły dostępu

   Uruchomić Security Advisor Supabase i test z dwoma użytkownikami z naszej checklisty bezpieczeństwa. Polityki nie zawsze przetrwają migrację bez zmian.

7. 07

   Przećwiczyć, potem przełączyć

   Przećwiczyć całą migrację na kopii, a potem przełączyć produkcję w spokojnej godzinie, ze spisanym planem wycofania. Cloud zostawić wstrzymany, a nie usunięty, dopóki nie będą Państwo pewni.

Czy użytkownicy będą musieli zresetować hasła?

Nie, jeśli przywrócą Państwo eksport Lovable w projekcie Supabase: dokumentacja Lovable mówi, że eksport zawiera konta użytkowników i skróty haseł, więc użytkownicy zachowują hasła. Prosimy przetestować to przed przełączeniem, logując się do nowego projektu istniejącym kontem. Użytkownicy zauważą, że muszą zalogować się ponownie, jeśli byli zalogowani w chwili przełączenia, oraz brak logowania społecznościowego, którego zapomniano ponownie skonfigurować.

Co zwykle psuje się podczas migracji z Lovable Cloud?

• Pliki. Obrazy i przesłane pliki zostają, chyba że samodzielnie przeniosą Państwo storage, a ich adresy URL się zmieniają.
• Praca w tle. E-maile, obsługa płatności i wywołania AI działają w Edge Functions, których eksport nie obejmuje.
• Webhooki. Stripe i inni dostawcy nadal wskazują stare endpointy, dopóki ich nie zmienią Państwo, a ich sekrety podpisujące zmieniają się wraz z nowymi funkcjami.
• Reguły dostępu. Polityka odwołująca się do czegoś specyficznego dla Cloud może zawieść w stronę zamkniętą (funkcje przestają działać) lub otwartą (dane wyciekają).
• Sam Lovable. Dokumentacja Lovable opisuje podłączenie nowego projektu Supabase do nowego projektu Lovable, więc warto zaplanować, jak zespół będzie dalej pisać prompty po migracji.

Migrować samodzielnie czy zlecić to inżynierom?

Mała aplikacja bez płatności, z niewielką liczbą plików i garstką użytkowników to rozsądny projekt na weekend według powyższych kroków. Ryzyko rośnie przy działających płatnościach, wielu użytkownikach i plikach, bo błąd objawia się utratą przesłanych plików, podwójnymi obciążeniami lub danymi widocznymi dla niewłaściwych osób. Dla takich aplikacji migracja to zadanie inżynierskie z próbą generalną i planem wycofania. W naszych planach jest częścią pracy, po której utrzymujemy nowy backend, z monitoringiem i awaryjnym wsparciem produkcji.