Lovable विकल्प: नए builds और existing apps

Lovable के विकल्प दो श्रेणियों में आते हैं। वे अलग-अलग सवालों का जवाब देते हैं। जब आप कोई उत्पाद शुरू करते हैं, तो आप एक वर्कफ़्लो चुन रहे होते हैं और यह तय कर रहे होते हैं कि पहली पास काम करने के बाद कौन बैकएंड को चलाएगा। जब आप पहले से ही एक काम करने वाला Lovable ऐप चलाते हैं, तो आपका पहला काम एक सूची बनाना है: Lovable की अपनी डॉक्यूमेंटेशन में कहा गया है कि एप्लिकेशन सोर्स आपका है और इसे स्थानांतरित करना एक पुनर्लेखन के बजाय एक परिनियोजन परिवर्तन है। असली मेहनत कहीं और है। डेटा और सेवाएं असली काम की मांग करती हैं। नीचे क्रम में पाँच भाग दिए गए हैं: एक नई-निर्माण तालिका, वर्तमान पोर्टेबिलिटी तथ्य, एक फ्रेमवर्क जाँच, एक मौजूदा-ऐप तालिका और एक प्रोडक्शन स्वीकृति चेकलिस्ट।

दो पाठक, दो अलग-अलग निर्णय

शुरुआत से शुरू करते समय, तुलना करें कि प्रत्येक टूल आपके वर्कफ़्लो में कैसे फिट बैठता है और डेमो चलने के बाद आपको क्या बनाए रखना होगा। डेमो आसान हिस्सा है। बिल्डर से कहीं अधिक महत्वपूर्ण है कि छः महीने बाद कौन डेटाबेस, डिप्लॉयमेंट पाइपलाइन और लॉगिन सिस्टम को संचालित करता है।

पहले से काम करने वाले ऐप के लिए, इसे किसी अन्य टूल में फिर से बनाने की जल्दबाज़ी न करें। सूची से शुरुआत करें। पहचानें कि यह किस पर निर्भर करता है: कोड कहाँ रहता है, फ्रंटएंड कहाँ चलता है, कौन सा बैकएंड डेटा संग्रहीत करता है, और कौन सी AI सुविधाएं और कनेक्टर्स रनटाइम पर Lovable के माध्यम से काम करते हैं।

और यह वह हिस्सा है जिसे लोग छोड़ते हैं। Lovable पर रहना पूरी तरह से मान्य विकल्प है। Lovable की स्वामित्व गाइड अपने प्रबंधित सेटअप को अधिकांश ऐप्स के लिए सिफारिश के रूप में लेबल करती है और कहती है कि घटकों को केवल तभी स्थानांतरित करें जब आप कोई वास्तविक सीमा के साथ टकराएँ, जैसे डेटा रेजीडेंसी आवश्यकता, असमर्थित नेटवर्किंग या आत्म-प्रबंधित होस्टिंग की आवश्यकता वाली नीति। यदि इनमें से कोई भी लागू नहीं होता है और आपकी टीम में कोई भी अतिरिक्त संचालन के मालिक नहीं बनना चाहता, तो माइग्रेशन बिना कोई लाभ के एक खर्च है।

नई बिल्ड: निर्णय तालिका

यह तालिका मेरे निर्णय का प्रतिनिधित्व करती है। मैंने इसे प्रत्येक विक्रेता की अपनी डॉक्यूमेंटेशन से बनाया है जहाँ उपलब्ध है। यह एक रैंकिंग नहीं है, और यह कोई दावा नहीं करता कि कौन सा टूल बेहतर ऐप्स बनाता है।

अंतिम पंक्ति एक वर्कफ्लो का वर्णन करती है, कोई तैयार उत्पाद नहीं। आप स्वयं भागों को इकट्ठा करते हैं। आप एक स्टैक, एक होस्ट और एक एजेंट या एडिटर चुनते हैं, फिर सभी परिचालन कार्य को ले लेते हैं जो आगे सूचीबद्ध हैं। यदि आप उस मार्ग के लिए फ्रेमवर्क पर विचार कर रहे हैं, तो Astro बनाम Next.js और Next.js और Supabase पृष्ठ मानक शुरुआती बिंदु कवर करते हैं।

सबूत का कार्य हर उम्मीदवार के लिए समान आकार लेता है। इसे छोटा रखें, लेकिन इसे वास्तविक बनाएँ। लगातार डेटा, प्रमाणीकरण और एक लाइव तैनाती के साथ एक यथार्थवादी उपयोगकर्ता प्रवाह बनाएँ। एक जेनरेट की गई स्क्रीनशॉट कुछ साबित नहीं करती। खाता पंजीकृत करना, एक रिकॉर्ड को जारी रखना, साइन आउट करना, वापस साइन इन करना और उस रिकॉर्ड को फिर से देखना बहुत कुछ साबित करता है।

Lovable वास्तव में आपको क्या ले जाने देता है

वर्तमान पोर्टेबिलिटी तथ्य Lovable के deployment guide और ownership guide से आते हैं:

• Git sync सभी योजनाओं पर उपलब्ध है (GitHub, GitLab, Bitbucket)। कोडबेस डाउनलोड करना, एक बार का .zip स्नैपशॉट, सशुल्क योजनाओं पर उपलब्ध है।
• दोनों मार्ग आपको एप्लिकेशन स्रोत देते हैं, कॉन्फ़िगरेशन और डेटाबेस माइग्रेशन फ़ाइलों सहित। कोई भी आपके डेटाबेस में रिकॉर्ड या स्टोरेज में फ़ाइलें शामिल नहीं करता।
• डेटाबेस पंक्तियों और स्टोरेज फ़ाइलों को अलग से निर्यात की आवश्यकता है, और आप उन्हें गंतव्य पर मूल को सेवानिवृत्त करने से पहले सत्यापित करते हैं।
• आप Lovable को विकास उपकरण के रूप में रख सकते हैं जबकि दूसरा होस्ट उत्पादन परोसता है। Git sync के माध्यम से रिपॉज़िटरी को कनेक्ट करें और दूसरे होस्ट को इससे तैनात करने दें।

GitHub integration के लिए ध्यान देने योग्य बाधाएँ हैं। कुछ परिचालन की दृष्टि से अजीब हैं। Lovable एक बार में केवल एक शाखा को संपादित और सिंक करता है। Git sync हमेशा एक नई रिपॉज़िटरी प्रदान करता है और किसी मौजूदा को किसी प्रोजेक्ट से संलग्न नहीं कर सकता, और डिस्कनेक्ट के बाद पुनः कनेक्ट करने से एक और नई रिपॉज़िटरी बन जाती है। रिपॉज़िटरी डिफ़ॉल्ट रूप से निजी है। इसे हटाने से सिंक रुक जाता है।

कोड तब बंद नहीं होता। यह उपयोगी है, लेकिन पूरा माइग्रेशन नहीं है। अपनी रिपॉज़िटरी में स्रोत संग्रहीत करना Lovable पर रनटाइम निर्भरता को समाप्त नहीं करता। मौजूदा-ऐप तालिका के लिए उस अंतर को ध्यान में रखें।

होस्ट चुनने से पहले फ्रेमवर्क की जांच करें

Lovable के documentation में बताया गया है कि 13 मई, 2026 के बाद बनाए गए नए ऐप्स TanStack Start का इस्तेमाल करते हैं, जो server code को चलाता है। पुराने ऐप्स अलग होते हैं। वे React plus Vite पर निर्भर करते हैं और static files में build होते हैं। Supabase integration docs Enterprise plans के लिए 22 जून, 2026 दिखाते हैं एक संबंधित सुविधा के लिए, आपके अपने Supabase project के साथ built-in payments, इसलिए हर account के लिए एक blanket creation-date rule apply न करें।

अपने actual project की inspect करें। Code tab में package.json खोलें। एक TanStack Start project अपने dependencies में @tanstack/react-start list करता है। एक पुराना React और Vite project ऐसा नहीं करता।

hosting के नतीजे अलग होते हैं:

• TanStack Start: host को server part चलाना चाहिए: server-side rendering, server functions और API routes। एक host जो सिर्फ static files लेता है वह उन features को नहीं चलाता। Object storage या एक CDN अकेला काफी नहीं है। Lovable एक ऐसे platform की ओर इशारा करता है जिसे Nitro detect करता है, एक container या आपका अपना server। यह भी check करें कि package.json में nitro list है, क्योंकि बिना इसके build ऐप को Lovable के बाहर किसी host के लिए package नहीं करता।
• पुराना React और Vite: static output को dist/ से एक static host, CDN या एक web server जैसे Nginx में deploy करें, index.html को fallback के साथ ताकि client-side routes काम करें।

एक और trap: VITE_ से शुरू होने वाले variables build time पर baked होते हैं, runtime पर नहीं पढ़े जाते। यह teams को पकड़ता है। built-in backend का इस्तेमाल करते समय, Lovable आपको VITE_SUPABASE_URL और VITE_SUPABASE_PUBLISHABLE_KEY को npm run build चलाने से पहले set करने के लिए कहता है।

मैंने यहां provider-by-provider deployment recipes को छोड़ दिया है। यह जानबूझकर scope control है। Lovable की guide मौजूदा steps को detail में बताती है, और एक server-rendered project के लिए यह checks prescribe करती है जैसे एक server-rendered page load करना और traffic switch करने से पहले एक server function को execute करना।

मौजूदा ऐप: चार paths, compared

उस तालिका में दो चीजें गलत हो जाना आसान है।

पहली बात, बैकएंड को माइग्रेट करना कोई टॉगल स्विच नहीं है। Lovable कहता है कि वह किसी प्रोजेक्ट को बिल्ट-इन बैकएंड से Supabase में एक ही कदम में ट्रांसफर नहीं कर सकता, न ही प्रक्रिया को रिवर्स कर सकता है। दस्तावेज़ित रास्ता अधिक मैनुअल है। इसके लिए स्कीमा को फिर से बनाना और डेटा को हाथ से स्थानांतरित करना पड़ता है: सक्रिय बैकएंड से एक्सपोर्ट करें, नया बैकएंड कनेक्ट करें, और Lovable को स्कीमा फिर से बनाने के लिए कहें।

दूसरी बात, समर्थित लक्ष्य मैनेज्ड Supabase और सेल्फ-होस्टेड Supabase हैं। केवल PostgreSQL डेटाबेस को स्थानांतरित करना बहुत कुछ छोड़ देता है: ऑथेंटिकेशन, स्टोरेज, रीयलटाइम फीचर्स और Edge Functions। सादे PostgreSQL या किसी अन्य प्रोवाइडर पर जाने के लिए आपको इन समकक्षों को स्वयं बनाना होगा, एक रास्ता जो Lovable समर्थन नहीं करता है। यह असली इंजीनियरिंग कार्य है, कोई सीधा माइग्रेशन नहीं। यदि आप इस रास्ते पर जाते हैं, तो सर्वरलेस डेटाबेस अवलोकन लक्ष्यों की तुलना करने के लिए एक समझदारी भरी जगह है।

बिल्ट-इन बैकएंड छोड़ना नेटिव टूलिंग भी हटा देता है। आप एडिटर में डेटाबेस, यूजर्स, स्टोरेज, सीक्रेट्स, जॉब्स और लॉग्स व्यू खो देते हैं, रोज़मर्रा के बैकअप और क्लिक-टू-रिस्टोर रिस्टोरेशन, और Lovable-कॉन्फ़िगर्ड ऑथ जैसे मैनेज्ड Google साइन-इन। अपना स्वयं का Supabase प्रोजेक्ट चलाने के लिए अपनी स्वयं की Supabase सदस्यता और सीधे इंफ्रास्ट्रक्चर प्रबंधन की आवश्यकता है।

और स्रोतों में कुछ नहीं कहता कि कोई अन्य बिल्डर एक पूर्ण Lovable बैकएंड आयात करता है। यह मान लें कि नहीं होगा।

प्रोडक्शन स्वीकृति चेकलिस्ट

एक इन्वेंटरी से शुरू करें। असली प्रोजेक्ट के लिए, सूची बनाएं:

• डेटा और स्कीमा (माइग्रेशन फाइलें supabase/migrations/ के तहत रहती हैं)
• ऑथ यूजर्स और प्रोवाइडर्स
• स्टोरेज फाइलें और एक्सेस पॉलिसीज़
• रीयलटाइम सदस्यताएं
• Edge Functions या server functions
• Secrets
• Scheduled jobs और webhooks
• AI access और app connectors

फिर इसे क्रम में काम करें:

1. Repository को clone करें और actual code को locally run करें। इससे पता चलता है कि यह क्या install करता है, किस पर depend करता है और environment से क्या पढ़ता है।
2. Framework और runtime को identify करें (ऊपर package.json check देखें)।
3. Data export को staging project में restore करें, production में नहीं।
4. Storage files को More → Storage से download करें और उन्हें staging storage में load करें।
5. Signup, login और OAuth redirects को test करें, और account continuity को check करें। Lovable के database export docs कहते हैं कि Supabase project में restore करने से users के passwords रहते हैं, और जो लोग switch के समय signed in हैं उन्हें फिर से sign in करना पड़ता है। Assume न करें; इसे validate करें, और Supabase की current user-migration guidance को follow करें। authentication page भी देखें।
6. Real accounts के साथ different roles में file access और permissions को test करें।
7. Row Level Security को check करें। हर table के policies होने चाहिए जो restrict करते हैं कि कौन हर row को read और write कर सकता है, और Lovable कहता है कि उन्हें Supabase dashboard में खुद verify करें।
8. एक critical paid या state-changing flow को test mode में run करें, कभी real customers को charge न करें।
9. Record counts को compare करें, और storage से representative files को open करें।
10. Logs, backups, recovery और rollback path को verify करें।
11. जो कुछ भी Lovable के through चला: AI access, connectors, scheduled jobs को replace करें।
12. उसके बाद ही original services को remove करें।

Step 12 को एक warning की जरूरत है। इसे seriously लें। Lovable database को drop करने से आपका export और आपकी files दोनों delete हो जाती हैं, तो पहले उन्हें download करके inspect करें। Credentials को tickets, chats या repository में कभी न paste करें जबकि इसे handle कर रहे हैं।

एक और trap: अगर दो Lovable projects एक ही Supabase project share करते हैं, तो वे एक दूसरे के secrets को overwrite करते हैं, जिसमें LOVABLE_API_KEY भी है, जो इस पर depend करने वाले किसी भी feature को break कर देता है।

Stay put करें, hybrid जाएं, या leave करें

ज्यादातर real decisions बीच में land करते हैं।

• एक different deploy pipeline की requirement के लिए शायद सिर्फ एक frontend move की जरूरत हो।
• अपने own account में एक database की जरूरत के लिए backend migration की जरूरत हो सकती है, और कुछ नहीं और।
• Authoring experience से unhappiness का मतलब शायद सिर्फ exported repository में अपने own editor के साथ काम करना हो, जबकि Lovable Git sync के through connected रहे।

एक maintenance owner को assign करें और किसी भी service को cancel करने से पहले हर remaining runtime dependency को map करें। Document को concise रखें। इसे कहना चाहिए कि कौन deploy करता है, कौन backup को restore करता है, कौन secrets को rotate करता है, और कौन से features अभी भी Lovable को call करते हैं। अगर आप एक owner का नाम नहीं रख सकते, तो अभी के लिए जहाँ हैं वहीं रहें।

अगर आप उस हैंडओवर पर दूसरी राय चाहते हैं, तो रिपॉज़िटरी, डिप्लॉयमेंट मैप और वह यूज़र फ़्लो, जिस पर इंजीनियरिंग की निगरानी चाहिए, एजेंटिक इंजीनियरिंग टीम को भेजें, ताकि वह स्वामित्व की सीमाओं और बचे हुए काम का आकलन कर सके। अपनी माँग स्पष्ट रखें। यह एक आकलन है, एक बटन दबाते ही समाधान की गारंटी नहीं।

FAQ

क्या मैं Lovable editor और agent को self-host कर सकता हूँ?

नहीं। Lovable कहता है कि editor और AI agent एक managed service हैं और उन्हें self-host या customer VPC के अंदर deploy नहीं किया जा सकता। हालाँकि, आप जो applications उनके साथ बनाते हैं, उन्हें कहीं भी होस्ट किया जा सकता है।

क्या किसी दूसरे builder में स्विच करने से मेरा backend साथ चला आता है?

स्रोतों में कुछ भी यह नहीं बताता कि ऐसा होता है। अलग से काम करने की योजना बनाएँ। अपना डेटा और फाइलें export करें, codebase को Git या download के जरिए transfer करें, और destination पर authentication, secrets और supporting services को फिर से configure करें।

क्या अगर मैं free plan पर हूँ तो .zip download काफी है?

Lovable की direct codebase .zip download paid plans पर उपलब्ध है। Git sync अलग है। चूँकि Git sync सभी tiers पर उपलब्ध है, पहले उस रास्ते को test करें।

मुख्य सावधानी स्पष्ट है: exported code आपका है, लेकिन database records, storage files, auth configuration, और Lovable-managed AI और connectors को अलग से migrate करना पड़ता है, जो कुछ भी automatically नहीं होता। cut over करने से पहले inventory कर लें। अपनी package.json check करें, हर dependency की inventory करें, और कुछ भी cancel करने से पहले migration को staging में test करें।