Cum migrezi de la Lovable la Mythex (cod, date și domeniu)

Ca să migrezi de la Lovable la Mythex, scoate codul din Lovable prin integrarea lor cu GitHub, apoi adu-l într-un proiect Mythex legând repository-ul sau importând o arhivă, readaugă secretele și testează în Preview înainte de publicare. Frontend-ul de obicei se mută fără modificări. Deciziile reale sunt despre backend: păstrezi proiectul tău Supabase existent sau muți datele în altă parte.

Acest ghid parcurge toată mutarea în ordine și este sincer despre părțile care cer muncă.

Înainte să începi: ce se mută efectiv

O aplicație Lovable este mai multe lucruri, iar fiecare se mută diferit.

Scrie acest tabel pentru propria ta aplicație înainte de orice altceva. Durează zece minute și previne majoritatea surprizelor.

Pasul 1: Scoate codul din Lovable

Documentația Lovable (la zi în septembrie 2026) descrie două modalități de a ieși:

• Sincronizare cu GitHub. Lovable poate exporta și sincroniza bidirecțional proiectul cu GitHub, iar documentația lor listează suportul pentru github.com pe toate planurile. Conectează GitHub în Lovable, iar codul ajunge într-un repository care îți aparține. Ține cont că Lovable sincronizează câte o ramură pe rând.
• Descarcă baza de cod. Pe planurile plătite Lovable, poți descărca codul direct din Project settings → Git.

GitHub este varianta mai bună pentru o migrare: păstrezi tot istoricul și poți continua sincronizarea cât testezi noua configurație. Vezi documentația integrării GitHub de la Lovable pentru pașii actuali.

Înainte să părăsești Lovable, deschide repository-ul și caută:

• Un fișier .env sau .env.example, care listează variabilele de mediu pe care le așteaptă aplicația
• Un folder supabase/, care poate conține migrări de bază de date și cod de Edge Functions
• Scripturile din package.json, care arată cum se construiește și se rulează aplicația

Pasul 2: Decide ce faci cu backend-ul

Aceasta este alegerea cea mai importantă. Aplicațiile Lovable folosesc de obicei Supabase pentru baza de date și autentificare, fie printr-un proiect Supabase pe care l-ai conectat tu, fie prin Lovable Cloud.

Varianta A: Păstrează propriul tău proiect Supabase

Dacă aplicația ta deja vorbește cu propriul tău proiect Supabase, aceasta este cea mai simplă cale. Codul aplicației continuă să apeleze același URL Supabase cu aceleași chei, deci datele, utilizatorii și fișierele rămân exact unde sunt. Muți doar frontend-ul.

Varianta B: Mută-te din Lovable Cloud

Dacă aplicația ta folosește Lovable Cloud, Lovable documentează un export al bazei de date în More → Cloud → Overview → Advanced settings. Conform documentației Lovable (la zi în septembrie 2026):

• Exportul conține întreaga bază de date, structura și datele, inclusiv conturile utilizatorilor și hash-urile parolelor.
• Nu include fișierele din stocare, codul Edge Functions sau secretele proiectului. Nici setările furnizorilor de autentificare nu sunt incluse.
• Exporturile acoperă baze de date de până la 15 GB, fișierul poate avea cel mult 5 GB, iar poți cere un export la fiecare 24 de ore.
• Nu există migrare cu un singur clic de la Cloud la Supabase, iar destinațiile acceptate pentru mutarea backend-ului Cloud sunt Supabase gestionat sau Supabase self-hosted.

Așadar, calea practică este de obicei: restaurezi exportul în propriul tău proiect Supabase, recreezi bucket-urile de stocare, Edge Functions și setările de autentificare acolo, și apoi tratezi situația ca Varianta A. Vezi documentația Lovable despre setările avansate pentru detalii.

Varianta C: Mută totul în baza de date Mythex

Mythex poate oferi unui proiect o bază de date Postgres dedicată. Mutarea datelor acolo este posibilă, dar înseamnă rescrierea fiecărui loc în care aplicația folosește biblioteca client Supabase, iar Mythex nu are autentificare integrată pentru utilizatorii finali, deci ar trebui să conectezi separat un furnizor de autentificare. Este o reconstruire reală a backend-ului, nu o migrare. Fă-o mai târziu, dacă e cazul, după ce aplicația rulează pe Mythex cu Supabase.

Pasul 3: Adu codul în Mythex

Creează un proiect nou, gol, în Mythex. Apoi fie:

• Importă o arhivă. Deschide project settings → Export → Import into this project și încarcă un .zip, .tar.gz sau .tgz. Butonul Download ZIP de pe GitHub îți dă un fișier care funcționează aici.
• Conectează GitHub și trage codul. Conectează GitHub în setările proiectului, leagă repository-ul și fă pull. Sincronizarea GitHub este o funcție Pro.

Importul înlocuiește fișierele proiectului, deci folosește un proiect gol. Fișierele .env din arhivă sunt eliminate la import, astfel încât niciun secret nu călătorește din greșeală. După un import reușit, Mythex poate deschide un chat nou în care agentul instalează dependențele, află cum să pornească aplicația și pune Preview în funcțiune. Poți dirija acel chat ca orice alt chat. Detaliile sunt în După import.

Dacă Preview nu pornește de la sine, cere:

Acest proiect a fost exportat din Lovable. Este o aplicație React + TypeScript + Tailwind care folosește Supabase. Instalează dependențele, află comanda de dezvoltare din package.json și pune Preview în funcțiune. Nu schimba încă niciun cod al aplicației.

Pasul 4: Readaugă secretele

Deschide project settings → Secrets și adaugă fiecare valoare de care are nevoie aplicația ta. Pentru o aplicație bazată pe Supabase, asta înseamnă de obicei URL-ul proiectului Supabase și cheia publică (anon sau publishable). Ia numele din .env.example sau din locul unde codul le citește.

Două reguli:

• În variabilele de frontend intră doar chei publice. Într-o aplicație Vite, orice cu prefixul VITE_ este inclus în JavaScript-ul pe care îl descarcă fiecare vizitator.
• Niciodată nu pune cheia service role de Supabase în codul de frontend. Dacă o funcție de server are nevoie de ea, rămâne pe server.

Apoi cere agentului să confirme că aplicația le citește:

Verifică ce variabile de mediu citește această aplicație. Listează-le pe cele care nu sunt setate încă în secretele proiectului și nu afișa valorile lor.

Ghidul nostru despre variabile de mediu și secrete explică diferența dintre valorile publice și cele private.

Pasul 5: Testează înainte să schimbi ceva

Aplicația ta Lovable încă este live, deci nu există grabă. Testează versiunea Mythex în Preview, pe fluxuri reale:

• Înregistrare, autentificare, deconectare și resetarea parolei
• Creare, editare și ștergere a unei înregistrări
• Încărcarea unui fișier, dacă aplicația ta face asta
• Orice care apelează o Edge Function sau un API terț

Auth-ul Supabase are o setare ușor de ratat: URL-urile de redirecționare permise pentru emailurile de autentificare și resetare a parolei. Adaugă acolo adresele Mythex de preview și de publicare, altfel autentificările vor reveni pe vechiul domeniu.

Comanda /test din Mythex îi cere agentului să parcurgă preview-ul tău ca un utilizator și să raporteze fluxurile defecte. Ghidul nostru despre testarea aplicației înainte de lansare are o listă de verificare mai completă.

Pasul 6: Publică și mută domeniul

Când totul funcționează, publică din workspace ca să obții o adresă <slug>.mythex.app. Testează din nou acolo, pentru că aplicația publicată este un instantaneu separat al proiectului tău.

Pe planul Pro poți conecta propriul domeniu. Actualizează înregistrările DNS la furnizorul de domenii, adaugă noua adresă la URL-urile de redirecționare permise în Supabase și abia apoi scoate versiunea Lovable din funcțiune. Ghidul nostru despre conectarea unui domeniu propriu acoperă DNS-ul pas cu pas.

Greșeli frecvente

• Să muți baza de date și frontend-ul în același timp. Mută întâi frontend-ul, dovedește că funcționează cu backend-ul existent, apoi decide ce faci cu datele.
• Uitatul Edge Functions. Dacă aplicația apelează Supabase Edge Functions, acestea fie rămân pe Supabase, fie trebuie rescrise ca cod de server. Nu rulează în interiorul unui frontend Vite.
• Lipirea cheii service role în frontend. Îi oferă acces complet la baza ta de date oricui deschide devtools.
• URL-uri de redirecționare de autentificare lipsă. Autentificarea funcționează în Preview, apoi eșuează pe domeniul real.
• Schimbarea DNS-ului înainte de a testa URL-ul publicat. Testează întâi adresa mythex.ai; modificările DNS durează să fie anulate.
• Importul într-un proiect care are deja lucru. Importul înlocuiește fișierele. Folosește un proiect nou.

Când rămânerea pe Lovable are sens

Fii sincer cu tine în privința motivului pentru care muți. Lovable oferă modificări vizuale punct-și-click în preview și un backend de produs, Lovable Cloud, iar Mythex nu are niciuna dintre acestea. Dacă acestea sunt lucrurile de care depinzi zi de zi, mutarea te costă mai mult decât câștigi. Mythex este mai potrivit dacă vrei un editor de cod și un terminal reale lângă chat, un singur sold de credite pentru construcție și găzduire sau dacă vrei să rulezi o altă stivă tehnologică. Ghidul nostru despre alternative la Lovable și pagina Mythex vs Lovable compară cele două mai în detaliu.

Lista de verificare a migrării

• Am listat fiecare parte a aplicației: cod, bază de date, utilizatori, fișiere, funcții, secrete, domeniu
• Codul este sincronizat cu un repository GitHub care îmi aparține
• Decizia privind backend-ul este luată (păstrez Supabase sau export din Lovable Cloud)
• Codul este importat într-un proiect Mythex gol, Preview rulează
• Secretele sunt readăugate; nicio cheie privată în variabilele VITE_
• URL-urile de redirecționare ale autentificării sunt actualizate pentru noile adrese
• Înregistrarea, autentificarea, fluxurile de date principale și încărcările sunt testate în Preview
• Publicat și retestat la adresa mythex.ai
• DNS mutat; aplicația veche scoasă din funcțiune abia după confirmarea celei noi

Pentru partea Mythex, vezi GitHub, export și import în documentație.

Întrebări