Si të migrosh nga Lovable në Mythex (kodi, të dhënat dhe domain-i)

Për të migruar nga Lovable në Mythex, nxirr kodin nga Lovable përmes integrimit të tij me GitHub, pastaj sille në një projekt Mythex duke lidhur repo-n ose duke importuar një arkiv, rishto sekretet dhe testo në Preview përpara se të publikosh. Frontend-i zakonisht zhvendoset pa ndryshime. Vendimet e vërteta lidhen me backend-in: mban projektin tënd ekzistues Supabase, ose zhvendos të dhënat diku tjetër.

Ky udhëzues të çon në rend nëpër gjithë zhvendosjen, dhe është i sinqertë për pjesët që kërkojnë punë.

Para se të fillosh: çfarë zhvendoset realisht

Një aplikacion Lovable është disa gjëra të ndryshme, dhe secila zhvendoset ndryshe.

Shkruaje këtë tabelë për aplikacionin tënd para së gjithash. Merr dhjetë minuta dhe parandalon shumicën e surprizave.

Hapi 1: Nxirr kodin nga Lovable

Dokumentacioni i Lovable (që nga shtatori 2026) përshkruan dy mënyra për ta nxjerrë:

• Sinkronizim me GitHub. Lovable mund të eksportojë dhe të sinkronizojë në dy drejtime projektin tënd me GitHub, dhe dokumentacioni i tij liston mbështetjen e github.com në të gjitha planet. Lidh GitHub në Lovable, dhe kodi yt shkon në një repo që të përket ty. Vër re se Lovable sinkronizon një degë në të njëjtën kohë.
• Shkarko kodbazën. Në planet me pagesë të Lovable mund ta shkarkosh kodin direkt nga Project settings → Git.

GitHub është rruga më e mirë për një migrim: merr historikun e plotë, dhe mund të vazhdosh sinkronizimin ndërsa teston konfigurimin e ri. Shih dokumentacionin e integrimit me GitHub të Lovable për hapat aktualë.

Para se të largohesh nga Lovable, hap repo-n dhe kërko:

• Një skedar .env ose .env.example, që liston variablat e mjedisit që pret aplikacioni
• Një dosje supabase/, që mund të mbajë migrime të bazës së të dhënave dhe kodin e Edge Functions
• Skriptet e package.json, që tregojnë si ndërtohet dhe ekzekutohet aplikacioni

Hapi 2: Vendos çfarë do të bësh me backend-in

Ky është zgjedhja që ka më shumë peshë. Aplikacionet Lovable zakonisht përdorin Supabase për bazën e të dhënave dhe hyrjen, ose përmes një projekti Supabase që ke lidhur vetë, ose përmes Lovable Cloud.

Opsioni A: Mbaj projektin tënd Supabase

Nëse aplikacioni yt tashmë flet me projektin tënd Supabase, kjo është rruga më e thjeshtë. Kodi i aplikacionit vazhdon të thërrasë të njëjtin URL Supabase me të njëjtat çelësa, kështu që të dhënat, përdoruesit dhe skedarët mbeten pikërisht aty ku janë. Zhvendos vetëm frontend-in.

Opsioni B: Largohu nga Lovable Cloud

Nëse aplikacioni yt përdor Lovable Cloud, Lovable dokumenton një eksport të bazës së të dhënave nën More → Cloud → Overview → Advanced settings. Sipas dokumentacionit të Lovable (që nga shtatori 2026):

• Eksporti përmban të gjithë bazën e të dhënave, strukturën dhe të dhënat, përfshirë llogaritë e përdoruesve dhe hash-et e fjalëkalimeve të tyre.
• Nuk përfshin skedarët në hapësirën e ruajtjes, kodin e Edge Functions, ose sekretet e projektit. Cilësimet e ofruesit të hyrjes gjithashtu nuk përfshihen.
• Eksporti mbulon baza të dhënash deri në 15 GB, skedari mund të jetë më së shumti 5 GB, dhe mund të kërkosh një eksport çdo 24 orë.
• Nuk ka migrim me një klik nga Cloud në Supabase, dhe destinacionet e mbështetura për zhvendosjen e backend-it Cloud janë Supabase i menaxhuar ose Supabase i vetë-strehuar.

Rrjedhimisht rruga praktike zakonisht është: rikthe eksportin në projektin tënd Supabase, ri-krijo bucket-et e ruajtjes, Edge Functions dhe cilësimet e autentikimit atje, dhe pastaj trajtoje si Opsionin A. Shih cilësimet e avancuara të Lovable për detajet.

Opsioni C: Zhvendos gjithçka te baza e të dhënave e Mythex

Mythex mund t'i japë një projekti një bazë të dhënash Postgres të dedikuar. Zhvendosja e të dhënave atje është e mundur, por do të thotë të rishkruash çdo vend ku aplikacioni përdor bibliotekën klient të Supabase, dhe meqenëse Mythex nuk ka hyrje të integruar për përdoruesit fundorë, do të duhet të lidhësh edhe një ofrues të veçantë autentikimi. Kjo është një ri-ndërtim i vërtetë i backend-it, jo një migrim. Bëje më vonë, nëse del nevoja, kur aplikacioni të jetë duke funksionuar në Mythex me Supabase.

Hapi 3: Sill kodin në Mythex

Krijo një projekt të ri, bosh në Mythex. Pastaj ose:

• Importo një arkiv. Hap project settings → Export → Import into this project dhe ngarko një .zip, .tar.gz ose .tgz. Butoni Download ZIP i GitHub të jep një skedar që funksionon këtu.
• Lidh GitHub dhe tërhiq. Lidh GitHub në cilësimet e projektit, lidh repo-n dhe tërhiq. Sinkronizimi me GitHub është një funksion i planit Pro.

Importi zëvendëson skedarët e projektit, prandaj përdor një projekt bosh. Çdo skedar .env në arkiv hiqet gjatë importit, kështu që asnjë sekret nuk udhëton pa dashje. Pas një importi të suksesshëm, Mythex mund të hapë një bisedë të re ku agjenti instalon varësitë, kupton si ekzekutohet aplikacioni dhe e ngrit Preview-n. Mund ta drejtosh atë bisedë si çdo tjetër. Detajet janë në Pas importit.

Nëse Preview nuk ngrihet vetë, pyet:

Ky projekt është eksportuar nga Lovable. Është një aplikacion React + TypeScript + Tailwind që përdor Supabase. Instalo varësitë, gjej komandën e zhvillimit nga package.json, dhe ngre Preview. Mos ndrysho ende asnjë kod aplikacioni.

Hapi 4: Rishto sekretet

Hap project settings → Secrets dhe shto çdo vlerë që i duhet aplikacionit. Për një aplikacion të mbështetur nga Supabase kjo zakonisht do të thotë URL-ja e projektit Supabase dhe çelësi publik (anon ose publishable). Merr emrat nga .env.example ose nga vendi ku i lexon kodi.

Dy rregulla:

• Vetëm çelësat publikë i përkasin variablave të frontend-it. Në një aplikacion Vite, çdo gjë me prefiks VITE_ futet në JavaScript që shkarkon çdo vizitor.
• Asnjëherë mos vendos çelësin service role të Supabase në kodin e frontend-it. Nëse një funksion në server e ka nevojë, mbetet në server.

Pastaj kërko agjentit të konfirmojë që aplikacioni i lexon ato:

Kontrollo cilat variabla mjedisi lexon ky aplikacion. Listo ato që nuk janë vendosur ende në sekretet e projektit, dhe mos i shfaq vlerat e tyre.

Udhëzuesi ynë për variablat e mjedisit dhe sekretet shpjegon ndryshimin midis vlerave publike dhe private.

Hapi 5: Testo para se të ndërrosh diçka

Aplikacioni yt Lovable është ende aktiv, prandaj nuk ka nxitim. Testo versionin në Mythex në Preview me rrjedhat reale:

• Regjistrohu, hyr, dil, dhe rivendos një fjalëkalim
• Krijo, redakto dhe fshi një rekord
• Ngarko një skedar, nëse aplikacioni yt e bën këtë
• Çdo gjë që thërret një Edge Function ose një API të palës së tretë

Autentikimi Supabase ka një cilësim të lehtë për t'u harruar: URL-të e ridrejtimit të lejuara për email-et e hyrjes dhe rivendosjes së fjalëkalimit. Shto adresat e tua Mythex të Preview dhe të publikuara atje, ose hyrjet do të kthehen te domain-i i vjetër.

Komanda /test e Mythex e bën agjentin të klikojë nëpër preview-n tënd si përdorues dhe të raportojë rrjedhat e prishura. Udhëzuesi ynë për testimin e aplikacionit para lansimit ka një listë më të plotë kontrolli.

Hapi 6: Publiko dhe zhvendos domain-in

Kur gjithçka funksionon, publiko nga hapësira e punës për të marrë një adresë <slug>.mythex.app. Testo përsëri aty, sepse aplikacioni i publikuar është një pamje e veçantë e projektit tënd.

Në Pro mund të lidhësh domain-in tënd. Përditëso rekordet DNS te ofruesi i domain-it, shto adresën e re te URL-të e lejuara të ridrejtimit të Supabase, dhe vetëm atëherë hiq versionin Lovable. Udhëzuesi ynë për lidhjen e një domain-i të personalizuar mbulon DNS hap pas hapi.

Gabimet më të shpeshta

• Zhvendosja e bazës së të dhënave dhe e frontend-it në të njëjtën kohë. Zhvendos së pari frontend-in, vërtetoje që funksionon me backend-in ekzistues, dhe pastaj vendos për të dhënat.
• Harrimi i Edge Functions. Nëse aplikacioni thërret Edge Functions të Supabase, ato ose mbeten në Supabase ose duhet ri-shkruar si kod serveri. Ato nuk ekzekutohen brenda një frontend-i Vite.
• Ngjitja e çelësit service role në frontend. Jep akses të plotë në bazën e të dhënave të çdo kujt që hap devtools.
• Mungesa e URL-ve të ridrejtimit të autentikimit. Hyrja funksionon në Preview, pastaj dështon në domain-in e vërtetë.
• Ndërrimi i DNS para testimit të URL-së së publikuar. Testo fillimisht adresën mythex.ai; ndryshimet e DNS kërkojnë kohë për t'u kthyer.
• Importimi në një projekt që ka punë brenda. Importi zëvendëson skedarët. Përdor një projekt të ri.

Kur ka kuptim të mbetesh në Lovable

Bëhu i sinqertë me vetveten për arsyen pse po zhvendosesh. Lovable ofron ndryshime vizuale me klikime në preview dhe një backend të produktizuar me Lovable Cloud, dhe Mythex s'ka asnjërin prej tyre. Nëse ato janë ato që përdor çdo ditë, zhvendosja të kushton më shumë se sa fiton. Mythex është më i përshtatshëm nëse do një redaktor kodi dhe terminal të vërtetë pranë bisedës, një bilanc të vetëm kreditesh për ndërtimin dhe strehimin, ose do të përdorësh një stack tjetër. Udhëzuesi ynë për alternativat e Lovable dhe faqja Mythex kundrejt Lovable i krahasojnë më hollësisht.

Lista e kontrollit për migrimin

• Të listuara çdo pjesë e aplikacionit: kodi, baza e të dhënave, përdoruesit, skedarët, funksionet, sekretet, domain-i
• Kodi i sinkronizuar me një repo GitHub që të përket ty
• Vendimi për backend-in i marrë (mban Supabase, ose eksporto nga Lovable Cloud)
• Kodi i importuar në një projekt Mythex bosh, Preview në punë
• Sekretet e rishtuara; asnjë çelës privat në variablat VITE_
• URL-të e ridrejtimit të autentikimit të përditësuara për adresat e reja
• Regjistrimi, hyrja, rrjedhat kryesore të të dhënave dhe ngarkimet e testuara në Preview
• Publikuar dhe ri-testuar në adresën mythex.ai
• DNS i zhvendosur; aplikacioni i vjetër hiqet vetëm pasi i riu është konfirmuar

Për anën e Mythex, shih GitHub, eksporti dhe importi në dokumentacion.

Pyetje