प्रत्येक साइटनुसार पृथक्करण

प्रत्येक साइट स्वतःच्या स्वतंत्र पिंजऱ्यात, ज्यामुळे एक वाईट शेजारी फक्त एकच वाईट शेजारी राहतो.

आयझोलेशन हा एखाद्या घटनेत आणि पूर्ण आउटेजमध्ये फरक करतो. आम्ही होस्ट करत असलेली प्रत्येक साइट तिच्या स्वतःच्या CPU, RAM, IO आणि प्रोसेस मर्यादा, तिचे स्वतःचे CageFS फाइलसिस्टम व्ह्यू, तिची स्वतःची PHP आवृत्ती आणि तिच्या स्वतःच्या डेटाबेस थ्रॉटलसह कर्नल-पातळीवरील CloudLinux LVE केजमध्ये चालते. ज्या साइटवर हल्ला झाला आहे, जी तडजोड झाली आहे किंवा जी केवळ एक अत्यंत जड क्वेरी चालवत आहे, ती जिथे आहे तिथेच नियंत्रित केली जाते — आणि आयझोलेशनची आधारभूत सुविधा प्रत्येक प्लॅनमध्ये समाविष्ट आहे, ती तुम्हाला अपग्रेड म्हणून विकली जात नाही. उपलब्धता: प्रति-साइट डेटाबेस थ्रॉटलिंग आणि प्रति-साइट संसाधन आकडेवारी सक्रिय विकासामध्ये आहे आणि अद्याप उपलब्ध नाही. येथे वर्णन केलेले इतर सर्व काही आज प्रत्यक्ष उपलब्ध आहे.

विनामूल्य सुरू करा दर पहा

७,००,०००+जगभरात होस्ट केलेल्या साइट्स
प्रति-साइटसीपीयू, रॅम, आयओ, आयओपीएस आणि प्रक्रिया मर्यादा
99.99%अपटाइम हमी
समाविष्टप्रत्येक प्लॅनवर आयसोलेशन बेसलाइन

कॉन्फिगरेशन फाइलमध्ये नाही, तर कर्नल स्तरावर अलगीकरण

वर्कर फ्लीट CloudLinux OS चालवते, जे मल्टी-टेनन्सीला कर्नलमध्ये ढकलते. प्रत्येक साइटला एक लाइटवेट व्हर्च्युअल एन्व्हायर्नमेंट (LVE) मिळते, जे केवळ शिष्टाचाराऐवजी एक कठोर सीमा असते. एका साइटने तिच्या पिंजऱ्यात केलेल्या कोणत्याही गोष्टीचा खर्च दुसऱ्या कोणाच्या बजेटमधून केला जाऊ शकत नाही.

प्रति-साइट कठोर संसाधन मर्यादा

LVE प्रत्येक साइटसाठी स्वतंत्रपणे CPU, RAM, IO, IOPS, प्रक्रिया आणि एंट्री-प्रक्रियांवर मर्यादा घालते. जेव्हा एखादी साइट तिच्या कमाल मर्यादेपेक्षा जास्त वापर करते, तेव्हा तिला तिच्या स्वतःच्या वेगळ्या कक्षेत मर्यादित केले जाते — त्रुटी त्या साइटच्या नावावर नोंदवली जाते आणि तिच्या शेजारील साइट्सवर कोणताही परिणाम न होता त्या सुरळीत सुरू राहतात.

अनियंत्रित प्रक्रियांचा पाठलाग केला जात नाही, तर त्यांना नियंत्रित केले जाते

लूपमध्ये अडकलेले प्लगइन, चुकीच्या पद्धतीने लिहिलेले क्रॉन जॉब किंवा एंडपॉइंटवर सतत मारा करणारे क्रॉलर प्रथम साइटच्या स्वतःच्या प्रोसेस आणि एन्ट्री-प्रोसेस मर्यादांवर आदळते. केवळ एक साइट संपूर्ण मशीनचे स्रोत संपवू शकत नाही.

हल्ल्याचा ट्रॅफिक प्रति साइट मर्यादित आहे

एंट्री-प्रोसेस प्रति केज मर्यादित असल्यामुळे, एका साइटला लक्ष्य करून आलेला ट्रॅफिकचा लोट होस्टवर अमर्याद कामाचा भार निर्माण करू शकत नाही. LiteSpeed कनेक्शन आणि विनंती थ्रॉटलिंग तसेच Imunify360 नेटवर्क फायरवॉल याच्या पुढे कार्यरत असतात, ज्यामुळे हा हल्ला केवळ लक्ष्यित साइटपुरताच मर्यादित राहतो.

संसाधनातील त्रुटी हे आश्चर्य नव्हे, तर संकेत बनतात

प्रत्येक LVE त्रुटी प्रत्येक साइटनुसार नोंदवली जाते आणि प्लॅटफॉर्मच्या धोरण इंजिनमध्ये प्रवाहित होते, जे आपोआप मर्यादा कठोर किंवा शिथिल करू शकते. साइट का आणि केव्हा थ्रॉटल केली गेली हे आपण पाहू शकता — क्रमिक, पूर्ववत करण्यायोग्य आणि नोंदवलेले.

तुमचे स्वतःचे फाइल सिस्टम दृश्य

संसाधन अलगीकरण साइटला सिस्टीमवर भार टाकण्यापासून थांबवते. फाइलसिस्टम अलगीकरण तिला नको त्या माहितीत डोकावण्यापासून रोखते. CageFS प्रत्येक वापरकर्त्याला मशीनचे खाजगी आणि मर्यादित दृश्य देते.

CageFS अंतर्गत, भाडेकरूला फक्त त्याच्या स्वतःच्या फाइल्स आणि सिस्टम बायनरीजचा किमान, निर्जंतुक केलेला संच दिसतो — आणि इतर भाडेकरू, इतर भाडेकरूंच्या साइट्स किंवा संवेदनशील सिस्टम फाइल्स पाहता येत नाहीत. शेअर-होस्टिंगमधील नेहमीची अपयशाची स्थिती, जिथे तडजोड केलेले एक खाते सर्व्हरवरील इतर प्रत्येक खात्याची माहिती वाचण्याची स्थिती बनते, ती कर्नल स्तरावरच बंद केली जाते.

जेव्हा काहीतरी चूक होते, तेव्हा या गोष्टीला सर्वात जास्त महत्त्व असते. जुनाट प्लगइन, चोरी झालेली क्रेडेन्शियल्स किंवा असुरक्षित थीममुळे एखादी साइट धोक्यात आली, तर CageFS तिच्या नुकसानीची व्याप्ती केवळ त्या एका केजपुरती मर्यादित ठेवते. आमच्या सुरक्षिततेच्या तपशिलातील शब्दरचना जाणीवपूर्वक ठरवली आहे: CageFS उल्लंघनांना रोखते. मर्यादित ठेवणे हा प्रामाणिक दावा आहे, आणि हीच गोष्ट ठरवते की ती घटना एका साइटपुरती मर्यादित स्वच्छता आहे की संपूर्ण सिस्टीमची.

बॅकअप याच सीमारेषेला अधिक बळकट करतात. प्रत्येक साइटचे बॅकअप अपरिवर्तनीय, ऑफसाइट आणि कार्यरत ताफ्यापासून वेगळे केलेले असतात, तसेच त्यांचे रिस्टोअर तपासलेले असतात; त्यामुळे एका साइटवर सर्वात वाईट तडजोड झाली तरीही, ती साइट ज्या मशीनवर चालत होती तिच्या स्थितीवर अवलंबून नसलेला एक स्वच्छ, स्वतंत्र पुनर्प्राप्ती मार्ग उपलब्ध असतो.

डेटाबेस देखील वेगळा ठेवला आहे — सामान्यत: येथेच होस्टिंग गोंगाटाचे ठरते

वेब-स्तरीय विलगीकरण ही केवळ अर्धी गोष्ट आहे. WordPress समूहावर, सर्व्हर मंद होण्याचे मुख्य कारण एका साइटची ट्रॅफिक नसून त्या साइटच्या क्वेरी असतात. हे स्पष्टपणे हाताळले जाते.

MySQL Governor

CloudLinux MySQL Governor प्रत्येक साइटनुसार डेटाबेस वापर मर्यादित करतो, ज्यामुळे एका साइटच्या हेवी क्वेरीज इतरांसाठी सर्व्हरचा वेग कमी करू शकत नाहीत. हे स्लोडाउन-विरोधी नियंत्रण आहे आणि गोंधळ घालणाऱ्या साइटला तिच्यावर मर्यादा घातली जात असल्याचे लक्षात आले किंवा नाही तरीही ते कार्यरत राहते.

WordPress वर्कलोडसाठी MariaDB

हा फ्लीट MariaDB (किंवा Percona) चालवतो, जो डीफॉल्टनुसार वारशाने मिळण्याऐवजी WordPress वर्कलोडसाठी निवडला गेला आहे, ज्यावर गव्हर्नर प्रति-भाडेकरू निष्पक्षता स्तर म्हणून कार्यरत आहे.

समोर Redis ऑब्जेक्ट कॅश

प्रत्येक साइटसाठी असलेला Redis ऑब्जेक्ट कॅश डेटाबेसपर्यंत पोहोचण्यापूर्वी वारंवार होणारे वाचन सामावून घेतो, ज्यामुळे Governor ला सुरुवातीलाच नियंत्रित करावा लागणारा ताण कमी होतो. कॅशिंग आणि आयसोलेशन एकाच प्रणालीप्रमाणे काम करतात.

प्रत्येक साइटनुसार PHP, अधिक सुरक्षित

CloudLinux alt-PHP प्रत्येक साइटला स्वतःची PHP व्हर्जन निवडक, स्वतःचे एक्स्टेंशन्स (imagick, gd, redis आणि इतर) आणि स्वतःच्या सुरक्षित सेटिंग्ज प्रदान करते — ज्यामध्ये LSAPI वर्कर्स त्या साइटच्या LVE मर्यादांशी बांधील असतात, ज्यामुळे PHP कॉनकरन्सी ही त्या पिंजऱ्यातून सुटका नसून त्याचाच एक भाग बनते.

अपयश हे श्रेणीबद्ध, पूर्ववत करण्यायोग्य आणि स्पष्ट केलेले आहे

समस्या किती दूर पसरते हे आयसोलेशन ठरवते. पुढे काय घडणार हे अंमलबजावणी ठरवते. आम्ही थेट ऑन/ऑफ सस्पेंड ऐवजी एका स्टेट मशीनचा वापर केला आहे, जे टिकाऊ वर्कफ्लोद्वारे चालवले जाते आणि LiteSpeed, LVE आणि Imunify द्वारे वर्करवर लागू केले जाते.

थ्रॉटल केले — अधिक कठोर LVE मर्यादा आणि दर मर्यादा, तरीही साइट अद्याप सुरू आहे आणि सेवा देत आहे. सामान्यतः हा संसाधनाचा गैरवापर किंवा सौम्य संकेत असतो आणि कारण दूर झाल्यावर ते आपोआप पूर्ववत होते.
प्रतिबंधित — साइट दृश्यमान असताना आउटबाउंड मेल, क्रॉन किंवा POST विनंत्या अक्षम केल्या जातात. संशयित तडजोड किंवा स्पॅम पाठवण्यासाठी वापरले जाते, आणि निराकरण केल्यावर आपोआप पूर्ववत होते.
निलंबित — साइट तुटलेल्या पृष्ठाऐवजी ब्रँडेड, कारण-विशिष्ट होल्डिंग पृष्ठाच्या (बिलिंग, देखभाल किंवा गैरवापर) मागे ऑफलाइन होते. पेमेंट केल्यावर, दुरुस्ती केल्यावर किंवा अपील केल्यावर ती पूर्ववत होते.
विलगीकरण केले — ऑफलाइन, फाइल्स लॉक केल्या आहेत, कोणतेही एक्झिक्युशन नाही, फॉरेन्सिक्ससाठी वेगळे केले आहे. पुष्टी झालेल्या मालवेअर किंवा फिशिंगसाठी राखीव, आणि ते केवळ साफसफाई आणि पुनरावलोकनानंतरच पूर्ववत होते; पुन्हा स्कॅन केल्यावर कोणतीही स्वयंचलित सुटका नाही.
प्रत्येक संक्रमणाची त्याच्या कारणासह, कर्त्यासह आणि पुराव्यासह ऑडिट-नोंद ठेवली जाते, त्याचे निराकरण कसे करावे याच्या सूचनांसह आपल्याला सूचित केले जाते आणि त्याविरुद्ध अपील केले जाऊ शकते. अंमलबजावणीची वेळ प्रत्येक उत्पादन श्रेणीनुसार कॉन्फिगर करण्यायोग्य आहे, त्यामुळे बिलिंग, गैरवापर आणि कायदेशीर बाबी या प्रत्येकाची त्यांच्या स्वतःच्या वेळेनुसार तीव्रता वाढते.

दोन्ही उत्पादन श्रेणींमध्ये समान पृथक्करण — आणि आपल्याला आवश्यकता भासल्यास अधिक शक्तिशाली स्तर

आयझोलेशन हे तीन स्तर वर गेल्यानंतर उपलब्ध होणारे प्लॅनचे वैशिष्ट्य नाही. हा मूळ पायाचाच एक गुणधर्म आहे, त्यामुळे तुम्ही एक WooCommerce स्टोअर चालवत असाल किंवा दोन हजार नेटवर्क साइट्स, हे अगदी सारखेच असते.

Footprint-Free होस्टिंग

बल्क आणि PBN नेटवर्क्स समान LVE आणि CageFS सबस्ट्रेटवर चालतात, सोबतच फूटप्रिंट-जागरूक CDN खाते रोटेशन आणि स्टॅटिक-HTML डिलिव्हरी असते. अलगीकरण हीच ती गोष्ट आहे जी घनता सुरक्षित करते: साइट्स नशीब सामायिक न करता फ्लीट सामायिक करतात.

Zinn® Managed WordPress

व्यवस्थापित WordPress, WooCommerce, PHP, स्टॅटिक आणि Node साइट्सना तेच वेगळे वातावरण (cages) आणि संपूर्ण स्व-सेवा मिळते — तुमची स्वतःची PHP आवृत्ती आणि विस्तार, Redis ऑब्जेक्ट कॅशे, स्टेजिंग आणि पुश-टू-लाइव्ह.

प्रीमियम पर्याय म्हणून प्रति-साइट कंटेनर

घनतेसाठी अनुकूलित केलेल्या डीफॉल्टपेक्षा अधिक मजबूत सीमारेषेची आवश्यकता असलेल्या वर्कलोड्ससाठी, प्रोव्हिजनिंग-ड्रायव्हर प्रकार म्हणून साइटनुसार पूर्ण कंटेनर विलगीकरण दिले जाते: तेच इंजिन, तेच कंट्रोल प्लेन, वेगळे प्लेसमेंट, उच्च ओव्हरहेडसह.

समाविष्ट, अतिरिक्त विक्री नाही

LVE आणि CageFS आयसोलेशन, प्रोॲक्टिव्ह WAF आणि मालवेअर स्कॅनिंग प्रत्येक ग्राहकासाठी समाविष्ट केले आहे, कारण संक्रमित किंवा अनियंत्रित झालेली साइट शेजारील साइट्सना आणि आमच्या IP च्या प्रतिष्ठेला धोका निर्माण करते. एका क्लिकवर मालवेअर क्लिनअप आणि प्रगत संरक्षण स्तर हे सशुल्क ॲड-ऑन्स आहेत — मूलभूत संरक्षण विनामूल्य आहे.

येथे अलगीकरण कधीही ऐच्छिक का नसते

होस्टिंगमधील व्यावसायिक मोह म्हणजे सुरक्षिततेची वेगवेगळ्या स्तरांमध्ये विक्री करणे: स्वस्त दरातील ग्राहकांना लवचिक मर्यादा असलेल्या सामायिक सर्व्हरवर ठेवणे आणि सुरक्षित मर्यादांची काळजी असलेल्या लोकांकडून अधिक शुल्क आकारणे. आम्ही असे करत नाही, कारण ज्या ग्राहकाने अलगीकरणासाठी पैसे दिले नाहीत, त्याच ग्राहकाची धोक्यात आलेली साइट इतरांसाठी समस्या बनते.

आम्ही जगभरातील ७,००,००० पेक्षा जास्त साइट्स अशा प्रणालीवर होस्ट करतो जिथे घनता हाच संपूर्ण आर्थिक प्रस्ताव आहे. त्याखालील अलगीकरण बिनशर्त असेल तरच हे शक्य होते. परस्पर अवलंबित्व न ठेवता अशा मोठ्या प्रमाणावर सेवा चालवण्यासाठी कर्नल-पातळीवरील पिंजरे, खाजगी फाइलसिस्टम दृश्य, प्रति-साइट डेटाबेस थ्रॉटलिंग आणि प्रति-साइट PHP ही किंमत मोजावी लागते — त्यामुळे तुम्ही तैनात केलेल्या पहिल्या साइटपासूनच, प्रत्येक योजनेवर, हे प्रत्येकासाठी सक्रिय असतात.

याचा परिणाम म्हणजे इतरांच्या कठीण दिवसांमध्येही अपेक्षेनुसार कार्य करणारे व्यासपीठ. यामागे 99.99% अपटाइम हमी, तपासलेल्या पुनर्प्राप्तीसह प्रति-साइट अपरिवर्तनीय ऑफसाइट बॅकअप आणि आपल्या साइट्सवर घेतलेल्या प्रत्येक अंमलबजावणी कारवाईचा संपूर्ण ऑडिट ट्रेल आहे.

नेहमी विचारले जाणारे प्रश्न

इतर ग्राहकाच्या साइटमुळे माझी साइट संथ होऊ शकते का?

ते रोखण्यासाठीच आयसोलेशनची रचना विशेषतः केली गेली आहे. LVE प्रत्येक साइटनुसार CPU, RAM, IO, IOPS आणि प्रक्रिया मर्यादित करते, MySQL Governor प्रत्येक साइटनुसार डेटाबेसचा वापर नियंत्रित करते आणि LSAPI वर्कर्स साइटच्या स्वतःच्या केजद्वारे मर्यादित असतात — त्यामुळे शेजारच्या साइटवरील ट्रॅफिकमधील वाढ किंवा हेवी क्वेरी लोड हा त्यांच्या मर्यादेनुसार नियंत्रित केला जातो, तुमच्या मर्यादेनुसार नाही. प्रत्येक त्रुटी साइटनुसार नोंदवली जाते आणि पॉलिसी इंजिन गोंधळ निर्माण करणाऱ्या साइटच्या मर्यादा आपोआप कठोर करू शकते.

त्याच सर्व्हरवरील एखादी साइट हॅक झाल्यास, माझी साइट धोक्यात येईल का?

प्रामाणिक उत्तर हे हमी देण्यापेक्षा प्रतिबंध घालणे हे आहे. CageFS प्रत्येक भाडेकरूला (tenant) एक स्वतंत्र फाइलसिस्टम व्ह्यू देते — बाधित भाडेकरू इतर भाडेकरूंना, त्यांच्या साइट्सना किंवा संवेदनशील सिस्टीम फाइल्सना पाहू शकत नाही — आणि मालवेअर किंवा फिशिंगची पुष्टी झालेली केस त्या साइटला क्वारंटाइनमध्ये हलवते: ऑफलाइन, फाइल्स लॉक, एक्झिक्युशन नाही, फॉरेन्सिक्ससाठी वेगळे केलेले. हेच विनाशाची व्याप्ती मर्यादित करते. यासोबतच आम्ही प्रत्येक साइटवर मालवेअर स्कॅनिंग आणि प्रोॲक्टिव्ह WAF चालवतो, तसेच चाचणी केलेल्या रिस्टोअर्ससह प्रति-साइट अपरिवर्तनीय ऑफसाइट बॅकअप चालवतो, ज्यामुळे पुनर्प्राप्ती कधीही संबंधित मशीनच्या स्थितीवर अवलंबून नसते.

आयसोलेशन समाविष्ट आहे की त्यासाठी अतिरिक्त शुल्क आकारले जाते?

हे प्रत्येक प्लॅनमध्ये समाविष्ट आहे. संसर्ग झालेली किंवा अनियंत्रित झालेली साइट शेजारील साइट्सना आणि आमच्या IP च्या प्रतिष्ठेला धोका निर्माण करते, त्यामुळे LVE आणि CageFS आयसोलेशन, सक्रिय WAF आणि मालवेअर स्कॅनिंग हे प्रत्येक ग्राहकासाठी मूलभूत आहे — आम्ही ते पर्यायी ठेवू शकत नाही. ॲड-ऑन म्हणून जे विकले जाते ते म्हणजे एका क्लिकवर मालवेअर साफ करणे आणि त्याचे निवारण, तसेच वर्धित WAF नियम, प्राधान्य स्कॅनिंग, बॉट व्यवस्थापन आणि उच्च DDoS स्तर यासारखे प्रगत संरक्षण स्तर.

माझ्या साइटने तिच्या संसाधनांची मर्यादा ओलांडल्यास काय होते?

ते बंद करण्याऐवजी त्याच्या स्वतःच्या मर्यादेत थ्रॉटल (नियंत्रित) केले जाते. थ्रॉटल म्हणजे साइट चालू असताना आणि सेवा देत असताना कडक LVE मर्यादा आणि दर मर्यादा लागू करणे, आणि कारण दूर झाल्यावर ते आपोआप पूर्ववत होते. आपल्याला कारणासह सूचित केले जाते, बदलाची त्याच्या पुराव्यासह नोंद ठेवली जाते आणि यावर अपील करता येते. जर हा लोड त्रुटी नसून वास्तविक वाढ असेल, तर त्याचे उत्तर कायमस्वरूपी थ्रॉटल नसून मोठी योजना आहे.

निलंबित केलेली साइट फक्त रिक्त दिसते का?

नाही — निलंबित केलेली साइट ब्रँडेड, कारण-विशिष्ट होल्डिंग पृष्ठ (बिलिंग, देखभाल किंवा गैरवापर) दाखवते, जेणेकरून ती बिघडलेली वाटण्याऐवजी जाणीवपूर्वक केलेली वाटते. पेमेंट केल्यावर, निराकरण केल्यावर किंवा अपील केल्यावर निलंबन पूर्ववत केले जाते. क्वारंटाइन अधिक कठोर असते आणि वेगळ्या पद्धतीने कार्य करते: ते केवळ साफसफाई आणि पुनरावलोकनानंतरच पूर्ववत केले जाते, कधीही आपोआप नाही.

मी माझी स्वतःची PHP आवृत्ती आणि विस्तार निवडू शकतो का?

Zinn® Managed WordPress वर, होय — CloudLinux alt-PHP प्रत्येक साइटला तिची स्वतःची PHP आवृत्ती निवडक, imagick, gd आणि redis सारखे स्वतःचे विस्तार आणि तिची स्वतःची कडक केलेली सेटिंग्ज प्रदान करते, जे सर्व त्या साइटच्या LVE मर्यादांनी मर्यादित असतात. Footprint-Free होस्टिंग हेतुपुरस्सर अधिक प्रमाणित, लॉक-डाउन प्रति-साइट कॉन्फिगरेशन चालवते, कारण कॉन्फिगरेशनची विविधता स्वतःच एक फूटप्रिंट (footprint) असते.

शेअर्ड-कर्नेल मॉडेलपेक्षा अधिक मजबूत पृथक्करण पर्याय उपलब्ध आहे का?

होय. दोन्ही उत्पादन श्रेणींमध्ये CloudLinux LVE आणि CageFS हे घनता-अनुकूलित डीफॉल्ट आहे. ज्या वर्कलोड्सना अधिक कठोर सीमेची आवश्यकता असते, त्यांच्यासाठी प्रोव्हिजनिंग-ड्रायव्हर व्हेरिएंट म्हणून प्रति-साइट पूर्ण कंटेनर अलगीकरण ऑफर केले जाते — मजबूत पृथक्करणासाठी ओव्हरहेडचा व्यापार करणारे, वेगवेगळ्या प्लेसमेंटसह समान इंजिन आणि नियंत्रण प्रतल.

बांधिलकी पत्करण्यापूर्वी मी याचा वापर करून पाहू शकतो का?

होय. Footprint-Free होस्टिंग कार्डशिवाय 14-दिवसांच्या चाचणीसह सुरू होते ज्यामध्ये पाच साइट्सपर्यंत समावेश आहे — कोणतेही पेमेंट तपशील नाहीत, कोणतीही बांधिलकी नाही. निर्णय घेण्यापूर्वी काही साइट्स उपयोजित करा, त्यावर काही लोड द्या आणि केजेस कसे कार्य करतात ते पहा.

तुमच्या स्वतःच्या लोडखाली केजेस कसे कार्य करतात ते पहा

Footprint-Free होस्टिंगवर कार्डशिवाय १४ दिवसांची विनामूल्य चाचणी सुरू करा — पाच वेबसाइट्सपर्यंत, पेमेंट तपशीलांची आवश्यकता नाही, कोणतेही बंधन नाही. पहिल्या डिप्लॉयपासूनच कर्नल-स्तरीय आयसोलेशन, सक्रिय WAF आणि मालवेअर स्कॅनिंग समाविष्ट आहेत.

विनामूल्य सुरू करा