FAQ

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

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

> टर्मिनल में सार्वजनिक SSH कुंजी बनाएं

एक्सेस के लिए सार्वजनिक SSH कुंजी बनाएं और केवल सार्वजनिक हिस्सा साझा करें।
faq/generate-public-ssh-key-hi

केवल सार्वजनिक कुंजी इस्तेमाल करें

SSH एक कुंजी जोड़ी का उपयोग करता है। सेवा सेटिंग में केवल सार्वजनिक कुंजी, आमतौर पर .pub फाइल, चिपकाएं। निजी कुंजी आपके डिवाइस पर रहती है।

टर्मिनल के चरण

  1. Terminal, Windows Terminal या PowerShell खोलें।
  2. चलाएं: ssh-keygen -t ed25519 -C "your-email@example.com"।
  3. डिफॉल्ट लोकेशन स्वीकार करें या सुरक्षित पथ चुनें।
  4. सार्वजनिक कुंजी दिखाएं: cat ~/.ssh/id_ed25519.pub।
  5. Windows PowerShell में उपयोग करें: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub।
  6. पूरी ssh-ed25519 लाइन SSH public key फील्ड में कॉपी करें।

चिपकाने से पहले जांचें

निजी कुंजी कॉपी न करें। यदि passphrase सेट करें तो उसे सुरक्षित रखें।

> Windows GUI में SSH कुंजी बनाएं

Windows में PuTTYgen से SSH कुंजी बनाएं और केवल सार्वजनिक कुंजी कॉपी करें।
faq/create-ssh-key-windows-gui-hi

सिर्फ सार्वजनिक हिस्सा चाहिए

PuTTYgen सार्वजनिक और निजी कुंजी बनाता है। Cli>_ में केवल सार्वजनिक कुंजी जोड़ें और निजी कुंजी अपने पास रखें।

Windows के चरण

  1. PuTTYgen खोलें।
  2. उपलब्ध हो तो EdDSA / Ed25519 चुनें।
  3. RSA 4096 केवल बैकअप विकल्प के रूप में इस्तेमाल करें।
  4. Generate क्लिक करें और कुंजी बनने तक माउस हिलाएं।
  5. निजी कुंजी अपने कंप्यूटर पर सेव करें।
  6. सार्वजनिक कुंजी का टेक्स्ट SSH public key फील्ड में कॉपी करें।

गुप्त डेटा साझा न करें

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

> Apna domain joden

Registrar या authoritative nameservers, exact hostname, apex या subdomain, CNAME/A/AAAA/ALIAS/ANAME support और conflicts जांचें।
faq/apna-domain-joden

Domain को service target पर point करना चाहिए

Final testing से पहले domain service में दिखे target पर point होना चाहिए। तरीका इस पर निर्भर है कि hostname apex है, जैसे example.com, या subdomain, जैसे app.example.com, और DNS provider क्या support करता है।

DNS readiness check

  1. उपयोग करने वाला exact hostname चुनें।
  2. Confirm करें कि registrar या authoritative nameservers सही edit place हैं।
  3. उसी hostname के conflicting records हटाएं।
  4. CNAME, A/AAAA, ALIAS या ANAME तभी इस्तेमाल करें जब provider और hostname type support करे।

पूरा नाम test करें

Visitors जिस full hostname का उपयोग करेंगे उसे test करें, केवल root domain नहीं। apex और subdomain में record type और verification तरीका अलग हो सकता है।

> DNS zone pratinidhitva

Services आम तौर पर A/AAAA, CNAME, MX, TXT और CAA उपयोग करती हैं; mail SPF, DKIM selector और _dmarc पर DMARC उपयोग करता है।
faq/dns-zone-pratinidhitva

हर record type की भूमिका अलग है

A और AAAA addresses की ओर point करते हैं, CNAME subdomain को दूसरे hostname पर भेजता है, MX mail के लिए है, TXT verification और SPF/DKIM/DMARC के लिए है, और CAA certificate authorities सीमित करता है।

Record conflicts से बचें

  1. Service page से type और target ठीक copy करें।
  2. उसी hostname पर CNAME के साथ दूसरे records न रखें।
  3. DKIM provider selector के नीचे और DMARC _dmarc के नीचे रखें।
  4. CAA सावधानी से बदलें क्योंकि गलत value certificate issuance रोक सकती है।

एक record साफ तरीके से बदलें

सुधार करते समय पुरानी value, नई value और change time लिखें। इससे cache खत्म होने तक दिखने वाले mixed DNS results समझना आसान होता है।

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

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

सेवा प्रबंधन एक खाते से होता है

ग्राहक खाता ऑर्डर, बिलिंग जानकारी, डोमेन और सेवा प्रबंधन के लिए उपयोग होता है। ऐसा कार्य ईमेल चुनें जिसे आपकी टीम लंबे समय तक चला सके।

पहले भुगतान वाले ऑर्डर से पहले

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

खाते का स्वामित्व बनाए रखें

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

> प्रीपेड क्रेडिट और दैनिक सेवा लागत

प्रीपेड क्रेडिट दिखाई देने वाला बैलेंस, अनुमानित रनवे, दैनिक लागत, टॉप अप समय और निलंबन या दृश्य हटाने की समय सीमा दिखाता है।
faq/prepaid-credit-how-it-works

सेवा चलते समय क्रेडिट खर्च होता है

योग्य सेवाएं चलने के समय के अनुसार क्रेडिट खर्च करती हैं। दिखाई देने वाला बैलेंस, रनवे अनुमान, दैनिक सेवा लागत और निलंबित सेवा की दृश्य हटाने की समय सीमा समय पर टॉप अप करने में मदद करती है।

टॉप अप कब करें

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

आखिरी दिन तक प्रतीक्षा न करें

यदि रनवे कम दिख रहा है तो पहले ही क्रेडिट जोड़ें। निलंबन खर्च रोकता है, लेकिन सेवा बंद हो सकती है और संरक्षण अवधि के बाद डेटा हटना शुरू हो सकता है।

> बिलिंग अवधि और क्रेडिट खर्च

मासिक अनुमान 31 दिन और वार्षिक अनुमान 372 दिन पर आधारित हैं; बदलाव पुष्टि, आवश्यक भुगतान और लागू होने के बाद दैनिक खर्च बदलता है।
faq/billing-periods-and-credit-burn

मासिक और वार्षिक राशि तुलना के लिए है

मासिक अनुमान 31 दिन और वार्षिक अनुमान 372 दिन का उपयोग करते हैं। वास्तविक क्रेडिट खर्च सक्रिय समय, CPU, RAM, storage और भुगतान विकल्पों पर निर्भर करता है।

पुष्टि से पहले लागत पढ़ें

  1. 31 दिन मासिक या 372 दिन वार्षिक अनुमान की दैनिक खर्च से तुलना करें।
  2. देखें कि संसाधन बदलाव दैनिक लागत बढ़ाता है या घटाता है।
  3. जरूरत होने पर पुष्टि और भुगतान करें, फिर लागू होने की प्रतीक्षा करें।
  4. लेखा के लिए invoice, order confirmation और credit history सहेजें।

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

सिर्फ चुना हुआ लेकिन अपुष्ट विकल्प लागत नहीं बदलता। ऑर्डर या बदलाव पुष्टि, जरूरी भुगतान और सेवा पर लागू होने के बाद दैनिक खर्च बदलता है।

> ऑर्डर स्थिति और भुगतान पुष्टि

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

Pending का अर्थ हमेशा विफलता नहीं है

भुगतान के बाद भुगतान प्रदाता की पुष्टि आने में कुछ समय लग सकता है। पहला ऑर्डर स्पष्ट रूप से expired या cancelled न हो तो नया ऑर्डर न बनाएं।

भुगतान के बाद जांच

  1. भुगतान पूरा होने पर payment provider पेज से Cli>_ पर वापस आएं।
  2. अपने खाते में ऑर्डर स्थिति देखें।
  3. यदि ऑर्डर pending है तो प्रदाता की पुष्टि की प्रतीक्षा करें।
  4. स्थिति न बदले तो ऑर्डर नंबर और उपलब्ध payment provider reference समर्थन को भेजें।

डुप्लिकेट ऑर्डर से बचें

यदि भुगतान पेज बंद हो गया या ब्राउजर देर से लौटा, तो पहले मौजूदा ऑर्डर जांचें। बहुत जल्दी नया ऑर्डर बनाने से ट्रैकिंग और बिलिंग भ्रमित हो सकती है।

> सेवा सेटअप के लिए आवश्यक जानकारी

सेवा नाम, डोमेन, DNS योजना, storage, संसाधन, admin email और SSH public key तैयार रखें; secrets न भेजें।
faq/service-setup-information-needed

सही सार्वजनिक मान देरी कम करते हैं

अधिकांश सेवाओं को सेवा नाम, डोमेन, DNS readiness, storage size, CPU या RAM, access या admin email और SSH public key जैसे ग्राहक विकल्प चाहिए। Passwords, private keys या tokens सेटअप fields में न डालें।

ऑर्डर तैयारी सूची

  1. भुगतान से पहले product form पढ़ें।
  2. डोमेन, DNS कार्य और SSH public key पहले तैयार करें।
  3. टीम को समझ आने वाले स्पष्ट सेवा नाम इस्तेमाल करें।
  4. सार्वजनिक मान मांगने वाले fields में secrets न डालें।

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

SSH के लिए केवल सार्वजनिक कुंजी भेजें, जो अक्सर ssh-ed25519 या ssh-rsa से शुरू होती है। निजी कुंजी आपके डिवाइस पर रहती है और सक्रियण के लिए जरूरी नहीं है।

> ऑर्डर के बाद सेवा संसाधन बदलना

CPU, RAM, storage या retention विकल्प बदलने से पहले नया मूल्य, दैनिक credit burn और restart या downtime जोखिम जांचें।
faq/change-service-resources-after-order

मौजूदा सेवा को बदलें

संसाधन बदलाव मौजूदा सेवा से करें, नई डुप्लिकेट सेवा ऑर्डर बनाकर नहीं। नया मूल्य और दैनिक credit burn पुष्टि, जरूरत के भुगतान और लागू होने के बाद प्रभावी होते हैं। कुछ बदलाव restart या maintenance window मांग सकते हैं।

सुरक्षित बदलाव प्रक्रिया

  1. मौजूदा सेवा खोलें और CPU, RAM, storage और retention देखें।
  2. आवश्यक बदलाव चुनें और नया मूल्य तथा दैनिक खर्च जांचें।
  3. जरूरत होने पर पुष्टि और भुगतान करें, फिर लागू होने की प्रतीक्षा करें।
  4. downtime वाले बदलाव से पहले महत्वपूर्ण data export करें।

बदलाव का समय तय करें

जो बदलाव पुनरारंभ करा सकते हैं उन्हें उपयोगकर्ताओं के लिए उचित समय पर करें। यदि ऐप downtime-संवेदनशील है, तो पुष्टि से पहले export या वापसी योजना तैयार रखें।

> सेवा रद्द करना और डेटा संरक्षण

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

रद्द करना automatic export नहीं है

सक्रिय सेवा रद्द होने पर पहले निलंबित होती है और कॉन्फिगर की जा सकने वाली हटाने की समय सीमा दिखती है। अवधि पूरी होने पर स्थायी सफाई होती है। बिना भुगतान वाले और अभी सक्रिय न हुए ऑर्डर उसी runtime data lifecycle से नहीं गुजर सकते। Backups और Offsite Archive की retention अलग है।

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

  1. रद्द करने या लंबे credit depletion से पहले अपना export बनाएं।
  2. suspension notice और visible deletion deadline पढ़ें।
  3. backup retention और Offsite Archive retention सेवा deletion से अलग हैं।
  4. संदेह हो तो deadline से पहले support से संपर्क करें।

दिखी तारीख जांचें

दिखी हुई हटाने की समय सीमा को वास्तविक अंतिम तारीख मानें। यदि डेटा चाहिए, तो उस तारीख से पहले export करें या समर्थन से संपर्क करें।

> Backups और restore अनुरोध

Backup retention product options पर निर्भर है; restore नया data overwrite कर सकता है, इसलिए बिना secrets के स्पष्ट संदर्भ भेजें।
faq/backups-and-restore-requests

Backup operational recovery के लिए है

Backups operational recovery में मदद करते हैं और आपके अपने exports या long-term archive का replacement नहीं हैं। Restore newer data को overwrite कर सकता है।

उपयोगी restore request

  1. Product या service पर backup retention option देखें।
  2. Business-critical data के लिए अलग exports रखें।
  3. Service name, order number, approximate restore time और visible error या context भेजें।
  4. Passwords, private keys, tokens या secret data न भेजें।

Restore point बताएं

अच्छे restore request में समस्या से पहले का अनुमानित समय और बाद में जांचने वाली चीजें होती हैं। इससे गलत point restore होने का जोखिम घटता है।

> Offsite Archive किसलिए है

Offsite Archive दूसरे datacenter में remote archive copies रखता है और short operational backups तथा service deletion timing से अलग है।
faq/offsite-archive-purpose

Remote archive, live storage नहीं

Offsite Archive remote archive copies के लिए है, active application storage के लिए नहीं। यह short operational backups और service deletion deadline से अलग है।

Retention और लागत

  1. Recovery या compliance जरूरत के अनुसार retention days चुनें।
  2. Stored MB को stored days से गुणा करके MB-days का अनुमान लगाएं।
  3. Data या retention बढ़ने पर monthly archive cost जांचें।
  4. इसे short backups या service deletion deadline का replacement न मानें।

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

Offsite Archive बड़े हादसों या compliance जरूरतों के लिए दूरस्थ retention layer है। यह operational backups या application health monitoring का replacement नहीं है।

> VPS CPU, RAM और disk size चुनना

VPS size workload, database, cache, logs और expected growth के अनुसार चुनें, और OOM या out of memory संकेतों पर ध्यान दें।
faq/vps-cpu-ram-and-disk-sizing

Application symptoms size बताते हैं

Databases, containers, search और Java applications को अक्सर छोटे static site से अधिक RAM और disk चाहिए। OOM, out of memory या process killed messages कम RAM का संकेत हो सकते हैं।

Resources कब बढ़ाएं

  1. Application requirements पूरी करने वाले सबसे छोटे size से शुरू करें।
  2. OOM, heavy swap या process killed दिखे तो RAM बढ़ाएं।
  3. Sustained compute या builds के लिए CPU बढ़ाएं।
  4. Filesystem भरने से पहले disk बढ़ाएं।

बढ़ाने से पहले निगरानी करें

यदि धीमेपन का कारण स्पष्ट नहीं है, तो पहले error messages और resource usage इकट्ठा करें। एक resource बढ़ाने से application या database issue हमेशा ठीक नहीं होता।

> VPS public IP विकल्प

Dedicated public IP तब उपयोग करें जब बाहरी provider या firewall को स्थिर allowlist, direct access या स्थिर outbound source चाहिए।
faq/vps-public-ip-options

Dedicated IP कब मदद करता है

Dedicated public IP तब उपयोगी है जब external partner, provider या firewall inbound, outbound source या दोनों दिशाओं के लिए stable address मांगता है। संभव हो तो DNS names इस्तेमाल करें और केवल जरूरी ports खोलें।

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

  1. External party से पूछें कि inbound, outbound source या दोनों allowlist चाहिए।
  2. Firewall में केवल application के जरूरी ports खोलें।
  3. Numeric IP के बजाय DNS names उपयोग करें जहां संभव हो।
  4. Access design बदलने से पहले allowlist requirement support को बताएं।

DNS, direct SSH और shared SSH

Dedicated public IP होने पर उस address की ओर pointing DNS name इस्तेमाल किया जा सकता है, और port allowed हो तो service address पर direct SSH हो सकता है। Dedicated IP न होने पर shared SSH service-specific high port और public host इस्तेमाल करता है, जैसे ssh -p @.

> VPS के लिए shared SSH access

Shared SSH में service page पर दिखे username, public host और high port के साथ ssh -p <port> <username>@<public-host> उपयोग करें।
faq/shared-ssh-access-for-vps

High port login detail का हिस्सा है

Customer area SSH username, आम तौर पर vps.cliopen.cloud के नीचे DNS name वाला public host, और assigned port दिखाता है। Shared SSH में port 22 मानकर न चलें; service पर दिखा high port ठीक-ठीक उपयोग करें। Dedicated public IP हो तो उस IP या उसके DNS name से अलग direct SSH path भी available हो सकता है।

कनेक्शन command

  1. Service page से SSH username, public host और port copy करें।
  2. Local terminal में ssh -p <port> <username>@<public-host> चलाएं।
  3. Private key local रखें; chat या ticket में paste न करें।
  4. Failure पर service name, host, port, username और visible error भेजें।

Private key local रखें

Private key केवल आपके device पर रहनी चाहिए। उसे ticket या chat में न भेजें; support को सिर्फ visible connection details और error साझा करें।

> Custom domain तैयारी जांच सूची

Registrar या authoritative nameservers, exact hostname, apex या subdomain, CNAME/A/AAAA/ALIAS/ANAME support और conflicts जांचें।
faq/custom-domain-readiness-checklist

Domain को service target पर point करना चाहिए

Final testing से पहले domain service में दिखे target पर point होना चाहिए। तरीका इस पर निर्भर है कि hostname apex है, जैसे example.com, या subdomain, जैसे app.example.com, और DNS provider क्या support करता है।

DNS readiness check

  1. उपयोग करने वाला exact hostname चुनें।
  2. Confirm करें कि registrar या authoritative nameservers सही edit place हैं।
  3. उसी hostname के conflicting records हटाएं।
  4. CNAME, A/AAAA, ALIAS या ANAME तभी इस्तेमाल करें जब provider और hostname type support करे।

पूरा नाम test करें

Visitors जिस full hostname का उपयोग करेंगे उसे test करें, केवल root domain नहीं। apex और subdomain में record type और verification तरीका अलग हो सकता है।

> Services के लिए DNS record प्रकार

Services आम तौर पर A/AAAA, CNAME, MX, TXT और CAA उपयोग करती हैं; mail SPF, DKIM selector और _dmarc पर DMARC उपयोग करता है।
faq/dns-record-types-for-services

हर record type की भूमिका अलग है

A और AAAA addresses की ओर point करते हैं, CNAME subdomain को दूसरे hostname पर भेजता है, MX mail के लिए है, TXT verification और SPF/DKIM/DMARC के लिए है, और CAA certificate authorities सीमित करता है।

Record conflicts से बचें

  1. Service page से type और target ठीक copy करें।
  2. उसी hostname पर CNAME के साथ दूसरे records न रखें।
  3. DKIM provider selector के नीचे और DMARC _dmarc के नीचे रखें।
  4. CAA सावधानी से बदलें क्योंकि गलत value certificate issuance रोक सकती है।

एक record साफ तरीके से बदलें

सुधार करते समय पुरानी value, नई value और change time लिखें। इससे cache खत्म होने तक दिखने वाले mixed DNS results समझना आसान होता है।

> DNS propagation और TTL

DNS propagation time का fixed promise नहीं होता, क्योंकि TTL और resolver cache पुराने और नए answers को साथ-साथ रख सकते हैं।
faq/dns-propagation-and-ttl

Cache अलग-अलग results दिखा सकता है

Record बदलने के बाद कुछ users नया answer देख सकते हैं और कुछ cache expire होने तक पुराना answer। इसलिए exact propagation time का guarantee नहीं है।

DNS change शांत तरीके से करें

  1. Provider अनुमति दे तो planned change से पहले TTL घटाएं।
  2. Change एक बार करें और cache expire होने तक बार-बार edit न करें।
  3. Results अलग हों तो कई resolvers या networks से test करें।
  4. Support को hostname, old answer, expected answer, TTL और change time भेजें।

Cache के पीछे न भागें

प्रतीक्षा के दौरान बार-बार edit करने से diagnosis लंबा हो सकता है। अपेक्षित TTL के बाद trusted resolver या अलग network से test करें।

> Nextcloud storage योजना

Nextcloud storage में user files, shared folders, trash, versions, previews, thumbnails और expected growth शामिल करें।
faq/nextcloud-storage-planning

Actual usage raw files से अधिक होता है

Nextcloud को user files, shared folders, deleted files, version history, previews, thumbnails और sync activity के लिए जगह चाहिए। Limit के करीब चलना uploads और sync तोड़ सकता है।

Growth headroom रखें

  1. Order से पहले current data size estimate करें।
  2. Trash, versions, previews और thumbnails के लिए headroom जोड़ें।
  3. Large imports से पहले team के साथ usage review करें।
  4. Users limit से टकराएं उससे पहले storage बढ़ाएं।

काम करने की जगह छोड़ें

Sync, previews और version history को temporary और permanent space चाहिए। Allocated storage का 100% उपयोग करने की योजना न बनाएं।

> Repositories को Gitea में migrate करना

Gitea migration को Git LFS, submodules, protected branches/tags, deploy keys, tokens, webhooks और CI/CD के आसपास plan करें।
faq/gitea-repository-migration

Migration सिर्फ history copy नहीं है

Move से पहले owners, teams, Git LFS, submodules, protected branches, protected tags, remote URLs, webhooks, CI/CD, deploy keys और old tokens की सूची बनाएं। Token values reveal न करें; migration के बाद rotate या recreate करें।

Migration के बाद verify करें

  1. Old provider से repositories export या mirror करें।
  2. Branches, tags और Git LFS files verify करें।
  3. Remote URLs, webhooks, CI/CD और deploy keys update करें।
  4. Old access हटाने से पहले clone, push, Git LFS, submodules और CI test करें।

Source बंद करने से पहले verify करें

Migration के बाद old provider access हटाने या original repositories delete करने से पहले clone, push, CI और team accounts test करें।

> Listmonk sender domain की मूल बातें

Listmonk को sender domain या subdomain, From identity, SPF, DKIM, DMARC और campaign से पहले testing चाहिए।
faq/listmonk-sender-domain-basics

Identity और DNS delivery सुधारते हैं

Newsletters बेहतर deliver होते हैं जब From identity स्पष्ट हो और DNS records सही हों। SPF mail provider की बताई जगह पर, DKIM selector के साथ और DMARC _dmarc पर publish करें।

पहले campaign से पहले

  1. Campaigns के लिए domain या subdomain चुनें।
  2. Mail provider के verification DNS, SPF, DKIM और DMARC records publish करें।
  3. Real campaign से पहले test messages, bounce, Return-Path और links जांचें।
  4. Unsubscribe, List-Unsubscribe और sender identity सही रखें, secrets share न करें।

Test send से शुरू करें

पूरी list पर भेजने से पहले small campaign या test message भेजें। Volume बढ़ाने से पहले bounce, links और authentication results देखें।

> Classic Hosting runtime सेटिंग्स

Classic Hosting PHP, Node.js, Java, Python, .NET, Go, Ruby, Nginx, Apache और FrankenPHP के लिए auto और manual mode support करता है।
faq/classic-hosting-runtime-settings

Auto या manual चुनें

Auto mode PHP, Node.js, Java, Python, .NET, Go और Ruby projects detect और build करता है। Manual mode Nginx, Apache या FrankenPHP control के लिए है। PHP selector केवल chosen runtime support होने पर लागू होता है।

Runtime संसाधन

  1. Application और framework के अनुसार auto या manual चुनें।
  2. PHP 8.2, 8.3 या 8.4 केवल support होने पर चुनें।
  3. CPU, RAM, storage, backup retention और Offsite Archive retention set करें।
  4. Deployment के बाद uploads, cache, logs और visible errors test करें।

Runtime को app से match करें

Build detection चाहिए तो auto चुनें; server या PHP version पता हो तो manual चुनें। First deployment के बाद logs देखें।

> समर्थन के साथ सुरक्षित रूप से साझा की जाने वाली जानकारी

ऑर्डर नंबर, सेवा नाम, डोमेन, समय, दिखी त्रुटियां और hosting settings साझा करें, लेकिन secrets न भेजें।
faq/support-safe-information-to-share

Visible customer context अक्सर पर्याप्त है

Safe details में order number, visible service name, domain, public host या port, runtime, PHP version, CPU, RAM, storage, backup retention, Offsite Archive retention, uploads, cache, logs, issue time, masked screenshot और visible error text शामिल हैं।

क्या न भेजें

  1. Passwords, private keys, tokens या seed phrases न भेजें।
  2. Secrets वाले full logs या database exports न भेजें।
  3. Screenshots लगाने से पहले personal data और sessions छिपाएं।
  4. Unredacted configuration files या private infrastructure names और addresses share न करें।

अनावश्यक जानकारी छिपाएं

Screenshot या log भेजने से पहले sessions, tokens और personal email छिपाएं। केवल वही साझा करें जिससे service और error पहचाने जा सकें।