मैनुअल: डिप्लॉय टारगेट और आपका अपना डोमेन

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

टारगेट बनाने के लिए मुझे क्या चाहिए?

पांच चीज़ें, सेटिंग्स → डिप्लॉय में:

1. एक नाम जो आप बाद में पहचान लेंगे — "prod-vps", "client-hostgator", जो भी रात 11 बजे ड्रॉपडाउन में बचा रहे
2. होस्ट और पोर्ट
3. SFTP क्रेडेंशियल्स
4. एक वेबरूट पाथ

न कोई API टोकन, न सर्वर पर इंस्टॉल करने के लिए कोई CLI, न कोई क्रॉन जॉब जिसे संभालना पड़े। अगर आपका होस्ट SFTP एक्सेस देता है — जो लगभग हर शेयर्ड होस्ट, हर VPS, हर मैनेज्ड वर्डप्रेस बॉक्स को कवर करता है — तो आप लगभग दो मिनट में तैयार हैं।

पासवर्ड या की?

की, अगर आपका होस्ट इसे सपोर्ट करता है। पासवर्ड ठीक काम करते हैं और हम उन्हें आपके खाते तक सीमित करके स्टोर करते हैं, लेकिन एक की का मतलब है एक कम सीक्रेट जो कहीं भी बैठा हो — बाद में कुछ गलत होने पर "एक की रद्द करना" और "हर जगह पासवर्ड रीसेट करना जहां वह पासवर्ड दोबारा इस्तेमाल हुआ हो" के बीच का अंतर। बहुत सारे सस्ते शेयर्ड-होस्टिंग SFTP सेटअप केवल पासवर्ड ऑथ ही देते हैं, और यह भी ठीक है। बस उस पासवर्ड को कहीं और दोबारा इस्तेमाल न करें।

मुझे सही वेबरूट पाथ कैसे मिलेगा?

यह वह फ़ील्ड है जिसे लोग पहली बार गलत समझते हैं, क्योंकि गलत जवाब भी सही दिख सकता है। यह आपकी होम डायरेक्टरी नहीं है, यह /var/www — यह वह सटीक फोल्डर है जिससे आपका वेब सर्वर सर्व करने के लिए कॉन्फ़िगर किया गया है।

अगर आप निश्चित नहीं हैं, तो किसी भी SFTP क्लाइंट का इस्तेमाल करके एक test.txt उस फोल्डर में डालें जो आपको सही लगता है, फिर देखें कि क्या वह यहाँ लोड होता है yoursite.com/test.txt। इसे गलत करने पर भी डिप्लॉय सफलता की रिपोर्ट देगा — एजेंट भरोसे से फाइलें गलत फोल्डर में लिख देता है, और आप एक लाइव साइट को घूरते रह जाते हैं जो बदली ही नहीं, और सोचते रहते हैं कि आखिर क्यों।

क्या एक टारगेट एक से ज़्यादा डोमेन को कवर कर सकता है?

हां, और यही वह हिस्सा है जो आपकी पहली साइट के बाद असली समय बचाता है। एक टारगेट एक सर्वर और एक क्रेडेंशियल सेट है — यह किसी एक डोमेन से बंधा नहीं है। डोमेन मैनेजमेंट में आप हर डोमेन को एक टारगेट से उसके अपने वेबरूट ओवरराइड के साथ जोड़ते हैं। एक VPS पर Nginx सर्वर ब्लॉक्स के साथ तीन साइट्स चलाएं?

• site-a → /var/www/site-a
• site-b → /var/www/site-b
• site-c → /var/www/site-c

एक टारगेट, तीन अटैचमेंट। आप एक SSH पासवर्ड तीन बार दोबारा नहीं डाल रहे, और आप तीन लगभग-एक जैसे टारगेट को बनाए नहीं रख रहे जो उस दिन बिखर जाएं जब आप एक की घुमाएं और उनमें से एक भूल जाएं। तीनों डोमेन में से किसी पर भी डिप्लॉय क्लिक करें और यह पहले से जानता है कि कौन सा सर्वर और कौन सा फोल्डर — आप डिप्लॉय के समय कभी नहीं चुनते।

कनेक्ट होने पर एजेंट असल में क्या करता है?

पहले, यह चारों ओर देखता है — रीड-ओनली, अभी कुछ नहीं लिखा जाता। यह निरीक्षण जांचता है:

• एक खाली फोल्डर
• इसी बिल्ड का एक पिछला वर्ज़न
• एक पुराना वर्डप्रेस इंस्टॉल
• एक "जल्द आ रहा है" प्लेसहोल्डर जो आपके होस्ट ने डिफ़ॉल्ट रूप से वहां छोड़ा हो

यह रणनीति तय करता है। एक खाली वेबरूट को सीधा अपलोड मिलता है। किसी चीज़ से पहले से भरे वेबरूट को ज़्यादा सावधानी से संभाला जाता है, क्योंकि बहुत सारे असली सेटअप में साइट के साथ ऐसी चीज़ें रहती हैं जिन्हें गायब नहीं होना चाहिए:

• A .well-known SSL वैलिडेशन के लिए फोल्डर
• एक uploads डायरेक्टरी जिसे किसी ने git में नहीं डाला
• A wp-config.php जिसे कोई छूना नहीं चाहता

यहां का काम "मिटाओ और बदलो" से ज़्यादा "जो बदला है उसे पता लगाओ और उसका मेल बिठाओ" के करीब है।

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

क्या यह मेरा सोर्स कोड अपलोड करता है या बना हुआ साइट?

हमेशा बना हुआ (built) साइट। स्टैटिक साइट के लिए यह जनरेट की गई पेजें हैं। फ्रेमवर्क बिल्ड के लिए — Next.js, Vite, जो भी साइट टाइप की ज़रूरत हो — यह कंपाइल किया गया आउटपुट है, वह dist या build फोल्डर, सोर्स ट्री कभी नहीं। मुझे लगता है यह सही फैसला है, भले ही इसका मतलब यह हो कि आप SSH में जाकर सर्वर पर मौजूद चीज़ के खिलाफ़ npm run dev नहीं चला सकते। सोर्स अपलोड करने का मतलब होगा कि आपके प्रोडक्शन वेबरूट को सिर्फ़ HTML सर्व करने के लिए Node रनटाइम और एक बिल्ड टूलचेन चाहिए होगी — एक शेयर्ड-होस्टिंग बॉक्स को, जो कभी बिल्ड पाइपलाइन चलाने के लिए बना ही नहीं था, वैसा बना देना, और हर डिप्लॉय को "उम्मीद करना कि सर्वर के पास खत्म करने लायक पर्याप्त मेमोरी है npm install" बना देना। सिर्फ़ कंपाइल किया आउटपुट भेजना वेबरूट को बिल्कुल वैसा रखता है जैसा एक स्टैटिक फाइल सर्वर उम्मीद करता है। उबाऊ। और उबाऊ ही वह चीज़ है जो आप रात के 2 बजे चाहते हैं जब कुछ गड़बड़ हो और आप उस फोल्डर को घूरकर यह समझने की कोशिश कर रहे हों कि असल में सर्व क्या हो रहा है।

मुझे कैसे पता चलेगा कि डिप्लॉय असल में सफल हुआ?

अपलोड के बाद, एजेंट लाइव URL पर जाकर चेक करता है कि वह रिज़ॉल्व होता है या नहीं — कोई 500 नहीं, कोई खाली पेज नहीं। जो भी इसे मिलता है, साथ ही निरीक्षण के दौरान जो कुछ भी इसने नोटिस किया और जिस पर आपकी राय चाहिए ("इस वेबरूट में एक wp-content फोल्डर है जिसे मैंने छुआ नहीं है, पुष्टि करें कि यह अपेक्षित है"), वह बिल्ड की चैट थ्रेड में आ जाता है। यही इस पूरे प्लेटफ़ॉर्म का पैटर्न है: न कोई खामोश सफलता, न कोई खामोश विफलता जो सपोर्ट टिकट बन जाए। एजेंट आपको बताता है कि उसने क्या देखा और क्या तय किया, उसी थ्रेड में जहाँ आपने बिल्ड माँगा था।

वर्ज़न हिस्ट्री में असल में क्या है?

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

रिवर्ट असल में क्या रिस्टोर करता है?

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

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

एक क्लिक, पिछला वर्शन रीस्टोर, बस। इसे बाद की सोच के बजाय एक फर्स्ट-क्लास फीचर मानने के पीछे की वजह Iterating without fear में है — इसे एक बार पढ़ना ज़रूरी है, ज़रूरत पड़ने से पहले। हिस्ट्री और रीस्टोर कंट्रोल दोनों बिल्ड कार्ड पर और टारगेट के अपने हिस्ट्री व्यू में मिलते हैं।

क्या यह मेरे डेटाबेस का भी बैकअप लेता है?

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