अक्सर पूछे जाने वाले प्रश्न

अक्सर पूछे जाने वाले प्रश्न

सेवा सेटअप, एक्सेस और सामान्य ग्राहक कार्यों के लिए व्यावहारिक, संक्षिप्त गाइड।

> Cli>_ क्रेडिट सिस्टम कैसे काम करता है?

एक साझा प्रीपेड बैलेंस सभी पात्र सेवाओं का भुगतान करता है और केवल उनके सक्रिय रहने पर खर्च होता है।
faq/prepaid-credit-how-it-works

आपके Cli>_ खाते में एक साझा प्रीपेड क्रेडिट बैलेंस होता है। पात्र नए ग्राहक आवश्यक खाता और दुरुपयोग-रोधी सत्यापन पूरा करने के बाद ही Starter Credit का दावा कर सकते हैं। सक्रिय पात्र सेवाएँ समय के साथ इस बैलेंस को खर्च करती हैं। मासिक अनुमान 31 दिनों पर आधारित है और नई सेवा तभी शुरू होती है जब बैलेंस कम से कम 7 दिनों को कवर करे। अनुमानित समय 7 दिनों से कम होने पर लाल चेतावनी दिखाई जाती है; अन्यथा 14 दिनों से कम होने पर नारंगी चेतावनी दिखाई जाती है।

बैलेंस खत्म होने के 7 दिन बाद सेवा निलंबित हो जाती है, क्रेडिट खर्च करना बंद कर देती है और 7 दिनों की संरक्षण और हटाने की उलटी गिनती शुरू होती है। दिखाए गए समय से पहले पर्याप्त क्रेडिट के साथ उसे दोबारा शुरू किया जा सकता है। provision की गई सेवा रद्द करने पर भी वह निलंबित होती है और यही उलटी गिनती शुरू होती है। लंबित और अभी provision न हुई सेवा तुरंत निष्क्रिय हो सकती है। समय के बाद provision की गई सेवा को निष्क्रिय करने और हटाने की प्रक्रिया शुरू होती है। Force delete सेवा को तुरंत निष्क्रिय करता है, संरक्षण छोड़ता है और सक्रिय runtime से हटाना शुरू करता है; पूरा होना deployment और GitOps processing के बाद होता है। बैकअप और Offsite Archive की अलग संरक्षण नीतियाँ हैं।

9.90 EUR वाले OpenCode का उदाहरण: 9.90 / 31 ≈ 0.319 EUR प्रतिदिन। पूरे 10 दिनों बाद लगभग 3.19 EUR खर्च होते हैं। यदि शुरुआती बैलेंस ठीक 9.90 EUR था और कोई अन्य सेवा नहीं थी, तो लगभग 6.71 EUR बचते हैं। सेवा अक्षम होने के बाद खर्च रुक जाता है।

यह केवल उदाहरण है। Cli>_ में वर्तमान में दिखाई गई कीमतें ही हमेशा लागू होती हैं।

> कमांड लाइन के माध्यम से सार्वजनिक एसएसएच कुंजी कैसे जेनरेट करें

सुरक्षित वीपीएस एक्सेस के लिए एक सार्वजनिक SSH कुंजी बनाएं। केवल सार्वजनिक कुंजी को Cli>_ के साथ साझा करें; निजी कुंजी को अपने डिवाइस पर रखें।
faq/generate-public-ssh-key-hi

केवल सार्वजनिक कुंजी साझा की जाती है, निजी कुंजी आपके पास ही रहती है

कृपया ऑर्डर या सेवा सेटअप में केवल सार्वजनिक SSH कुंजी डालें। निजी कुंजी आपके कंप्यूटर पर सुरक्षित रहती है और इसे समर्थन टीम को नहीं भेजा जाता है, न ही इसे किसी वेब फॉर्म में डाला जाता है।

प्रक्रिया

  1. अपने कंप्यूटर पर एक टर्मिनल खोलें।
  2. यह कमांड चलाएं: ssh-keygen -t ed25519 -C "your-email@example.com"।
  3. फ़ाइल को डिफ़ॉल्ट स्थान पर सहेजें या अपना कस्टम पथ चुनें। अपनी निजी कुंजी कभी भी किसी को न भेजें।
  4. सार्वजनिक कुंजी प्रदर्शित करने के लिए, निम्न कमांड का उपयोग करें: `cat ~/.ssh/id_ed25519.pub`।
  5. पूरी लाइन को कॉपी करें जो 'ssh-ed25519' से शुरू होती है और इसे ऑर्डर करते समय या सेवा सेट करते समय 'SSH सार्वजनिक कुंजी' फ़ील्ड में पेस्ट करें।
  6. पूरी ssh-ed25519 लाइन SSH public key फील्ड में कॉपी करें।

विंडोज 10/11 पॉवरशेल

  1. PowerShell या विंडोज टर्मिनल खोलें।
  2. कमांड चलाएँ: ssh-keygen -t ed25519 -C "आपका-ईमेल@example.com"।
  3. कुंजी को C:\Users\आपका-उपयोगकर्ता\.ssh\id_ed25519 में सहेजने के लिए एंटर दबाएं, या अपना कस्टम पथ दर्ज करें।
  4. यदि विंडोज एक पासफ़्रेज़ मांगता है, तो ऐसा पासफ़्रेज़ चुनें जिसे आप सुरक्षित रूप से संग्रहीत कर सकें, या सरल सेटअप के लिए एंटर दबाकर इसे छोड़ दें।
  5. सार्वजनिक कुंजी प्रदर्शित करने के लिए, निम्न कमांड का उपयोग करें: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub।
  6. केवल 'ssh-ed25519' से शुरू होने वाली पूरी पंक्ति को कॉपी करें। निजी कुंजी फ़ाइल को कॉपी या अपलोड न करें।
> विंडोज में ग्राफिकल तरीके से एसएसएच कुंजी कैसे बनाएं

विंडोज में कमांड लाइन का उपयोग किए बिना एक ग्राफिकल टूल के माध्यम से SSH कुंजी जोड़ी बनाने की प्रक्रिया।
faq/create-ssh-key-windows-gui-hi

विंडोज टूल का उपयोग करें और केवल सार्वजनिक कुंजी पेस्ट करें

आप PuTTYgen जैसे विंडोज SSH क्लाइंट के साथ ग्राफिक रूप से एक SSH कुंजी जोड़ी बना सकते हैं। Cli>_ को केवल सार्वजनिक कुंजी की आवश्यकता होती है। निजी कुंजी फ़ाइल को अपने कंप्यूटर पर रखें और इसे वेब फॉर्म में अपलोड न करें।

प्रक्रिया

  1. PuTTY स्थापित करें या यदि यह पहले से स्थापित है, तो PuTTYgen खोलें।
  2. यदि उपलब्ध हो, तो EdDSA/Ed25519 चुनें, अन्यथा RSA 4096 चुनें।
  3. 'Generate' पर क्लिक करें और कुंजी उत्पन्न होने तक खाली क्षेत्र में माउस घुमाएं।
  4. यदि आप निजी कुंजी के लिए अतिरिक्त स्थानीय सुरक्षा चाहते हैं, तो एक पासफ़्रेज़ जोड़ें।
  5. निजी कुंजी को अपने डिवाइस पर सहेजें और इसे गोपनीय रखें।
  6. सार्वजनिक कुंजी टेक्स्ट की प्रतिलिपि बनाएं और इसे Cli>_ में SSH सार्वजनिक कुंजी फ़ील्ड में पेस्ट करें।

कोई भी गोपनीय जानकारी साझा न करें

कृपया .ppk फ़ाइलें, निजी कुंजियाँ, passphrase, पासवर्ड या टोकन को सपोर्ट टीम को या किसी भी फॉर्म में न भेजें।

> अपना डोमेन जोड़ें

यह जानें कि अपने डोमेन या सबडोमेन को 'ब्रिंग योर ओन डोमेन' (Bring Your Own Domain) को सक्रिय करने से पहले CLIopen सेवा पर कैसे निर्देशित करें।
faq/apna-domain-joden

यह सेटिंग क्या करती है

'अपना डोमेन लाएं' सुविधा आपके सेवा को आपके व्यक्तिगत होस्टनाम पर प्रतिक्रिया देने की अनुमति देती है, उदाहरण के लिए app.example.com, डिफ़ॉल्ट जेनरेट किए गए *.co.cliopen.cloud होस्टनाम के बजाय। आपका DNS पहले CLIopen की ओर इंगित होना चाहिए, ताकि होस्टनाम का उपयोग सुरक्षित रूप से सेवा द्वारा किया जा सके।

शुरू करने से पहले

  1. वह सटीक होस्टनाम चुनें जिसका आप उपयोग करना चाहते हैं, जैसे कि app.example.com। सबडोमेन का उपयोग करना सबसे आसान विकल्प है।
  2. अपने डोमेन रजिस्ट्रार के DNS प्रबंधन कंसोल या अपने DNS प्रदाता के डैशबोर्ड में लॉग इन करें।
  3. CLIopen एंट्री जोड़ने से पहले, उस होस्टनाम के लिए किसी भी conflicting A, AAAA, CNAME, ALIAS या रीडायरेक्ट रिकॉर्ड को हटा दें।
  4. जेनरेट किया गया CLIopen होस्टनाम सक्रिय रखें जब तक कि आपका कस्टम होस्टनाम सत्यापित और पूरी तरह कार्यात्मक न हो जाए।

सबडोमेन के लिए अनुशंसित DNS सेटिंग्स

CLIopen में आप जो सटीक होस्टनाम दर्ज करेंगे, उसके लिए DNS रिकॉर्ड बनाएं। app.example.com के लिए, DNS लेबल app है। इसे CLIopen इनग्रेस पतों पर इंगित करें जो आपको CLIopen सपोर्ट द्वारा या आपके सेवा दस्तावेज़ों में मिलते हैं। यदि आपका प्रदाता एक रिकॉर्ड प्रकार पूछता है, तो IPv4 के लिए A रिकॉर्ड और IPv6 के लिए AAAA रिकॉर्ड का उपयोग करें जब उन पतों को प्रदान किया जाता है।

उदाहरण:

app.example.com.  A     <CLIopen IPv4 पता>
app.example.com.  AAAA  <CLIopen IPv6 पता, यदि उपलब्ध हो>

जब CLIopen एक CNAME लक्ष्य प्रदान करता है

कुछ सेवाओं में, CLIopen आपको एक उत्पन्न होस्टनाम दे सकता है, जैसे कि service.customer.co.cliopen.cloud. यदि आपकी सेवा के निर्देशों में स्पष्ट रूप से CNAME का उपयोग करने की आवश्यकता है, तो app.example.com CNAME service.customer.co.cliopen.cloud जैसा रिकॉर्ड बनाएं। केवल सबडोमेन के लिए ही CNAME का उपयोग करें, न कि शीर्ष/रूट डोमेन के लिए, जब तक कि आपके DNS प्रदाता द्वारा ALIAS या ANAME फ़्लैटनिंग समर्थित न हो।

रूट डोमेन का उपयोग

example.com जैसे बिना सबडोमेन वाले डोमेन के लिए, अधिकांश DNS प्रदाता एक मानक CNAME की अनुमति नहीं देते हैं। CLIopen इनग्रेस पतों की ओर इशारा करते हुए A/AAAA रिकॉर्ड का उपयोग करें, या यदि CLIopen ने आपको एक होस्टनाम लक्ष्य प्रदान किया है तो अपने प्रदाता की ALIAS/ANAME सुविधा का उपयोग करें।

पूरे उप-क्षेत्र का प्रतिनिधिमंडल

यदि आप चाहते हैं कि CLIopen apps.example.com जैसे सब-ज़ोन के अंतर्गत रिकॉर्ड प्रबंधित करे, तो उस सब-ज़ोन के लिए NS रिकॉर्ड बनाएं जो आपको प्राप्त CLIopen नेमसर्वर की ओर इशारा करते हों। पूरे डोमेन के लिए नेमसर्वर को न बदलें जब तक कि आप जानबूझकर CLIopen (या किसी अन्य DNS सेवा) को सभी रिकॉर्ड प्रबंधित करने के लिए नहीं चाहते हैं।

जांच सूची

  1. DNS प्रसार के लिए प्रतीक्षा करें। छोटे बदलाव अक्सर कुछ मिनटों में दिखाई देते हैं, लेकिन कुछ प्रदाता लंबे समय तक कैश करते हैं।
  2. जांचें कि होस्टनाम CLIopen लक्ष्य पर इंगित करता है, न कि पिछले प्रदाता पर।
  3. 'अपना डोमेन लाएं' फ़ील्ड में सटीक होस्टनाम दर्ज करें - `https://` और किसी भी पथ को छोड़ दें।
  4. अपडेट करने के बाद, अपने ब्राउज़र में `https://app.example.com` का परीक्षण करें।
  5. पुराने DNS रिकॉर्ड केवल तभी रखें जब वे नए होस्टनाम से मेल न खाते हों।
> CLIopen में DNS ज़ोन कैसे स्थानांतरित करें

डोमेन को ns1.cliopen.com और ns2.cliopen.com पर डेलिगेट करें ताकि CLIopen पूरे ज़ोन के लिए रिकॉर्ड प्रकाशित कर सके।
faq/dns-zone-pratinidhitva

यहाँ ज़ोन ट्रांसफर का क्या मतलब है

ग्राहक DNS में, 'ट्रांसफर' का अर्थ आपके डोमेन रजिस्ट्रार पर आधिकारिक नेमसर्वर को बदलना होता है। जब आप CLIopen पर डेलिगेशन करते हैं, तो CLIopen DNS में जोड़े गए रिकॉर्ड हमारे आधिकारिक नेमसर्वर द्वारा प्रकाशित किए जाते हैं।

सर्वर नामों को बदलने से पहले

  1. मौजूदा DNS रिकॉर्ड की प्रतियां बनाएं जिन्हें आपको अभी भी आवश्यकता है, जैसे कि वेबसाइट, मेल, सत्यापन, SPF, DKIM, DMARC और सेवा रिकॉर्ड।
  2. CLIopen DNS में एक ज़ोन जोड़ें। यदि प्रतिनिधिमंडल अभी तक तैयार नहीं है, तो CLIopen इसे सहेज लेगा लेकिन ग्राहकों के लिए तब तक सक्रिय नहीं करेगा जब तक कि सत्यापन पास न हो जाए।
  3. यदि संभव हो, तो नेमसर्वर बदलने से पहले आवश्यक रिकॉर्ड को CLIopen DNS में बनाएं।
  4. सुनिश्चित करें कि आप CAA प्रविष्टि को सही ढंग से कॉन्फ़िगर करते हैं, क्योंकि गलत मान प्रमाणपत्र जारी करने में बाधा डाल सकते हैं।

ज़ोन को सौंपें

  1. अपने डोमेन के लिए रजिस्ट्रार की सेटिंग खोलें, उदाहरण के लिए example.com।
  2. नेमसर्वर, डीएनएस डेलीगेशन या ऑथोरिटेटिव डीएनएस सेटिंग्स खोजें।
  3. वर्तमान नेमसर्वरों को ns1.cliopen.com और ns2.cliopen.com के मानों से बदलें।
  4. परिवर्तन सहेजें और रजिस्ट्री तथा रिज़ॉल्वरों में प्रचार होने की प्रतीक्षा करें।

सत्यापन

CLIopen DNS पर वापस जाएँ और 'प्रतिनिधिमंडल की दोबारा जाँच' पर क्लिक करें। जब सार्वजनिक NS रिकॉर्ड ns1.cliopen.com और ns2.cliopen.com प्रदर्शित करते हैं, तो ज़ोन सिंक्रोनाइज़ेशन के लिए कतारबद्ध हो जाता है और रिकॉर्ड CLIopen से सक्रिय हो जाते हैं।

> खाता पंजीकरण और पहली बार लॉग इन

एक ग्राहक खाता बनाएं जो ऑर्डर, बिलिंग विवरण, DNS और सेवा प्रबंधन के लिए हो। एक ऐसा ईमेल पता इस्तेमाल करें जिसे आपकी टीम सुरक्षित रख सके।
faq/account-registration-and-login

ऑर्डर और प्रबंधन के लिए एक ही खाता

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

पहले ऑर्डर से पहले

  1. अपने कार्य ईमेल पते के साथ पंजीकरण करें।
  2. यदि साइट द्वारा अनुरोध किया जाता है, तो ईमेल सत्यापन पूरा करें।
  3. भुगतान किए गए ऑर्डर को भेजने से पहले बिलिंग विवरण भरें।
  4. जब यह उपलब्ध हो, तो अपने खाते के लिए दो-कारक प्रमाणीकरण चालू करें।

टीम के लिए एक्सेस

अपने सहकर्मियों को चैट या ईमेल के माध्यम से पासवर्ड न भेजें। यदि कई लोगों को इसकी आवश्यकता है, तो आंतरिक पासवर्ड मैनेजर का उपयोग करें या अनुशंसित टीम प्रक्रिया का अनुरोध करें; समर्थन को आपके पासवर्ड या लॉगिन टोकन की आवश्यकता नहीं है।

> मासिक अनुमान, वार्षिक अनुमान और वास्तविक दैनिक खपत

मासिक और वार्षिक मूल्य केवल तुलना के लिए दिए गए हैं; प्रीपेड सेवाओं के मामले में, परिवर्तन की पुष्टि होने के बाद दैनिक उपयोग पर आधारित शुल्क लागू होगा।
faq/billing-periods-and-credit-burn

यह तुलना बिलिंग कैलेंडर नहीं है

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

कीमत में बदलाव करते समय क्या जांचना चाहिए

  1. परिवर्तन से पहले और बाद में दैनिक खपत की तुलना करें।
  2. यदि आप CPU, RAM, डिस्क या सशुल्क विकल्पों को बढ़ाते हैं, तो दैनिक उपयोग अधिक हो सकता है।
  3. परिवर्तन तभी प्रभावी होगा जब इसकी पुष्टि हो जाएगी, भुगतान किया जाएगा (यदि आवश्यक हो) और लागू किया जाएगा।
  4. लेखांकन के लिए, ऑर्डर की पुष्टि और क्रेडिट इतिहास को सहेजें।

खर्च कब बदलता है

सहायता टीम को ऑर्डर नंबर, सेवा का नाम और उन तिथियों की जानकारी देने से मदद मिलेगी जिनके लिए आप जांच करवाना चाहते हैं। कृपया बैंक विवरण, संपूर्ण भुगतान विवरण या ऐसी स्क्रीनशॉट न भेजें जिनमें अवांछित व्यक्तिगत जानकारी हो।

> ऑर्डर की स्थिति: भुगतान के बाद

भुगतान के बाद, ऑर्डर को सेवा प्रदाता द्वारा पुष्टि होने में थोड़ा समय लग सकता है। डुप्लिकेट ऑर्डर तभी बनाएँ जब पहला ऑर्डर स्पष्ट रूप से रद्द या समाप्त हो गया हो।
faq/order-status-and-payment-confirmation

'पेंडिंग' का मतलब हमेशा असफलता नहीं होता है

भुगतान पृष्ठ पर वापस आने के बाद, ऑर्डर को भुगतान प्रदाता से पुष्टि होने की प्रतीक्षा करनी पड़ सकती है। जब तक स्थिति स्पष्ट रूप से विफल या समाप्त नहीं हो जाती, तब तक एक नया डुप्लिकेट ऑर्डर अनावश्यक जटिलता पैदा कर सकता है।

भुगतान के बाद क्या करें

  1. भुगतान पूरा होने के बाद, पेमेंट प्रोवाइडर पेज से Cli>_ पर वापस आ जाएं।
  2. अपने खाते में ऑर्डर की स्थिति जांचें।
  3. यदि ऑर्डर अभी भी 'प्रतीक्षा' मोड में है, तो प्रदाता को इसकी पुष्टि करने के लिए थोड़ा समय दें।
  4. यदि कोई समस्या आती है, तो सपोर्ट को ऑर्डर नंबर और भुगतान संदर्भ (यदि उपलब्ध हो) भेजें।

क्या न भेजें

सपोर्ट को क्रेडिट कार्ड की जानकारी, लॉगिन पासवर्ड या पूरे बैंक स्टेटमेंट की आवश्यकता नहीं होती है। केवल ऑर्डर नंबर, भुगतान का समय, दिखाई देने वाली स्थिति और यदि कोई त्रुटि प्रदर्शित हो रही है तो एक स्क्रीनशॉट (संवेदनशील जानकारी छिपाई हुई) पर्याप्त है।

> उन जानकारियों के साथ सेवा सेटअप को तेज़ करें

सेवा का नाम, डोमेन, स्टोरेज का आकार, एक्सेस ईमेल और पब्लिक एसएसएच कुंजी तैयार करें; गोपनीय जानकारी फ़ॉर्म में न डालें।
faq/service-setup-information-needed

सटीक जानकारी समय बचाती है

ऑर्डर फ़ॉर्म का उपयोग सार्वजनिक या गैर-गोपनीय मूल्यों के लिए करें: सेवा नाम, डोमेन, DNS योजना, स्टोरेज आकार, CPU, RAM, एडमिन ईमेल या सार्वजनिक SSH कुंजी। पासवर्ड, निजी कुंजियाँ और टोकन फॉर्म से बाहर होने चाहिए।

ऑर्डर करने से पहले तैयारी करें

  1. अपनी टीम के लिए एक पहचानने योग्य सेवा नाम चुनें।
  2. यह तय करें कि आप अपना डोमेन उपयोग करेंगे या अस्थायी सिस्टम होस्टनाम का उपयोग करेंगे।
  3. यदि सेवा को इसकी आवश्यकता है, तो एक सार्वजनिक SSH कुंजी तैयार करें।
  4. कृपया एप्लिकेशन चलाने के लिए आवश्यक स्टोरेज और संसाधनों की जांच करें।

केवल सार्वजनिक कुंजी दें

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

> ऑर्डर करने के बाद CPU, RAM, डिस्क या रिटेंशन में बदलाव

मौजूदा सेवा को नए डुप्लिकेट ऑर्डर के बजाय, उसके विवरण के माध्यम से संपादित करें; स्रोत बदलने पर कीमत, सेवा की कीमत, दैनिक क्रेडिट खपत, रीस्टार्ट और डाउनटाइम का जोखिम बदल जाता है।
faq/change-service-resources-after-order

क्या आप किसी मौजूदा सेवा को बदल रहे हैं, नई शुरू नहीं कर रहे?

यदि कोई सेवा पहले से चल रही है, तो उसके विवरण से संसाधनों में बदलाव करें। एक नया ऑर्डर मौजूदा सेवा को बदलने के बजाय एक और सेवा बनाएगा, और पुष्टि होने, भुगतान (यदि आवश्यक हो) और लागू होने के बाद यह मूल्य, दैनिक क्रेडिट खपत और संचालन व्यवहार को बदल सकता है।

परिवर्तन की पुष्टि करने से पहले

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

जब बदलाव अपेक्षित रूप से न हो पाए

सेवा का नाम, परिवर्तन का समय, दृश्यमान स्थिति और त्रुटि संदेश भेजें। निजी कुंजियाँ, पासवर्ड या टोकन न भेजें; निदान के लिए सार्वजनिक संदर्भ और मास्क की गई स्क्रीनशॉट पर्याप्त है।

> सेवा को रद्द करना और डेटा हटाने का समय

एक सक्रिय सेवा को पहले निलंबित किया जाता है, फिर एक कॉन्फ़िगर करने योग्य हटाने की समय सीमा प्रदर्शित होती है, और उसके बाद ही स्थायी रूप से साफ़ किया जा सकता है।
faq/cancel-service-and-data-retention

रद्द करना तत्काल हटाने नहीं है

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

स्थायी हटाने से पहले

  1. अपनी आवश्यकतानुसार डेटा का निर्यात करें, जिसे आप लंबे समय तक सुरक्षित रखना चाहते हैं।
  2. सस्पेंड की गई सेवा के लिए निर्धारित हटाने की तारीख और समय पढ़ें।
  3. बैकअप और ऑफसाइट आर्काइव को लाइफसाइकिल डिलीशन से अलग समझें।
  4. यदि आप निश्चित नहीं हैं, तो हटाने की समय-सीमा से पहले सपोर्ट टीम से संपर्क करें।

निर्धारित तिथि के बाद पुनर्प्राप्ति संभव नहीं हो सकती।

दिखाई गई समाप्ति तिथि के बाद, डेटा को उपलब्ध नहीं माना जाना चाहिए। प्रश्न पूछने पर, कृपया ऑर्डर नंबर और सेवा का नाम प्रदान करें, न कि डेटाबेस एक्सपोर्ट या गोपनीय लॉगिन क्रेडेंशियल।

> बैकअप और पुनर्स्थापना अनुरोध

बैकअप उत्पाद विकल्पों पर निर्भर करते हैं; पुनर्स्थापना नए डेटा को ओवरराइट कर सकती है।
faq/backups-and-restore-requests

बैकअप एक अभिलेखागार या निर्यात विकल्प नहीं है

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

रिकवरी अनुरोध कैसे तैयार करें

  1. सेवा का नाम और ऑर्डर नंबर बताएं।
  2. उस अनुमानित समय का वर्णन करें जिस पर आप वापस जाना चाहते हैं।
  3. लिखें कि क्या पूरी सेवा को पुनर्स्थापित किया जाना है या केवल एक विशिष्ट भाग, यदि समर्थित है।
  4. पासवर्ड, निजी कुंजियों, टोकन या गुप्त डेटा के बिना स्पष्ट त्रुटि या संदर्भ संलग्न करें।

पुनर्स्थापना से पहले प्रभाव का अनुमान लगाएं

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

> ऑफसाइट आर्काइव का क्या उपयोग है

ऑफसाइट आर्काइव, अन्य डेटासेंटर में रिमोट आर्काइव प्रतियां रखता है। यह छोटे ऑपरेशनल बैकअप और सर्विस डिलीशन टाइमिंग से अलग होता है, और यह लाइव एप्लिकेशन स्टोरेज नहीं है। बिलिंग संग्रहीत डेटा के समय पर आधारित होती है: संग्रहीत एमबी को दिनों की संख्या से गुणा किया जाता है, जिसे EUR/GB/महीने में दिखाया जाता है और पूरे सेंट तक पूर्णांकित किया जाता है।
faq/offsite-archive-purpose

सामान्य संचालन से बाहर का अभिलेखागार

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

इसे कब चालू करें

  1. इसका उपयोग उन डेटा के लिए करें जिन्हें आप सामान्य सेवा संचालन के बाहर भी रखना चाहते हैं।
  2. अपनी अनुपालन आवश्यकताओं या रिकवरी लक्ष्यों के अनुसार प्रतिधारण दिनों का चयन करें।
  3. ध्यान दें कि संग्रहीत मात्रा और भंडारण अवधि के आधार पर लागत बढ़ सकती है।
  4. बड़े डेटा के लिए, आर्काइव की योजना अपनी निर्यात प्रक्रिया के साथ बनाएं।

इसे अतिरिक्त परत की तरह उपयोग करें

आधार MB-दिनों में है: संग्रहीत डेटा की मात्रा और यह कितने दिनों तक रखा जाता है। ग्राहक को दर EUR/GB/महीने के रूप में दिखाई जाती है, और परिणाम को निकटतम पूर्ण सेंट पर पूर्णांकित किया जाता है।

> वीपीएस के लिए सीपीयू, रैम और डिस्क का चयन

वीपीएस का आकार एप्लिकेशन, डेटाबेस, कैश, लॉग और विकास को ध्यान में रखते हुए चुनें। यदि 'आउट ऑफ मेमोरी' (OOM) त्रुटि या स्वैपिंग हो रही है, तो यह अधिक रैम की आवश्यकता का संकेत है।
faq/vps-cpu-ram-and-disk-sizing

वास्तविक लोड के अनुसार शुरुआत करें, न कि केवल अनुमान के आधार पर

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

संकेत कि योजना छोटी है

  1. जब OOM (मेमोरी की कमी) त्रुटि हो, प्रक्रिया बंद हो जाए या लगातार स्वैपिंग हो रही हो, तो RAM बढ़ाएँ।
  2. यदि लंबे समय तक उच्च कंप्यूटिंग लोड, संपीड़न, बिल्ड या व्यस्त वर्कर एप्लिकेशन चल रहे हैं, तो CPU बढ़ाएँ।
  3. फ़ाइल सिस्टम, लॉग या डेटाबेस भरने से पहले डिस्क की जगह बढ़ा लें।
  4. प्रत्येक परिवर्तन के बाद, जांचें कि क्या एप्लिकेशन वास्तव में मूल सीमा तक पहुँचने बंद हो गया है।

साइज़िंग संबंधी प्रश्न पूछते समय क्या जानकारी भेजें

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

> वीपीएस के लिए सार्वजनिक आईपी कब उपयोगी होता है

एक समर्पित सार्वजनिक आईपी उन स्थितियों में सहायक होता है जहां आपको एक्सेस लिस्ट, इनबाउंड एक्सेस, एक स्थिर आउटबाउंड स्रोत या ऐसे सेवाओं की आवश्यकता होती है जो किसी विशिष्ट पते से जुड़ी हों।
faq/vps-public-ip-options

सबसे पहले संचार की दिशा जानें

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

IP मांगने से पहले

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

कौन सी चीजें बंद रखें

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

> वीपीएस के लिए साझा एसएसएच एक्सेस

साझा एसएसएच एक्सेस में, यदि आपने सार्वजनिक आईपी नहीं खरीदा है, तो वीपीएस एक साझा एसएसएच एंडपॉइंट का उपयोग करके उच्च पोर्ट पर कनेक्ट होता है। यदि आपके पास सार्वजनिक आईपी है, तो आप इस पते पर सीधे एसएसएच कनेक्शन भी स्थापित कर सकते हैं।
faq/shared-ssh-access-for-vps

उच्च पोर्ट का उपयोग क्यों किया जाता है?

कई VPS सेवाओं एक ही सार्वजनिक SSH एंडपॉइंट को साझा कर सकती हैं, इसलिए प्रत्येक सेवा को अपना उच्च पोर्ट मिलता है। पोर्ट आपके सेवा के लिए रूटिंग का हिस्सा है; इसके बिना, कनेक्शन को सही VPS पर स्पष्ट रूप से नहीं पहुंचाया जा सकता।

कनेक्शन करने का तरीका

  1. शेयर्ड SSH के लिए, SSH सेवा से उपयोगकर्ता नाम, सार्वजनिक होस्ट और पोर्ट की जानकारी कॉपी करें।
  2. ssh -p <पोर्ट> <उपयोगकर्ता नाम>@<सार्वजनिक-होस्ट> कमांड का उपयोग करके कनेक्ट करें।
  3. यदि सेवा में एक सार्वजनिक IP पता है, तो इसमें सीधे उस IP पते या उसके DNS नाम पर एक अतिरिक्त SSH एंडपॉइंट हो सकता है, जो सेवा की कॉन्फ़िगरेशन पर निर्भर करता है।
  4. अपनी निजी कुंजी का उपयोग केवल अपने SSH क्लाइंट या एजेंट के माध्यम से स्थानीय रूप से करें; सपोर्ट टीम को केवल सार्वजनिक होस्ट, पोर्ट, उपयोगकर्ता नाम और दिखाई देने वाली त्रुटि भेजें।

जब आपने सार्वजनिक आईपी खरीदा हो

सार्वजनिक IP साझा किए गए SSH एंडपॉइंट को प्रतिस्थापित नहीं करता है; यह एक्सेस करने का एक अलग तरीका जोड़ता है जो अनुमति सूचियों, निगरानी या सीधे कनेक्शन के लिए उपयुक्त है। व्यवहार में, आप दो प्रकार के SSH कनेक्शन देख सकते हैं: उच्च पोर्ट वाला साझा होस्ट और सार्वजनिक IP वाले सेवा के लिए सीधा होस्ट या IP।

> अपने डोमेन को कनेक्ट करने से पहले की जाँच

डोमेन बदलने से पहले, सुनिश्चित करें कि आपके पास सही DNS सेटिंग्स हैं, सटीक होस्टनाम है, रिकॉर्ड का प्रकार सही है (क्या यह एक डोमेन या सबडोमेन है), और कोई पुराना, संघर्षपूर्ण रिकॉर्ड नहीं है।
faq/custom-domain-readiness-checklist

यह जानना महत्वपूर्ण है

सबसे पहले यह स्पष्ट करें कि आप एक शीर्ष-स्तरीय डोमेन (जैसे example.com) या एक सबडोमेन (जैसे app.example.com) को जोड़ रहे हैं। प्रत्येक विकल्प के लिए अलग-अलग प्रकार की DNS प्रविष्टियों, DNS प्रदाता सीमाओं और रजिस्ट्रार सत्यापन की आवश्यकता हो सकती है।

DNS परिवर्तन से पहले

  1. वह सटीक डोमेन या सबडोमेन चुनें जहाँ आप DNS रिकॉर्ड संपादित कर रहे हैं।
  2. संघर्षपूर्ण A/AAAA, CNAME, ALIAS, ANAME या रीडायरेक्ट रिकॉर्ड को हटाएं या संशोधित करें।
  3. उस सेवा और होस्टनाम के लिए अनुशंसित रिकॉर्ड प्रकार का उपयोग करें।
  4. परिवर्तन के बाद, DNS प्रसार की प्रतीक्षा करें और फिर अंतिम HTTPS का परीक्षण करें।

सुरक्षित पुनर्स्थापना

मूल होस्टिंग को तब तक बंद न करें जब तक कि नया होस्टनाम सही ढंग से प्रतिक्रिया न दे। समस्या निवारण करते समय, डोमेन, अपेक्षित गंतव्य और दिखाई देने वाले DNS परिणाम प्रदान करें, लेकिन रजिस्ट्रेटर एक्सेस जानकारी नहीं।

> सेवाओं के लिए DNS रिकॉर्ड प्रकार

A/AAAA रिकॉर्ड्स IP एड्रेस की ओर इंगित करते हैं, CNAME एक उपनाम (alias) बनाता है, MX मेल सर्वर को निर्दिष्ट करता है, और TXT रिकॉर्ड का उपयोग सत्यापन, SPF, DKIM या DMARC के लिए किया जाता है।
faq/dns-record-types-for-services

हर रिकॉर्ड प्रकार का एक अलग कार्य होता है

A और AAAA रिकॉर्ड IP पतों की ओर इशारा करते हैं, CNAME एक सबडोमेन को दूसरे होस्टनाम पर रीडायरेक्ट करता है, MX मेल के लिए उपयोग किया जाता है, TXT सत्यापन और SPF/DKIM/DMARC के लिए उपयोग किया जाता है, और CAA प्रमाणपत्र प्राधिकरणों को सीमित करता है।

रिकॉर्ड कॉपी करते समय

  1. सेवा द्वारा दिए गए DNS प्रकार और लक्ष्य को ठीक से कॉपी करें।
  2. CNAME का उपयोग केवल उन सबडोमेन उपनामों के लिए करें जिन्हें अनुमति है, और एक ही होस्टनाम पर अन्य रिकॉर्ड न रखें।
  3. DKIM को प्रदाता चयनकर्ता के नीचे और DMARC को आमतौर पर _dmarc के नीचे रखें।
  4. CAA को सावधानीपूर्वक सेट करें, क्योंकि गलत मान प्रमाणपत्र जारी करने की प्रक्रिया को बाधित कर सकता है।

जब DNS ठीक से काम नहीं करता है

समर्थन टीम को होस्टनाम, रिकॉर्ड का प्रकार, अपेक्षित मान और सार्वजनिक रूप से दिखाई देने वाला परिणाम भेजें। DNS प्रशासन में लॉगिन जानकारी या API टोकन वाली स्क्रीनशॉट न भेजें।

> DNS प्रसार और TTL: मिनटों में होने की कोई गारंटी नहीं

TTL यह निर्धारित करता है कि रिज़ॉल्वर कितने समय तक पुराने उत्तर को बरकरार रख सकते हैं; संक्रमण के दौरान, पुराने और नए परिणाम एक साथ मौजूद हो सकते हैं।
faq/dns-propagation-and-ttl

प्रसार एक कैश है, कोई जादुई प्रतीक्षा नहीं

DNS में प्रति मिनट की कोई निश्चित गारंटी नहीं होती है। जब आप आधिकारिक DNS बदलते हैं, तो विभिन्न रिज़ॉल्वर अभी भी पुराने और नए उत्तर दे सकते हैं जब तक कि उनका कैश TTL के अनुसार समाप्त न हो जाए। इसलिए, परिणाम नेटवर्क, देशों या DNS रिज़ॉल्वरों के बीच भिन्न हो सकता है।

योजनाबद्ध परिवर्तन के लिए

  1. यदि आपका DNS प्रदाता अनुमति देता है, तो नियोजित परिवर्तन से पहले TTL को कम करें।
  2. DNS में एक बार बदलाव करें और कैश समाप्त होने तक बार-बार बदलाव न करें।
  3. यदि परिणाम भिन्न हैं, तो कई रिज़ॉल्वरों या नेटवर्क से परीक्षण करें।
  4. परिवर्तन का समय, पुराना मान, नया मान और टीटीएल (TTL) नोट कर लें।

निदान के दौरान क्या भेजें

होस्टनाम, अपेक्षित परिणाम, दिखाई देने वाला पुराना उत्तर, दिखाई देने वाला नया उत्तर, टीटीएल (TTL) और परिवर्तन का समय प्रदान करें। कृपया DNS खाते की जानकारी या प्रदाता के आंतरिक नोट्स न भेजें।

> नेक्स्टक्लाउड के लिए स्टोरेज प्लानिंग

स्टोरेज क्षमता की योजना बनाते समय, उपयोगकर्ता फ़ाइलों, साझा फ़ोल्डरों, पुराने संस्करणों, ट्रैश, थंबनेल्स, सिंक ओवरहेड और टीम के विकास को शामिल करें।
faq/nextcloud-storage-planning

नेक्स्टक्लाउड का उपयोग वास्तविक फ़ाइलों से अधिक स्थान लेता है

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

क्षमता बुक करने से पहले

  1. ऑर्डर करने से पहले वर्तमान उपयोगकर्ताओं के डेटा और साझा फ़ोल्डरों का अनुमान लगाएं।
  2. वर्जन, कचरा, पूर्वावलोकन और सिंक ओवरहेड के लिए अतिरिक्त जगह जोड़ें।
  3. बड़े इम्पोर्ट, नई टीमों और अपेक्षित वृद्धि को ध्यान में रखें।
  4. उपयोगकर्ताओं को सीमा तक पहुंचने से पहले ही क्षमता बढ़ाएं।

सिंक्रोनाइज़ेशन में समस्या होने पर

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

> गिटिया में रिपॉजिटरी का माइग्रेशन

गिट एलएफएस, सबमॉड्यूल, संरक्षित शाखाओं/टैग, डिप्लॉय कीज़, टोकन, वेबहुक और सीआई/सीडी के साथ गिटिया माइग्रेशन की योजना बनाएं।
faq/gitea-repository-migration

माइग्रेशन केवल गिट क्लोन नहीं है

रिपॉजिटरी के इतिहास के अलावा, आपको मालिकों, टीमों, संरक्षित शाखाओं, संरक्षित टैग, Git LFS, सबमॉड्यूल, डिप्लॉय कीज़, वेबहुक और CI/CD कनेक्शन को भी स्थानांतरित या फिर से कॉन्फ़िगर करने की आवश्यकता होती है।

माइग्रेशन से पहले जांच

  1. रिपॉजिटरी, मालिकों, सहयोगियों, ऑटोमेशन खातों आदि की सूची बनाएं।
  2. Git LFS ऑब्जेक्ट्स, सबमॉड्यूल्स, ब्रांच प्रोटेक्शन और टैग प्रोटेक्शन की जांच करें।
  3. स्थानांतरण के बाद, क्लोन, पुश, Git LFS, सबमॉड्यूल्स और CI रन का परीक्षण करें।
  4. माइग्रेशन के बाद पुराने टोकन को रद्द करें या उनके मूल्यों को साझा किए बिना बदल दें।

माइग्रेशन के दौरान संवेदनशील डेटा

सपोर्ट टीम को टोकन, प्राइवेट की, डिप्लॉय की प्राइवेट भाग या CI सीक्रेट न भेजें। केवल रिपॉजिटरी के नाम, एकीकरण का प्रकार, दिखाई देने वाली त्रुटि और यह जानकारी पर्याप्त है कि माइग्रेशन से पहले क्या ठीक काम कर रहा था।

> लिस्टमोंक के लिए प्रेषण डोमेन

अभियानों के लिए एक प्रेषण डोमेन या सबडोमेन तैयार करें, साथ ही फ्रॉम पहचान, एसपीएफ, डीकेआईएम, डीएमएआरसी, बाउंस और अनसब्सक्राइब जानकारी भी।
faq/listmonk-sender-domain-basics

डिलीवरी डोमेन से शुरू होती है

लिस्टमंक को एक स्पष्ट 'प्रेषक' पहचान (From identity) और ऐसे DNS रिकॉर्ड की आवश्यकता होती है जिन्हें डाक प्रणाली सत्यापित कर सके। SPF, DKIM और DMARC आपके डोमेन या सबडोमेन के साथ मेल खाने चाहिए जिससे आप अभियान भेजना चाहते हैं।

पहले अभियान से पहले

  1. कैंपेन के लिए एक डोमेन या सबडोमेन चुनें और 'From' पहचान सेट करें।
  2. अपने मेल प्रदाता द्वारा अनुरोधित सत्यापन DNS, SPF, DKIM और DMARC रिकॉर्ड प्रकाशित करें।
  3. वास्तविक अभियान शुरू करने से पहले परीक्षण संदेश भेजें और स्पैम प्लेसमेंट, बाउंस व्यवहार, रिटर्न-पाथ और लिंक की जांच करें।
  4. लाइव भेजने से पहले अनसब्सक्राइब (unsubscribe) और लिस्ट-अनसब्सक्राइब (List-Unsubscribe) की जांच करें।

ईमेल संबंधी जानकारी टिकट में शामिल नहीं होनी चाहिए।

समस्या निवारण करते समय, डोमेन, रिकॉर्ड का प्रकार, सार्वजनिक रूप से दिखाई देने वाला DNS मान और त्रुटि संदेश भेजें। SMTP पासवर्ड, API टोकन, निजी DKIM कुंजी या व्यक्तिगत डेटा वाले ग्राहक सूची निर्यात जैसी जानकारी न भेजें।

> क्लासिक होस्टिंग के लिए रनटाइम सेटिंग्स

क्लासिक होस्टिंग ऑटो या मैनुअल रनटाइम मोड में चल सकता है। CPU, RAM, मेमोरी, स्टोरेज, बैकअप रिटेंशन, ऑफसाइट आर्काइव रिटेंशन, अपलोड, कैश और लॉग्स की कीमत और स्थिरता दोनों पर प्रभाव डालते हैं।
faq/classic-hosting-runtime-settings

ऑटो मोड ही एकमात्र सही विकल्प नहीं है

ऑटो रनटाइम उन परियोजनाओं की पहचान करने में मदद करता है, लेकिन मैनुअल मोड तब उपयुक्त होता है जब आप Nginx, Apache, FrankenPHP या किसी विशिष्ट भाषा रनटाइम को सटीक रूप से चुनना चाहते हैं। PHP चयनकर्ता का उपयोग केवल तभी करें जब चयनित रनटाइम द्वारा इसका समर्थन किया जाता है।

तैनाती से पहले की सेटिंग्स

  1. एप्लिकेशन और फ्रेमवर्क के अनुसार ऑटो या मैनुअल मोड चुनें।
  2. PHP 8.2, 8.3 या 8.4 केवल तभी चुनें जब चयनित रनटाइम इसका समर्थन करता हो।
  3. डेटा और ट्रैफिक के अनुसार CPU, RAM, स्टोरेज, बैकअप रिटेंशन और ऑफसाइट आर्काइव रिटेंशन सेट करें।
  4. तैनाती के बाद, अपलोड, कैश, लॉग और दिखाई देने वाली एप्लिकेशन त्रुटियों का परीक्षण करें।

जब एप्लिकेशन शुरू नहीं होता है

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

> समर्थन टीम को सुरक्षित रूप से कौन सी जानकारी भेजनी चाहिए?

सहायता के लिए सबसे उपयोगी जानकारी में ऑर्डर नंबर, सेवाओं के नाम, डोमेन, समय, सार्वजनिक होस्ट, पोर्ट, बैकअप रिटेंशन, ऑफसाइट आर्काइव रिटेंशन, अपलोड, कैश, लॉग, स्क्रीनशॉट और दिखाई देने वाली त्रुटियां शामिल हैं। गोपनीय जानकारी न भेजें।
faq/support-safe-information-to-share

एक अच्छी टिकट में प्रासंगिक जानकारी होती है, गुप्त जानकारी नहीं।

सहायता टीम तेजी से प्रतिक्रिया दे पाती है जब उसे ऑर्डर नंबर, सेवा का नाम, डोमेन, सार्वजनिक होस्ट या पोर्ट, समस्या का समय, क्या बदला गया था और सटीक त्रुटि संदेश जैसे विवरण मिलते हैं।

सुरक्षित सामग्री

  1. कृपया ऑर्डर नंबर, सेवा का नाम, डोमेन, समय और उस चरण के बारे में जानकारी दें जिसमें समस्या हुई थी।
  2. होस्टिंग संबंधी समस्याओं के लिए, रनटाइम मोड, भाषा या PHP संस्करण, CPU, RAM, स्टोरेज, बैकअप प्रतिधारण, ऑफसाइट आर्काइव प्रतिधारण, अपलोड, कैश और लॉग शामिल करें, और बताएं कि हाल ही में क्या बदला है।
  3. स्क्रीनशॉट भेजने से पहले पासवर्ड, टोकन, निजी कुंजियाँ, सत्र और व्यक्तिगत डेटा छिपाएं।
  4. यदि आपको यकीन नहीं है कि कोई जानकारी टिकट के लिए उपयुक्त है, तो उसे भेजने से पहले पूछें।

कभी भी यह जानकारी न भेजें

पासवर्ड, प्राइवेट की, रिकवरी सीड्स, एपीआई टोकन, सेशन कुकीज़, डेटाबेस एक्सपोर्ट, संपूर्ण .env फ़ाइलें, संवेदनशील मूल्यों वाली पूर्ण लॉग या आंतरिक इंफ्रास्ट्रक्चर विवरण न भेजें।