Átköltözés a Lovable-ról a Mythexre (kód, adatok és domain)

A Lovable-ról a Mythexre költözéshez először vidd ki a kódodat a Lovable GitHub-integrációján át, majd hozd be egy Mythex-projektbe az összekapcsolt tároló vagy egy archívum importálásával, add újra a titkos kulcsaidat, és teszteld a Preview-ban, mielőtt publikálnál. A frontend általában változtatás nélkül költözik. A valódi döntések a backendről szólnak: megtartod a meglévő Supabase-projektedet, vagy máshová viszed az adatokat.

Ez az útmutató sorrendben végigvezet a teljes költözésen, és őszinte arról, mely részek igényelnek munkát.

Először: mi költözik valójában

Egy Lovable-app több dologból áll, és mindegyik máshogy költözik.

Írd le ezt a táblázatot a saját appodra előbb. Tíz percet vesz igénybe, és a legtöbb meglepetést megelőzi.

1. lépés: Vidd ki a kódot a Lovable-ból

A Lovable dokumentációja (2026 szeptemberétől) két kiviteli módot ír le:

• GitHub-szinkronizálás. A Lovable exportálhatja és kétirányúan szinkronizálhatja a projektedet a GitHubbal, a dokumentációjuk szerint minden csomagban támogatott a github.com. Kösd össze a GitHubot a Lovable-ben, és a kódod egy általad birtokolt tárolóba kerül. Vedd figyelembe, hogy a Lovable egyszerre egy ágat szinkronizál.
• A kódbázis letöltése. A fizetős csomagokban közvetlenül letöltheted a kódot a Projektbeállítások → Git menüpontból.

A GitHub a jobb út egy költözéshez: megkapod a teljes előzményeket, és az új beállítás tesztelése közben tovább szinkronizálhatsz. A friss lépésekért nézd meg a Lovable GitHub-integrációs dokumentációját.

Mielőtt elhagyod a Lovable-t, nyisd meg a tárolót, és keresd:

• Egy .env vagy .env.example fájlt, amely felsorolja az app által várt környezeti változókat
• Egy supabase/ mappát, amely adatbázis-migrációkat és Edge Function kódot tartalmazhat
• A package.json scripteket, amelyek megmutatják, hogyan épül és fut az app

2. lépés: Döntsd el, mi legyen a backenddel

Ez a legfontosabb választás. A Lovable-appok jellemzően Supabase-t használnak az adatbázishoz és a bejelentkezéshez, vagy egy általad összekötött Supabase-projekten, vagy a Lovable Cloudon keresztül.

A. lehetőség: Megtartod a saját Supabase-projektedet

Ha az appod már a saját Supabase-projektedhez csatlakozik, ez a legegyszerűbb út. Az app kódja ugyanazt a Supabase URL-t és ugyanazokat a kulcsokat hívja tovább, így az adataid, felhasználóid és fájljaid pontosan ugyanott maradnak. Csak a frontendet mozgatod.

B. lehetőség: Kiköltözés a Lovable Cloudról

Ha az appod a Lovable Cloudot használja, a Lovable egy adatbázis-exportot dokumentál a Több → Cloud → Áttekintés → Speciális beállítások menüpont alatt. A Lovable dokumentációja szerint (2026 szeptemberétől):

• Az export tartalmazza a teljes adatbázist, a struktúrát és az adatokat, beleértve a felhasználói fiókokat és a jelszó-hash-eiket.
• Nem tartalmazza a tárolt fájlokat, az Edge Function kódot és a projekt titkos kulcsait. A bejelentkezési szolgáltató beállításai sem kerülnek bele.
• Az exportok legfeljebb 15 GB-os adatbázist fednek le, a fájl legfeljebb 5 GB lehet, és 24 óránként csak egy exportot kérhetsz.
• Nincs egykattintásos költözés a Cloudról a Supabase-re; a Cloud backend támogatott célállomásai a kezelt Supabase vagy a saját üzemeltetésű Supabase.

A gyakorlatban tehát általában így jársz el: visszaállítod az exportot a saját Supabase-projektedbe, újra létrehozod ott a tárolóbucketeket, az Edge Functionöket és az auth-beállításokat, és onnantól az A. lehetőségként kezeled. A részletekért lásd a Lovable speciális beállítások dokumentációját.

C. lehetőség: Minden átköltözik a Mythex adatbázisába

A Mythex egy projekthez dedikált Postgres-adatbázist tud adni. Az adataid oda költöztetése lehetséges, de azt jelenti, hogy az app minden helyét át kell írnod, ahol a Supabase klienskönyvtárát használja, és a Mythexnek nincs beépített végfelhasználói bejelentkezése, így egy külön auth-szolgáltatót is be kellene kötnöd. Ez valódi backend-újraépítés, nem költözés. Ezt később csináld meg, ha egyáltalán, miután az app már Supabase-zel fut a Mythexen.

3. lépés: Hozd be a kódot a Mythexbe

Hozz létre egy új, üres projektet a Mythexben. Ezután vagy:

• Importálj egy archívumot. Nyisd meg a projektbeállítások → Exportálás → Importálás ebbe a projektbe menüpontot, és tölts fel egy .zip, .tar.gz vagy .tgz fájlt. A GitHub Letöltés ZIP-ként gombja olyan fájlt ad, amely itt működik.
• Kösd össze a GitHubot, és húzd be. Kösd össze a GitHubot a projektbeállításokban, kapcsold hozzá a tárolót, és húzd be. A GitHub-szinkronizálás a Pro csomag funkciója.

Az importálás lecseréli a projekt fájljait, ezért üres projektet használj. Az archívumban lévő .env fájlok importáláskor törlődnek, így titkos kulcs nem utazik véletlenül. Sikeres import után a Mythex új chatet nyithat, ahol az agent telepíti a függőségeket, kitalálja, hogyan kell futtatni az appot, és elindítja a Preview-t. Ezt a chatet ugyanúgy irányíthatod, mint bármelyik másikat. A részletek az Importálás után oldalon vannak.

Ha a Preview nem indul el magától, kérd:

Ez a projekt Lovable-ből lett exportálva. React + TypeScript + Tailwind app, amely Supabase-t használ. Telepítsd a függőségeket, állapítsd meg a package.json alapján a dev parancsot, és indítsd el a Preview-t. Még ne változtass az app kódján.

4. lépés: Add újra a titkos kulcsaidat

Nyisd meg a projektbeállítások → Titkos kulcsok menüpontot, és add hozzá minden értéket, amelyre az appnak szüksége van. Egy Supabase-alapú appnál ez általában a Supabase projekt URL-je és a nyilvános (anon vagy publishable) kulcs. A neveket a .env.example fájlból vagy abból a helyből vedd, ahonnan a kód olvassa őket.

Két szabály:

• Csak nyilvános kulcs való frontend-változóba. Egy Vite-appban minden VITE_ előtagú érték beépül abba a JavaScriptbe, amelyet minden látogató letölt.
• Soha ne tedd a Supabase service role kulcsát frontend-kódba. Ha egy szerveroldali függvénynek kell, az maradjon a szerveroldalon.

Ezután kérd meg az agentet, hogy erősítse meg, az app melyik változókat olvassa:

Ellenőrizd, mely környezeti változókat olvassa ez az app. Sorold fel azokat, amelyek még nincsenek beállítva a projekt titkos kulcsai között, és ne írd ki az értékeiket.

A környezeti változók és titkos kulcsok útmutató elmagyarázza a nyilvános és a privát értékek közötti különbséget.

5. lépés: Teszteld, mielőtt bármit átkapcsolnál

A Lovable-appod még él, nincs ok sietni. Teszteld a Mythex-verziót a Preview-ban valódi folyamatokkal:

• Regisztráció, bejelentkezés, kijelentkezés, jelszó-visszaállítás
• Rekord létrehozása, szerkesztése, törlése
• Fájlfeltöltés, ha az app ezt csinálja
• Minden, ami Edge Functiont vagy harmadik féltől származó API-t hív

A Supabase authentikációnak van egy könnyen elfelejthető beállítása: a bejelentkezési és jelszó-visszaállító e-mailekhez engedélyezett átirányítási URL-ek. Add hozzá a Mythex preview- és publikált címeidet, különben a bejelentkezés a régi domainre dob vissza.

A Mythex /test parancsa az agentet arra utasítja, hogy kattintson végig a preview-don, mint egy felhasználó, és jelentse a törött folyamatokat. A tesztelés indítás előtt útmutató részletesebb ellenőrzőlistát ad.

6. lépés: Publikálás és a domain átköltöztetése

Ha minden működik, publikálj a munkaterületről, és kapsz egy <slug>.mythex.app címet. Teszteld újra ott is, mert a publikált app a projekted külön pillanatképe.

A Pro csomagon csatlakoztathatod a saját domainedet. Frissítsd a DNS-rekordokat a domain-szolgáltatódnál, add hozzá az új címet a Supabase engedélyezett átirányítási URL-jei közé, és csak ezután vedd le a Lovable-verziót. A egyedi domain csatlakoztatása útmutató lépésenként lefedi a DNS-t.

Gyakori hibák

• Az adatbázis és a frontend egyszerre költöztetése. Előbb a frontendet vidd át, bizonyítsd be, hogy működik a meglévő backenddel, és csak utána dönts az adatokról.
• Az Edge Functionök elfelejtése. Ha az app Supabase Edge Functionöket hív, azok vagy a Supabase-en maradnak, vagy szerverkódként kell újraírni őket. Nem futnak egy Vite-frontendben.
• A service role kulcs beillesztése a frontendbe. Teljes hozzáférést ad az adatbázisodhoz bárkinek, aki megnyitja a fejlesztői eszközöket.
• Hiányzó auth-átirányítási URL-ek. A bejelentkezés működik a Preview-ban, majd a valódi domainen elbukik.
• DNS átállítása a publikált URL tesztelése nélkül. Teszteld előbb a mythex.ai címet; a DNS-változtatás visszavonása időbe telik.
• Importálás olyan projektbe, amelyben már van munka. Az importálás lecseréli a fájlokat. Használj friss projektet.

Mikor érdemes a Lovable-nál maradni

Legyél őszinte magaddal arról, miért költözöl. A Lovable pontkattintásos vizuális szerkesztést kínál a preview-n, és a Lovable Cloud termékszintű backendet ad; a Mythexnek egyik sincs. Ha ezekre támaszkodsz a mindennapokban, a költözés többe kerül, mint amennyit nyersz. A Mythex akkor jobb választás, ha valódi kódszerkesztőt és terminált akarsz a chat mellett, egy kreditegyenleget az építéshez és a hostinghoz, vagy más stacket szeretnél futtatni. A Lovable-alternatívák útmutató és a Mythex vs Lovable oldal részletesebben összehasonlítja őket.

Átköltözési ellenőrzőlista

• Felsorolva az app minden része: kód, adatbázis, felhasználók, fájlok, függvények, titkos kulcsok, domain
• A kód szinkronizálva egy általad birtokolt GitHub-tárolóba
• A backend-döntés megszületett (Supabase megtartása, vagy export a Lovable Cloudból)
• A kód egy üres Mythex-projektbe importálva, a Preview fut
• A titkos kulcsok újra megadva; nincs privát kulcs VITE_ változóban
• Az auth-átirányítási URL-ek frissítve az új címekre
• Regisztráció, bejelentkezés, fő adatfolyamok és feltöltések tesztelve a Preview-ban
• Publikálva és újratesztelve a mythex.ai címen
• DNS átállítva; a régi appot csak az új megerősítése után veszed le

A Mythex oldali részletekért lásd a GitHub, export és import részt a dokumentációban.

Kérdések