तुमच्या साइट्स तुम्ही ठरवलेल्या ठिकाणीच चालतात

होय. प्रदेश हा प्लेसमेंट इंजिनसाठीचा एक इनपुट आहे, स्वतंत्रपणे हाताळली जाणारी विनंती नाही. एखादा प्रदेश पिन करा आणि केवळ त्या प्रदेशासाठी टॅग केलेले फ्लीट वर्कर्सच साइट प्राप्त करण्यास पात्र असतील; निवडलेला प्रदेश नंतर साइट रेकॉर्डवर संग्रहित केला जातो जेणेकरून तो कुठे चालतो हे आपण नेहमी पुन्हा पाहू शकता. ते सेट न करता तसेच ठेवा आणि साइट ज्या वर्करवर जाते त्याचा प्रदेश वारशाने घेईल.

हे होस्टिंग लाइनवर अवलंबून असते, कारण प्रत्येक लाइन तिच्यासाठी तयार केलेल्या क्षमतेवर चालते. ऑर्डर फॉर्म आणि प्रत्येक होस्टिंग पेज तुम्ही आज निवडू शकता अशा शहरांची यादी दाखवते, जी प्लेसमेंट इंजिनवरून थेट वाचली जाते, त्यामुळे हे उत्तर कधीही कालबाह्य होत नाही. काटेकोर EU निवासीयतेसाठी, युरोपियन युनियनमधील डेटा सेंटर निवडा; जिथे खरेदीसाठी प्रमाणित मूलभूत प्लॅटफॉर्म आवश्यक असतो, तिथे आम्ही त्या आवश्यकता पूर्ण करणाऱ्या क्षमतेवर जागा देऊ शकतो. प्रत्येक स्थानामागील पुरवठादार ही आमची स्वतःची व्यावसायिक व्यवस्था आहे — तुम्ही स्थान निवडता, विक्रेता नाही.

नाही — Zinn Digital® कडे आज स्वतःची कोणतीही अनुपालन प्रमाणपत्रे नाहीत, आणि आम्ही अन्यथा सुचवणार नाही. खरेदीदाराच्या खरेदी प्रक्रियेमुळे तुमच्या साइट्सच्या मागे प्रमाणित प्लॅटफॉर्म असणे ही अनिवार्य आवश्यकता बनते, तिथे आम्ही फक्त तुमचे वर्कलोड अशी प्रमाणपत्रे असलेल्या मूळ प्लॅटफॉर्मवर ठेवू शकतो. स्वतंत्रपणे, प्लॅटफॉर्मची स्वतःची नियंत्रणे वास्तविक आणि तपासणीयोग्य आहेत: प्रति-साइट अलगीकरण, प्रत्येक भाडेकरू-व्याप्तीच्या टेबलवर पंक्ती-स्तरीय सुरक्षितता, Vault मध्ये ठेवलेले रहस्य, संपूर्ण TLS, आणि विशेषाधिकारप्राप्त क्रियांचे ऑडिट लॉगिंग.

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

आम्ही लेटन्सीचे निकष प्रकाशित करत नाही आणि कोणत्याही विशिष्ट आकडेवारीचे वचन देणार नाही. आम्ही ज्याची माहिती देऊ शकतो ती म्हणजे ही रचना: Cloudflare प्रत्येक साइटच्या अग्रभागी कार्य करते जेणेकरून कॅश करण्यायोग्य प्रतिसाद अभ्यागताच्या जवळील एज स्थानावरून दिले जातात, LSCache PHP किंवा डेटाबेसशी संपर्क न साधता वर्करकडून पूर्ण पृष्ठे प्रदान करते, आणि प्रत्येक साइटसाठी असलेला Redis ऑब्जेक्ट कॅश पुनरावृत्ती होणाऱ्या क्वेरी सामावून घेतो. बहुतांश कन्टेन्ट साइट्ससाठी या संयोजनाचा अर्थ असा होतो की मूळ प्रदेश कॅश कॉन्फिगरेशनपेक्षा फारच कमी महत्त्वाचा ठरतो. आपले प्रेक्षक एकाच खंडात केंद्रित असल्यास, तरीही मूळ सर्व्हर तेथेच ठेवा.

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

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

होय. चाचणी कालावधी 14 दिवसांचा आहे आणि यासाठी कार्डची आवश्यकता नाही. यामध्ये पाच साइट्सपर्यंतचे Footprint-Free Hosting समाविष्ट आहे, जे तुमचे प्रोडक्शन पोर्टफोलिओ कुठे असावे हे ठरवण्यापूर्वी डिप्लॉयमेंट्स, प्लेसमेंट आणि कॅशे लेयर्स कसे कार्य करतात हे पाहण्यासाठी पुरेसे आहे.