विशेषताएं

सबडोमेन जो वास्तविक साइटों की तरह काम करते हैं

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

एक DNS ज़ोन जो अपने द्वारा प्रकाशित रिकॉर्डों में विस्तारित हो रहा है।
  • 1-क्लिकस्टेजिंग सबडोमेन और पुश-टू-लाइव
  • वाइल्डकार्डSSL स्वचालित रूप से जारी, निःशुल्क
  • 99.99%अपटाइम का आश्वासन
  • 7,00,000+दुनिया भर में होस्ट की गई साइटें

यहाँ एक सबडोमेन एक पूरी साइट है, कोई फ़ोल्डर नहीं

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

इसका अपना स्टैक और ब्लूप्रिंट

प्रत्येक सबडोमेन साइट एक संस्करणबद्ध ब्लूप्रिंट से बनाई गई है और अपने स्वयं के स्टैक प्रकार और रनटाइम को चलाती है: प्रबंधित WordPress, WooCommerce, PHP, स्थिर HTML या Node। आपका docs सबडोमेन स्थिर HTML हो सकता है जबकि रूट WordPress चलाता है, उनके बीच बिना किसी समझौते के।

इसका अपना डेटाबेस और ऑब्जेक्ट कैश

प्रत्येक साइट के लिए एक MariaDB डेटाबेस, LiteSpeed LSCache फुल-पेज कैशिंग और प्रति-साइट Redis या Memcached ऑब्जेक्ट कैश। मूल साइट के साथ कुछ भी साझा नहीं किया जाता है, इसलिए कोई भारी सबडोमेन मूल साइट के कैश को हटा नहीं सकता है या उसके प्रश्नों में भीड़ नहीं लगा सकता है।

इसका अपना आइसोलेशन केज

CloudLinux LVE प्रत्येक साइट के लिए CPU, RAM, IO, IOPS और प्रविष्टि प्रक्रियाओं (entry processes) को सीमित करता है, CageFS प्रत्येक साइट को उसका स्वयं का फ़ाइल सिस्टम दृश्य प्रदान करता है, और MySQL Governor प्रत्येक साइट के डेटाबेस लोड को नियंत्रित करता है। एक अनियंत्रित सबडोमेन अपने स्वयं के पिंजरे के भीतर ही सीमित रहता है।

इसके अपने बैकअप और पुनर्स्थापना पथ

प्रत्येक साइट के लिए एक-क्लिक पुनर्स्थापना के साथ 30 दिनों तक रखे जाने वाले दैनिक बैकअप। आप मुख्य साइट या उसकी किसी भी सहयोगी साइट को प्रभावित किए बिना सबडोमेन को कल की स्थिति में वापस ला सकते हैं।

DNS रिकॉर्ड जिनका आप वास्तव में नियंत्रण करते हैं

सबडोमेन होस्टिंग की समस्या होने से पहले एक DNS समस्या हैं, इसलिए DNS परत को दो फ़ील्ड वाले फ़ॉर्म के पीछे छिपाने के बजाय ठीक से प्रदर्शित किया जाता है।

आपके द्वारा होस्ट किए जाने वाले प्रत्येक पंजीकरण योग्य डोमेन को हमारे DNS ड्राइवर सीम के माध्यम से प्रबंधित एक DNS ज़ोन प्राप्त होता है। आपको उन अपेक्षित रिकॉर्ड प्रकारों में रिकॉर्ड CRUD की सुविधा मिलती है, इसलिए app, shop, docs, mail या वाइल्डकार्ड होस्ट जोड़ना केवल एक रिकॉर्ड संपादन है, कोई सपोर्ट टिकट नहीं। ज़ोन की स्थिति को प्रदाता के साथ अप्रतिवर्ती (idempotent) रूप से समेटा जाता है, जिसका अर्थ है कि आंशिक रूप से लागू किया गया परिवर्तन या पुनः प्रयास किया गया संपादन आपके ज़ोन को किसी अस्पष्ट मध्य स्थिति में छोड़ने के बजाय आपके द्वारा अनुरोधित स्थिति में ला देता है।

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

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

प्रत्येक होस्ट पर प्रमाणपत्र, डिलीवरी और गति

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

वाइल्डकार्ड सहित निःशुल्क SSL

Let's Encrypt प्रमाणपत्र स्वचालित रूप से जारी और नवीनीकृत किए जाते हैं। प्रत्येक सबडोमेन को एक साथ कवर करने के लिए वाइल्डकार्ड प्रमाणपत्र का उपयोग करें, जहाँ आप उन्हें अलग रखना चाहते हैं वहाँ प्रति-होस्ट प्रमाणपत्रों का उपयोग करें, या अपना स्वयं का कस्टम प्रमाणपत्र अपलोड करें।

LiteSpeed और HTTP/3

प्रत्येक साइट HTTP/3 सक्षम के साथ LiteSpeed द्वारा संचालित होती है, जिससे एक सबडोमेन को द्वितीय श्रेणी के वर्चुअल होस्ट के बजाय रूट डोमेन के समान ही कनेक्शन-स्तरीय प्रदर्शन मिलता है।

पूर्ण-पृष्ठ और ऑब्जेक्ट कैशिंग

LSCache फुल-पेज कैशिंग और प्रति-साइट Redis ऑब्जेक्ट कैश, डैशबोर्ड से या WordPress के भीतर से समन्वित पर्ज के साथ। पैरेंट को पर्ज करने से आपके सबडोमेन का कैश नहीं हटता है।

आपकी पसंद का CDN खाता

हमारे CDN और Cloudflare खाता पूल के माध्यम से डिप्लॉय करें या अपने स्वयं के खातों को कनेक्ट करें और चुनें कि कोई दिया गया साइट किस खाते में डिप्लॉय होगा। डिलीवरी एक ऐसा निर्णय है जो आप लेते हैं, ऐसा नहीं जो हम आपके लिए लेते हैं।

स्टेजिंग सबडोमेन और पुश-टू-लाइव

सबडोमेन चाहने का सबसे आम कारण प्रयोग करने और बिना किसी डर के बदलाव करने के लिए एक सुरक्षित जगह पाना है। यह विकल्प Mainstream प्लान में इन-बिल्ट है और बिना किसी पाबंदी के उपलब्ध है।

स्टेजिंग पर क्लोन करना एक लाइव साइट की फ़ाइलों और डेटाबेस को अक्षुण्ण रखते हुए, प्रोडक्शन के समान स्टैक और ब्लूप्रिंट संस्करण पर, स्टेजिंग सबडोमेन पर उसकी एक अलग प्रतिलिपि बनाता है। आप टूल के पूरे सेट के साथ प्रतिलिपि पर काम करते हैं: जेल किया गया SSH और SFTP, wp-cli, ब्राउज़र-आधारित VS Code एडिटर, phpMyAdmin या Adminer, प्रति-साइट cron और परिवेश चर।

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

  • फ़ाइलों और डेटाबेस सहित, एक अलग स्टेजिंग सबडोमेन पर एक-क्लिक में क्लोन करें
  • उत्पादन जैसा ही स्टैक और ब्लूप्रिंट संस्करण, इसलिए जो आप परीक्षण करते हैं वही आप परिनियोजित करते हैं
  • खोजें-बदलें के साथ डेटाबेस-सचेत पुश-टू-लाइव, फ़ाइलें या डेटाबेस या दोनों
  • क्षतिपूर्ति के साथ टिकाऊ, पुनः प्रयास योग्य कार्यप्रवाह, ताकि क्लोनिंग के बीच में होने वाली विफलता किसी साइट को अधर में न छोड़े
  • स्टेजिंग कॉपी पर पूर्ण डेवलपर एक्सेस: SSH, SFTP, wp-cli, वेब IDE, डेटाबेस टूल्स

जब सबडोमेन गलत विकल्प हो

हम आपको कुछ ऐसा बेचने के बजाय यह बात पहले ही बता देना बेहतर समझते हैं, जो आपके प्रयासों को नुकसान पहुँचाए।

एक ही ब्रांड की संरचना के लिए सबडोमेन सही समाधान हैं: एक ऐप, एक स्टोर, एक दस्तावेज़ साइट, एक ग्राहक पोर्टल, प्रति-ग्राहक स्टेजिंग परिवेश। वे एक निजी ब्लॉग नेटवर्क (PBN) के लिए गलत समाधान हैं। प्रत्येक सबडोमेन एक ही पंजीकरण योग्य डोमेन साझा करता है, इसलिए जो कोई भी उनमें से किसी एक को हल (resolve) करता है, वह ठीक से जान जाता है कि बाकी का मालिक कौन है। वाइल्डकार्ड प्रमाणपत्र के तहत वे एक प्रमाणपत्र भी साझा करते हैं, और प्रमाणपत्र जारी करना सार्वजनिक Certificate Transparency लॉग में प्रकाशित होता है, जिससे साझा डोमेन के तहत होस्ट किसी भी व्यक्ति द्वारा गिने जा सकते हैं जो देखना चाहता है। यह सार्वजनिक वेब PKI और DNS की एक विशेषता है, हमारे प्लेटफ़ॉर्म की नहीं, और कोई भी होस्टिंग कॉन्फ़िगरेशन इसे बदल नहीं सकता है।

इसलिए सबडोमेन हमारी Mainstream और Agency लाइनों में आते हैं, Footprint-Free में नहीं। यदि आपकी आवश्यकता यह है कि साइटें एक-दूसरे से लिंक करने योग्य नहीं होनी चाहिए, तो आपको footprint-free उत्पाद लाइन पर अलग पंजीकरण योग्य डोमेन की आवश्यकता होगी, जहां CDN और DNS खाता पूल, फ़ुटप्रिंट प्रबंधन और स्थिर-HTML डिलीवरी विशेष रूप से उस पैटर्न को तोड़ने के लिए मौजूद हैं। दोनों एक ही इंजन और एक ही डैशबोर्ड पर चलते हैं, इसलिए सही विकल्प चुनने से आपकी सुविधा में कोई कमी नहीं आती है।

पोर्टफोलियो के सभी सबडोमेन

एजेंसियां और पुनर्विक्रेता बड़े पैमाने पर सबडोमेन का उपयोग करते हैं: प्रति ग्राहक एक स्टेजिंग होस्ट, प्रति प्रोजेक्ट एक पूर्वावलोकन होस्ट, प्रति खाता एक पोर्टल। यह प्लेटफ़ॉर्म इसी तरह की कार्यप्रणाली के लिए बनाया गया है।

पदानुक्रमित किरायेदारी

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

थोक संचालन

प्रत्येक साइट के लिए प्रक्रिया दोहराने के बजाय एक ही क्रिया में कई साइटों को परिनियोजित, अद्यतन और प्रबंधित करें।

API, CLI और MCP एक्सेस

डैशबोर्ड की प्रत्येक चीज़ सार्वजनिक API में उपलब्ध है, जिसे OpenAPI विनिर्देश से जनरेट किया गया है। संगठन-स्तरीय API कुंजी, CLI, Terraform या हमारे MCP सर्वर के माध्यम से AI टूल का उपयोग करके सबडोमेन निर्माण का संचालन करें।

ऑडिट-लॉग किया गया व्यवस्थापन

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

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

क्या कोई सबडोमेन मेरे प्लान की साइट सीमा में गिना जाता है?

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

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

हाँ, और वे वास्तव में स्वतंत्र हैं। प्रत्येक सबडोमेन का अपना साइट रिकॉर्ड और अपना ब्लूप्रिंट होता है, इसलिए स्टैक का मेल खाना आवश्यक नहीं है: मुख्य डोमेन पर WordPress, shop पर WooCommerce, app पर एक Node.js ऐप और docs पर एक स्टैटिक साइट यहाँ एक विशेष स्थिति के बजाय एक सामान्य सेटअप है। वे विभिन्न मशीनों पर स्थित हो सकते हैं, विभिन्न रनटाइम और विभिन्न PHP या Node संस्करण चला सकते हैं, और अपने स्वयं के शेड्यूल पर डिप्लॉय, स्टेज, बैकअप और रोलबैक किए जा सकते हैं। एक डोमेन नाम साझा करने के अलावा एक का प्रभाव दूसरे पर बिल्कुल नहीं पड़ता है।

क्या सबडोमेन को अपना स्वयं का SSL प्रमाणपत्र मिलता है?

वे दोनों तरह से स्वचालित रूप से कवर होते हैं। आप एक वाइल्डकार्ड प्रमाणपत्र जारी कर सकते हैं जो डोमेन के अंतर्गत प्रत्येक होस्ट को एक साथ कवर करता है, या जहाँ आप उन्हें अलग रखना चाहते हैं वहाँ प्रति-होस्ट प्रमाणपत्र जारी कर सकते हैं। Let's Encrypt प्रमाणपत्र निःशुल्क हैं, स्वचालित रूप से जारी और नवीनीकृत किए जाते हैं, और यदि आपके पास कोई कस्टम प्रमाणपत्र है तो आप इसके बजाय उसे अपलोड कर सकते हैं।

क्या मैं PBN बनाने के लिए सबडोमेन का उपयोग कर सकता हूँ?

हम इसके विरुद्ध सलाह देंगे, और हम इसे इस तरह नहीं बेचेंगे। प्रत्येक सबडोमेन एक ही रजिस्ट्रेबल डोमेन साझा करता है, और वाइल्डकार्ड प्रमाणपत्र के तहत एक साझा प्रमाणपत्र साझा करता है जिसका जारी होना सार्वजनिक Certificate Transparency लॉग में दिखाई देता है, इसलिए कोई भी देखने वाला होस्ट्स को एक-दूसरे से जोड़ सकता है। ऐसे काम के लिए जहाँ साइटों का आपस में जुड़ा होना बिल्कुल नहीं चाहिए, हमारी Footprint-Free लाइन पर अलग-अलग रजिस्ट्रेबल डोमेन का उपयोग करें, जिसे विशेष रूप से CDN और DNS खाता पूलों, प्रबंधित फ़ुटप्रिंट्स और स्टेटिक-HTML डिलीवरी के साथ इसी उद्देश्य के लिए तैयार किया गया है।

क्या एक सबडोमेन की समस्या दूसरों को प्रभावित कर सकती है?

प्लेटफ़ॉर्म को इसे फैलने देने के बजाय सीमित रखने के लिए बनाया गया है। CloudLinux LVE प्रत्येक साइट के CPU, मेमोरी और IO को उसके अपने अलग वातावरण में सीमित करता है, CageFS प्रत्येक साइट को एक पृथक फ़ाइल सिस्टम दृश्य प्रदान करता है ताकि उल्लंघन सीमित रहे, और MySQL Governor प्रति-साइट डेटाबेस लोड को नियंत्रित करता है ताकि एक साइट के भारी प्रश्न सर्वर को धीमा न करें। मैलवेयर स्कैनिंग, एक सक्रिय वेब एप्लिकेशन फ़ायरवॉल और प्रति-साइट अपरिवर्तनीय बैकअप इसका समर्थन करते हैं। नियंत्रण रखना ही डिज़ाइन का लक्ष्य है; कोई भी होस्ट यह वादा नहीं कर सकता कि सुरक्षा उल्लंघन असंभव है।

क्या मैं अपने DNS को कहीं और रखते हुए एक सबडोमेन को आपकी ओर इंगित कर सकता हूँ?

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

स्टेजिंग सबडोमेन किसी सामान्य सबडोमेन से किस प्रकार भिन्न होता है?

केवल इस बात में कि इसे कैसे बनाया जाता है। क्लोन टू स्टेजिंग (Clone to staging) प्रोडक्शन के समान स्टैक और ब्लूप्रिंट संस्करण चलाने वाले स्टेजिंग सबडोमेन पर फ़ाइलों और डेटाबेस सहित लाइव साइट की एक अलग प्रतिलिपि बनाता है। जब आप संतुष्ट हों, तो पुश-टू-लाइव (push-to-live) डेटाबेस-सचेत खोज-प्रतिस्थापन के साथ इसे वापस सिंक करता है। बाकी सब कुछ, पृथक्करण, SSL, कैशिंग, बैकअप और डेवलपर एक्सेस, किसी भी अन्य साइट के समान है।

यदि मैं छोड़ता हूँ तो मेरे सबडोमेन का क्या होगा?

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

प्रत्येक सबडोमेन को एक ऐसी साइट दें जो रखने लायक हो

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

मुफ़्त शुरू करें