როგორ გადავიტანოთ Lovable-იდან Mythex-ზე (კოდი, მონაცემები და დომენი)

Lovable-იდან Mythex-ზე მიგრაციისთვის კოდი Lovable-იდან მისი GitHub ინტეგრაციით გამოიტანეთ, შემდეგ Mythex-ის პროექტში შემოიტანეთ რეპოზიტორიის დაკავშირებით ან არქივის ატვირთვით, ხელახლა დაამატეთ საიდუმლოებები და გამოქვეყნებამდე Preview-ში შეამოწმეთ. ფრონტენდი ჩვეულებრივ ცვლილებების გარეშე გადადის. ნამდვილი გადაწყვეტილებები ბექენდს ეხება: შეინარჩუნოთ არსებული Supabase პროექტი, ან მონაცემები სხვაგან გადაიტანოთ.

ეს გზამკვლევი მთელ გადასვლას თანმიმდევრობით გივლით და პირდაპირ ამბობს, რომელი ნაწილი მოითხოვს სამუშაოს.

დასაწყისში: რა ნამდვილად გადადის

Lovable აპლიკაცია რამდენიმე ნაწილისგან შედგება, და თითოეული განსხვავებულად გადადის.

პირველ რიგში ეს ცხრილი თქვენი აპლიკაციისთვის დაწერეთ. ეს ათ წუთს იკავებს და უმეტეს სიურპრიზს გაასწორებს.

ნაბიჯი 1: კოდის გამოტანა Lovable-იდან

Lovable-ის დოკუმენტაცია (2026 წლის სექტემბრის მდგომარეობით) ორ გზას აღწერს:

• GitHub სინქრონიზაცია. Lovable შეძლებს თქვენი პროექტის GitHub-ზე ექსპორტსა და ორმხრივ სინქრონიზაციას, და მისი დოკუმენტაცია github.com-ის მხარდაჭერას ყველა გეგმაზე ამბობს. დააკავშირეთ GitHub Lovable-ში და თქვენი კოდი თქვენს მფლობელობაში არსებულ რეპოზიტორიაში მოხვდება. გაითვალისწინეთ, რომ Lovable სინქრონიზაციას ერთ დროს ერთ ბრენჩზე ახორციელებს.
• კოდბაზის ჩამოტვირთვა. ფასიან გეგმებზე კოდი შეგიძლიათ პირდაპირ ჩამოტვირთოთ Project settings → Git-იდან.

მიგრაციისთვის GitHub უკეთესი გზაა: ისტორია სრულად გექნებათ, და ახალი გარემოს ტესტირების დროსაც შეგიძლიათ სინქრონიზაციის გაგრძელება. მიმდინარე ნაბიჯებისთვის იხილეთ Lovable-ის GitHub ინტეგრაციის დოკუმენტაცია.

Lovable-იდან წასვლამდე რეპოზიტორიაში შეამოწმეთ:

• .env ან .env.example ფაილი, რომელიც აპლიკაციისთვის საჭირო გარემოს ცვლადებს ჩამოთვლის
• supabase/ საქაღალდე, რომელიც შეიძლება მონაცემთა ბაზის მიგრაციებსა და Edge Function-ების კოდს შეიცავდეს
• package.json-ის სკრიპტები, რომლებიც აჩვენებს, როგორ აიგება და გაეშვება აპლიკაცია

ნაბიჯი 2: გადაწყვიტეთ, რა ვქნათ ბექენდთან

ეს ყველაზე მნიშვნელოვანი არჩევანია. Lovable აპლიკაციები ჩვეულებრივ მონაცემთა ბაზისა და ავტორიზაციისთვის Supabase-ს იყენებენ, ან თქვენს მიერ დაკავშირებული Supabase პროექტით, ან Lovable Cloud-ით.

ვარიანტი A: შეინარჩუნეთ თქვენი Supabase პროექტი

თუ თქვენი აპლიკაცია უკვე თქვენს Supabase პროექტთან საუბრობს, ეს ყველაზე მარტივი გზაა. აპლიკაციის კოდი იგივე Supabase URL-ს და იგივე გასაღებებს გამოიყენებს, ასე რომ თქვენი მონაცემები, მომხმარებლები და ფაილები ზუსტად იქ დარჩება, სადაც არიან. გადააქვთ მხოლოდ ფრონტენდი.

ვარიანტი B: გადასვლა Lovable Cloud-იდან

თუ თქვენი აპლიკაცია Lovable Cloud-ს იყენებს, Lovable აღწერს მონაცემთა ბაზის ექსპორტს მენიუში More → Cloud → Overview → Advanced settings. Lovable-ის დოკუმენტაციის მიხედვით (2026 წლის სექტემბრის მდგომარეობით):

• ექსპორტი შეიცავს მთელ მონაცემთა ბაზას, სტრუქტურასა და მონაცემებს, მათ შორის მომხმარებელთა ანგარიშებსა და მათ პაროლების ჰეშებს.
• ის არ შეიცავს საცავში არსებულ ფაილებს, Edge Function-ების კოდს და პროექტის საიდუმლოებებს. შესვლის პროვაიდერის პარამეტრებიც არ შედის.
• ექსპორტი მონაცემთა ბაზებს 15 GB-მდე ფარავს, ფაილი მაქსიმუმ 5 GB-ია, და ექსპორტის მოთხოვნა 24 საათში ერთხელ შეიძლება.
• Cloud-იდან Supabase-ზე ერთი დაწკაპუნებით მიგრაცია არ არსებობს, და Cloud-ის ბექენდის გადასატანად მხარდაჭერილი დანიშნულებებია მართული Supabase ან საკუთარ სერვერზე განთავსებული Supabase.

ამიტომ პრაქტიკული გზა, როგორც წესი, ასეთია: ექსპორტი აღადგინეთ თქვენს Supabase პროექტში, იქ ხელახლა შექმენით საცავის ბაქეტები, Edge Functions და ავტორიზაციის პარამეტრები, და შემდეგ ეს განიხილეთ როგორც ვარიანტი A. დეტალებისთვის იხილეთ Lovable-ის გაფართოებული პარამეტრების დოკუმენტაცია.

ვარიანტი C: ყველაფრის გადატანა Mythex-ის მონაცემთა ბაზაში

Mythex-ს პროექტისთვის შეუძლია გამოყოფილი Postgres მონაცემთა ბაზა მისცეს. თქვენი მონაცემების იქ გადატანა შესაძლებელია, მაგრამ ეს ნიშნავს, რომ ხელახლა უნდა დაწეროთ ყველა ადგილი, სადაც აპლიკაცია Supabase-ის კლიენტ ბიბლიოთეკას იყენებს, და Mythex-ს საბოლოო მომხმარებლის ჩაშენებული შესვლა არ აქვს, ანუ ცალკე ავტორიზაციის პროვაიდერსაც უნდა დააკავშიროთ. ეს ბექენდის ნამდვილი ხელახლა აშენებაა და არა მიგრაცია. გააკეთეთ ეს მოგვიანებით, თუ საერთოდ, მას შემდეგ რაც აპლიკაცია Supabase-ით Mythex-ზე იმუშავებს.

ნაბიჯი 3: კოდის შემოტანა Mythex-ში

შექმენით ახალი, ცარიელი პროექტი Mythex-ში. შემდეგ:

• არქივის შემოტანა. გახსენით project settings → Export → Import into this project და ატვირთეთ .zip, .tar.gz ან .tgz. GitHub-ის Download ZIP ღილაკი იძლევა ფაილს, რომელიც აქაც მუშაობს.
• GitHub-ის დაკავშირება და გამოტანა. დააკავშირეთ GitHub პროექტის პარამეტრებში, მიუთითეთ რეპოზიტორია და გაწიეთ კოდი. GitHub სინქრონიზაცია Pro-ს ფუნქციაა.

შემოტანა პროექტის ფაილებს ანაცვლებს, ამიტომ გამოიყენეთ ცარიელი პროექტი. არქივში არსებული ყველა .env ფაილი შემოტანისას იშლება, ასე რომ საიდუმლოებები შემთხვევით არ გადავა. წარმატებული შემოტანის შემდეგ Mythex-ს შეუძლია გახსნას ახალი ჩატი, სადაც აგენტი დაინსტალირებს დამოკიდებულებებს, გაარკვევს, როგორ გაეშვას აპლიკაცია და Preview-ს გააქტიურებს. ამ ჩატს ისე მართავთ, როგორც ნებისმიერ სხვას. დეტალები იხილეთ შემოტანის შემდეგ გვერდზე.

თუ Preview თავისით არ ამოქმედდა, ჰკითხეთ:

ეს პროექტი Lovable-იდან იყო ექსპორტირებული. ეს არის React + TypeScript + Tailwind აპლიკაცია, რომელიც Supabase-ს იყენებს. დააინსტალირე დამოკიდებულებები, package.json-იდან გაარკვიე dev ბრძანება და ამოქმედე Preview. აპლიკაციის კოდი ჯერ არ შეცვალო.

ნაბიჯი 4: საიდუმლოებების ხელახლა დამატება

გახსენით project settings → Secrets და დაამატეთ ყველა მნიშვნელობა, რომელიც აპლიკაციას სჭირდება. Supabase-ზე დაფუძნებული აპლიკაციისთვის ეს ჩვეულებრივ არის Supabase პროექტის URL და საჯარო (anon ან publishable) გასაღები. სახელები აიღეთ .env.example-დან ან იქიდან, სადაც კოდი მათ კითხულობს.

ორი წესი:

• ფრონტენდის ცვლადებში მხოლოდ საჯარო გასაღებები უნდა იყოს. Vite აპლიკაციაში ყველაფერი VITE_ პრეფიქსით ჩაიწერება JavaScript-ში, რომელსაც ყოველი ვიზიტორი გადმოწერს.
• Supabase-ის service role გასაღები ფრონტენდის კოდში არასდროს ჩაწეროთ. თუ სერვერულ ფუნქციას ის სჭირდება, ის სერვერზე რჩება.

შემდეგ სთხოვეთ აგენტს დაადასტუროს, რომ აპლიკაცია მათ კითხულობს:

შეამოწმე, რომელ გარემოს ცვლადებს კითხულობს ეს აპლიკაცია. ჩამოთვალე ის, რომლებიც ჯერ პროექტის საიდუმლოებებში არ არის დაყენებული, და მათი მნიშვნელობები არ დაბეჭდო.

ჩვენი გზამკვლევი გარემოს ცვლადებისა და საიდუმლოებების შესახებ განმარტავს საჯარო და პირადი მნიშვნელობების განსხვავებას.

ნაბიჯი 5: ყველაფრის შეცვლამდე შეამოწმეთ

თქვენი Lovable აპლიკაცია ჯერ კიდევ მუშაობს, ამიტომ არ ჩქარობთ. შეამოწმეთ Mythex-ის ვერსია Preview-ში რეალურ პროცესებზე:

• რეგისტრაცია, შესვლა, გასვლა და პაროლის აღდგენა
• ჩანაწერის შექმნა, რედაქტირება და წაშლა
• ფაილის ატვირთვა, თუ აპლიკაცია ამას აკეთებს
• ყველაფერი, რაც Edge Function-ს ან მესამე მხარის API-ს იძახებს

Supabase-ის ავტორიზაციას აქვს ერთი პარამეტრი, რომელიც ადვილად გამოგრჩებათ: redirect URL-ები, რომლებიც დაშვებულია შესვლისა და პაროლის აღდგენის ელფოსტებისთვის. დაამატეთ იქ თქვენი Mythex-ის preview და გამოქვეყნებული მისამართები, წინააღმდეგ შემთხვევაში შესვლა ძველ დომენზე დაგაბრუნებთ.

Mythex-ის /test ბრძანებას შეუძლია აგენტს დააყენოს, რომ თქვენს preview-ში მომხმარებლივით გაიაროს და გატეხილი პროცესები მოგახსენოთ. უფრო სრული ჩეკლისტისთვის იხილეთ ჩვენი გზამკვლევი აპლიკაციის ტესტირება გაშვებამდე.

ნაბიჯი 6: გამოქვეყნება და დომენის გადატანა

როცა ყველაფერი მუშაობს, სამუშაო სივრცედან გამოაქვეყნეთ, რომ მიიღოთ <slug>.mythex.app მისამართი. კვლავ შეამოწმეთ იქაც, რადგან გამოქვეყნებული აპლიკაცია თქვენი პროექტის ცალკე სნეპშოტია.

Pro გეგმაზე შეგიძლიათ საკუთარი დომენის დაკავშირება. განაახლეთ DNS ჩანაწერები თქვენს დომენის პროვაიდერთან, დაამატეთ ახალი მისამართი Supabase-ის დაშვებულ redirect URL-ებში და მხოლოდ ამის შემდეგ გათიშეთ Lovable-ის ვერსია. ნაბიჯ-ნაბიჯ DNS-ს ფარავს ჩვენი გზამკვლევი მორგებული დომენის დაკავშირების შესახებ.

გავრცელებული შეცდომები

• მონაცემთა ბაზისა და ფრონტენდის ერთდროულად გადატანა. ჯერ გადაიტანეთ ფრონტენდი, დაამტკიცეთ, რომ არსებულ ბექენდთან მუშაობს, და შემდეგ გადაწყვიტეთ მონაცემების ბედი.
• Edge Function-ების დავიწყება. თუ აპლიკაცია Supabase Edge Functions-ს იძახებს, ისინი ან Supabase-ზე რჩება, ან სერვერულ კოდად უნდა გადაიწეროს. Vite ფრონტენდში ისინი არ მუშაობს.
• service role გასაღების ჩასმა ფრონტენდში. ის ნებისმიერს, ვინც devtools-ს გახსნის, სრულ წვდომას აძლევს თქვენს მონაცემთა ბაზაზე.
• გამოტოვებული redirect URL-ები ავტორიზაციაში. შესვლა Preview-ში მუშაობს, შემდეგ კი რეალურ დომენზე წყდება.
• DNS-ის გადართვა გამოქვეყნებული URL-ის ტესტირებამდე. ჯერ შეამოწმეთ mythex.ai მისამართი; DNS-ის ცვლილების უკან დაბრუნებას დრო სჭირდება.
• შემოტანა პროექტში, სადაც სამუშაო უკვე გაქვთ. შემოტანა ფაილებს ანაცვლებს. გამოიყენეთ ახალი პროექტი.

როდის აზრი აქვს Lovable-ზე დარჩენას

გულწრფელად შეაფასეთ, რატომ გადადიხართ. Lovable გთავაზობთ წინასწარ ვიზუალურ რედაქტირებას preview-ზე და პროდუქტიზებულ ბექენდს Lovable Cloud-ით, Mythex-ს კი არც ერთი არ აქვს. თუ ყოველდღიურად სწორედ ეს გჭირდებათ, გადასვლა მეტს დაგიჯდებათ, ვიდრე მოგცემთ. Mythex უფრო შესაფერისია, თუ გინდათ რეალური კოდის რედაქტორი და ტერმინალი ჩატის გვერდით, ერთი კრედიტების ბალანსი აშენებისა და ჰოსტინგისთვის, ან სხვა სტეკის გაშვება. ჩვენი Lovable-ის ალტერნატივების გზამკვლევი და Mythex vs Lovable გვერდი მათ უფრო დეტალურად ადარებს.

მიგრაციის ჩეკლისტი

• ჩამოთვლილია აპლიკაციის ყველა ნაწილი: კოდი, მონაცემთა ბაზა, მომხმარებლები, ფაილები, ფუნქციები, საიდუმლოებები, დომენი
• კოდი სინქრონიზებულია თქვენს მფლობელობაში არსებულ GitHub რეპოზიტორიაში
• მიღებულია ბექენდის გადაწყვეტილება (Supabase-ის შენარჩუნება, ან ექსპორტი Lovable Cloud-იდან)
• კოდი შემოტანილია ცარიელ Mythex პროექტში, Preview მუშაობს
• საიდუმლოებები ხელახლა დამატებულია; VITE_ ცვლადებში პირადი გასაღებები არ არის
• ავტორიზაციის redirect URL-ები განახლებულია ახალი მისამართებისთვის
• რეგისტრაცია, შესვლა, ძირითადი მონაცემების პროცესები და ატვირთვები შემოწმებულია Preview-ში
• გამოქვეყნებულია და ხელახლა შემოწმებულია mythex.ai მისამართზე
• DNS გადატანილია; ძველი აპლიკაცია მხოლოდ ახლის დადასტურების შემდეგ გაითიშა

Mythex-ის მხარისთვის იხილეთ GitHub, ექსპორტი და შემოტანა დოკუმენტაციაში.

კითხვები