Replit ऐप प्रीव्यू में चलता है लेकिन पब्लिश करने के बाद टूट जाता है? फ़ाउंडर्स के लिए चेकलिस्ट

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

कोई ऐप Replit प्रीव्यू में क्यों चल सकता है और लाइव में फ़ेल क्यों हो सकता है?

Replit प्रीव्यू और पब्लिश किया गया ऐप अलग-अलग एनवायरनमेंट हैं। लाइव ऐप का URL, कॉन्फ़िगरेशन, डेटा और रनटाइम व्यवहार उस प्रोजेक्ट से अलग हो सकता है जिसे आप एडिट कर रहे हैं।

Replit की पब्लिशिंग गाइड बताती है कि पब्लिश करने से एक प्रोडक्शन डिप्लॉयमेंट बनता है और बाद में की गई एडिटिंग उसे तब तक नहीं बदलती जब तक आप दोबारा पब्लिश न करें। पहले पुष्टि करें कि आप सही रिलीज़ टेस्ट कर रहे हैं। पब्लिक URL, आख़िरी पब्लिश का समय, फ़ेल होने वाली कार्रवाई, और क्या यह समस्या नए ब्राउज़र सेशन में भी आती है, यह सब नोट करें।

पाँच असंबंधित स्क्रीनशॉट इकट्ठा करके Agent से पूरा ऐप ठीक करने को न कहें। एक विफलता चुनें: उदाहरण के लिए, किसी नए ग्राहक को Save चुनने के बाद एरर मिलता है। अपेक्षित नतीजा, असली नतीजा और समय नोट करें। इससे आपके पास पब्लिश किए गए ऐप्लिकेशन के लॉग से तुलना करने के लिए कुछ ठोस होगा।

क्या ऐप सही डिप्लॉयमेंट टाइप इस्तेमाल कर रहा है?

डिप्लॉयमेंट को उस तरह के प्रोग्राम को सपोर्ट करना चाहिए जो आपका ऐप चलाता है। स्टैटिक फ़ाइलों के सेट और एक फ़ुल-स्टैक ऐप्लिकेशन की होस्टिंग ज़रूरतें अलग होती हैं।

अक्टूबर 2026 तक, Replit का डिप्लॉयमेंट टाइप्स डॉक्यूमेंटेशन Autoscale, Static, Reserved VM और Scheduled डिप्लॉयमेंट में अंतर करता है। Publishing settings में डिप्लॉयमेंट टाइप जाँचें और उसकी तुलना ऐप्लिकेशन की असली ज़रूरतों से करें।

वही डॉक्यूमेंटेशन कहता है कि Static, Replit Agent से बनाए गए ऐप्स के साथ संगत नहीं है क्योंकि उन ऐप्स को बैकएंड चाहिए। अगर ऐप्लिकेशन को कस्टमाइज़ किया गया है, तो किसी डेवलपर से बिल्ड और रन कमांड की पुष्टि करवाएँ। बड़ी मशीन ख़रीदने से कोई ग़ायब सर्वर रूट या ग़लत स्टार्टअप कमांड ठीक नहीं होगी।

क्या ज़रूरी प्रोडक्शन सीक्रेट्स सच में उपलब्ध हैं?

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

Replit की Secrets गाइड आपको Publishing → Adjust settings → Production app secrets पर जाने को कहती है। यह संवेदनशील सीक्रेट्स और गैर-संवेदनशील कॉन्फ़िगरेशन वैल्यूज़ में भी अंतर करती है। वहाँ ज़रूरी एंट्रीज़ की समीक्षा करें, लेकिन उनकी वैल्यूज़ किसी ट्रबलशूटिंग प्रॉम्प्ट में कॉपी न करें।

1. ज़रूरी वेरिएबल नामों की सूची माँगें, हर एक कहाँ पढ़ा जाता है, और क्या वह बिल्ड टाइम पर इस्तेमाल होता है या रनटाइम पर।
2. जाँचें कि प्रोडक्शन एंट्रीज़ उन नामों से बिल्कुल मेल खाती हैं और सही प्रोवाइडर अकाउंट्स की हैं।
3. सर्वर क्रेडेंशियल्स को सर्वर पर ही रखें; फ़्रंटएंड वेरिएबल या ब्राउज़र बंडल सीक्रेट रखने की जगह नहीं है।
4. जब प्लेटफ़ॉर्म या बिल्ड प्रोसेस के लिए ज़रूरी हो तो दोबारा पब्लिश करें, फिर पब्लिक URL पर मूल कार्रवाई दोहराएँ।

क्या पब्लिश किया गया ऐप सही डेटाबेस पढ़ रहा है?

ग़ायब प्रोडक्शन रिकॉर्ड्स को टूटा हुआ इंटरफ़ेस मानने से पहले लाइव डेटाबेस पहचानें। डेवलपमेंट में दिखने वाला सैंपल डेटा ज़रूरी नहीं कि वही डेटा हो जिसे आपके ग्राहकों का ऐप पढ़ता है।

Replit की डेवलपमेंट और प्रोडक्शन डेटाबेस गाइड अलग-अलग एनवायरनमेंट और मौजूदा व पुराने (legacy) इंफ़्रास्ट्रक्चर के लिए अलग सेटअप तरीक़ों का वर्णन करती है। Database टूल में प्रोडक्शन सिलेक्शन और आपके ऐप पर लागू पब्लिशिंग सेटिंग्स जाँचें। यह न मानें कि किसी दूसरी प्रोजेक्ट पीढ़ी का ट्यूटोरियल आपके प्रोजेक्ट पर भी लागू होता है।

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

फ़ेल हुए write के लिए ऑपरेशन और सैनिटाइज़्ड एरर इकट्ठा करें। किसी डेवलपर से कहें कि वह कनेक्शन फ़ेल्योर को ग़ायब टेबल, कंस्ट्रेंट या ऑथराइज़ेशन समस्या से अलग करे। कनेक्शन स्ट्रिंग बार-बार बदलने से मूल समस्या छिप सकती है और डेवलपमेंट का काम ग़लती से ग़लत डेटा की ओर इशारा करने लग सकता है।

क्या फ़ाइलें और बाहरी कॉलबैक पब्लिक डोमेन पर काम करते हैं?

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

अपलोड के लिए, Replit App Storage स्थायी ऑब्जेक्ट स्टोरेज देता है। यह मानने के बजाय कि रनटाइम फ़ोल्डर में लिखी गई फ़ाइलों में आपके प्रोडक्ट के लिए ज़रूरी स्थायित्व और एक्सेस कंट्रोल हैं, मौजूदा इम्प्लीमेंटेशन जाँचें। एक नियंत्रित रिलीज़ के बाद फ़ाइल अपलोड करना, वापस पाना और उस पर पाबंदी लगाना टेस्ट करें।

लॉगिन प्रोवाइडर्स, पेमेंट वेबहुक्स और ईमेल लिंक्स के लिए, संबंधित प्रोवाइडर के साथ अनुमत origins, रजिस्टर्ड endpoints और return URLs की समीक्षा करें। जहाँ ज़रूरी हो, उन्हें इच्छित पब्लिश किए गए डोमेन की ओर इशारा करना चाहिए। पूरा राउंड ट्रिप टेस्ट करें: आपके ऐप से बाहर जाना, प्रोवाइडर पर कार्रवाई पूरी करना, और किसी उपयोगी स्क्रीन पर वापस आना।

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

लाइव फ़िक्स की पुष्टि कैसे करें?

पब्लिक URL पर मूल कार्रवाई दोहराएँ, फिर उससे मेल खाने वाले प्रोडक्शन सबूत जाँचें। सफल पब्लिश का मतलब है कि रिलीज़ पूरी हो गई; यह साबित नहीं करता कि ग्राहक का हर वर्कफ़्लो सफल रहा।

Replit की Monitoring गाइड रिक्वेस्ट स्टेटस, रिस्पॉन्स अवधि, रिसोर्स उपयोग और ऐप्लिकेशन लॉग समझाती है। जाँच को सीमित करने के लिए फ़ेल होने वाली कार्रवाई के टाइमस्टैम्प का इस्तेमाल करें। ज़्यादा रिसोर्स उपयोग और ऐप्लिकेशन एरर अलग-अलग निष्कर्ष हैं, इसलिए क्षमता बदलने से पहले निदान करें।

1. पब्लिश किए गए डोमेन पर एक नए अकाउंट से ठीक वही फ़ेल होने वाली जर्नी दोहराएँ।
2. पेज रिफ़्रेश करने के बाद पुष्टि करें कि इच्छित रिकॉर्ड या इंटीग्रेशन का नतीजा मौजूद है।
3. मेल खाने वाली सर्वर रिक्वेस्ट या लॉग जाँचें, फिर किसी आस-पास के फ़ेल्योर केस को सुरक्षित तरीक़े से टेस्ट करें।
4. मुख्य जर्नी फ़ोन पर दोहराएँ और पुष्टि करें कि पहले से काम करने वाला व्यवहार अब भी काम करता है।

अगर डिप्लॉयमेंट को अब भी डेवलपमेंट काम की ज़रूरत हो तो?

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

अपने दर्शकों का दायरा बढ़ाने से पहले व्यापक AI MVP प्रोडक्शन चेकलिस्ट इस्तेमाल करें, या अगर बार-बार के प्रॉम्प्ट रिग्रेशन पैदा कर रहे हैं तो फ़िक्स-लूप गाइड देखें। अगले वर्ज़न की समीक्षा और शिपिंग में मदद के लिए, अपने Replit ऐप के बारे में कॉल बुक करें। हम मिलकर तय कर सकते हैं कि आपको कॉन्फ़िगरेशन फ़िक्स, किसी केंद्रित कोड बदलाव, या बड़े रिलीज़ प्लान की ज़रूरत है।