टीमें और एक्सेस

अपनी टीम के प्रत्येक सदस्य को ठीक वही एक्सेस दें जिसकी उन्हें आवश्यकता है

चार ग्राहक भूमिकाएँ, उप-खाते जो आपके व्यवसाय की वास्तविक संरचना को दर्शाते हैं, प्रति-संगठन API कुंजियाँ, सिंगल साइन-ऑन और प्रत्येक विशेषाधिकार प्राप्त क्रिया के पीछे एक ऑडिट लॉग। यही एक्सेस मॉडल डैशबोर्ड, API, CLI, Terraform और हमारे MCP सर्वर पर काम करता है। उपलब्धता: Terraform प्रोवाइडर अभी सक्रिय विकास में है और अभी उपलब्ध नहीं है। यहाँ वर्णित बाकी सब कुछ आज लाइव है।

  • 650,000+दुनिया भर में होस्ट की गई साइटें
  • 4ग्राहक भूमिकाएँ, पहले से सेट और तैयार
  • 35दानेदार अनुमति कुंजियाँ
  • 14 दिनबिना कार्ड के निःशुल्क परीक्षण

चार भूमिकाएँ, जहाँ काम वास्तव में बँटता है

पहुँच कोई एक चालू/बंद स्विच नहीं है। प्रत्येक ग्राहक संगठन चार भूमिकाओं के साथ आता है, जिनमें से प्रत्येक दानेदार module.action अनुमतियों का एक निश्चित बंडल है — ताकि कोई वित्त संपर्क कभी सर्वर को न छुए और कोई डेवलपर कभी इनवॉइस न देखे।

मालिक

संगठन और उसके उप-खातों पर पूर्ण नियंत्रण: चाइल्ड संगठन बनाएं, सदस्यों को आमंत्रित करें और हटाएं, भूमिकाएं बदलें, API कुंजियों का प्रबंधन करें, साइटों को प्रावधानित, पुनरारंभ, निलंबित और हटाएं, चालान और भुगतान विधियों का प्रबंधन करें, और ऑडिट लॉग पढ़ें। दो चीजें जानबूझकर इससे बाहर रखी गई हैं — संगठन को बंद करना और रिफंड जारी करना स्टाफ के कार्य हैं, ग्राहक की भूमिका नहीं।

बिलिंग प्रबंधक

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

डेवलपर

बिना पैसों को छुए साइटों पर काम करें: साइटों को देखें और प्रावधान करें, सेवाओं को पुनः आरंभ करें, कैश साफ़ करें, API कुंजियों का प्रबंधन करें, और सहायता टिकटों को बढ़ाएं या उनका उत्तर दें। कोई बिलिंग दृश्य नहीं, कोई सदस्य प्रबंधन नहीं, कोई निलंबन नहीं और कोई विलोपन नहीं — विनाशकारी और व्यावसायिक कार्रवाइयां मालिक के पास रहती हैं।

केवल-पठन

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

सब-अकाउंट्स जो आपकी असली संरचना से मेल खाते हैं

टेनेंसी एक ट्री है, फ्लैट लिस्ट नहीं। एक रीसेलर ऑर्गनाइजेशन अपने क्लाइंट ऑर्गनाइजेशन के ऊपर होता है, और साइट्स उनके नीचे होती हैं। टीम का सदस्य एक मेंबरशिप है — एक यूजर, एक ऑर्गनाइजेशन, एक रोल — इसलिए वही मूल तत्व दो लोगों की टीम, सौ क्लाइंट खातों को मैनेज करने वाली एजेंसी और अपने ब्रांड के तहत सब-अकाउंट चलाने वाले रीसेलर को शक्ति देता है।

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

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

हर प्लेटफ़ॉर्म पर समान अनुमतियाँ

रोल्स केवल डैशबोर्ड तक सीमित सुविधा नहीं हैं। प्लेटफ़ॉर्म में प्रवेश करने का हर तरीका उन्हीं अनुमति कुंजियों पर आधारित होता है, इसलिए ऐसा कोई पिछला दरवाज़ा नहीं है जो आपके एक्सेस नियमों को छोड़ सके।

डैशबोर्ड

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

पब्लिक एपीआई और सीएलआई

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

Terraform प्रदाता

साइट्स, डोमेन, DNS, मेलबॉक्स और प्लान को इंफ्रास्ट्रक्चर-एज़-कोड के रूप में प्रबंधित करें और होस्टिंग प्रोविज़न करने के लिए terraform apply चलाएं — जो बाकी हर चीज़ की तरह समान स्कोप द्वारा नियंत्रित होता है।

MCP सर्वर

Claude Code, Cursor, ChatGPT, Claude Desktop या किसी भी MCP-capable टूल को कनेक्ट करें। टोकन किसी संगठन और उसकी RBAC अनुमतियों के दायरे में होते हैं, जिन्हें प्रति टूल निरस्त किया जा सकता है, विनाशकारी कार्रवाइयों पर पुष्टि, खर्च की सीमाएँ और एक पूर्ण ऑडिट ट्रेल के साथ।

कुंजी प्रबंधन

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

एक लॉगिन, मानकों पर आधारित, हर चीज़ के लिए

पहचान Keycloak पर आधारित है, इसलिए प्रमाणीकरण किसी होस्टिंग पैनल से जुड़े एक कस्टम लॉगिन फॉर्म के बजाय मानक OIDC और SAML है।

  • डिफ़ॉल्ट रूप से मैजिक-लिंक ईमेल लॉगिन, और जो लोग इसे पसंद करते हैं उनके लिए विकल्प के रूप में ईमेल और पासवर्ड की सुविधा।
  • फ़िशिंग-रोधी साइन-इन के लिए पासकीज़ और WebAuthn, साथ ही नीति के तहत सभी के लिए लागू TOTP दो-कारक प्रमाणीकरण।
  • Google, Microsoft, GitHub और अन्य पहचान प्रदाताओं के माध्यम से सामाजिक लॉगिन।
  • एंटरप्राइज़ और एजेंसी ग्राहकों के लिए SAML सिंगल साइन-ऑन, ताकि टीम का एक्सेस आपकी मौजूदा डायरेक्टरी के अनुसार हो।
  • डैशबोर्ड, एडमिन कंसोल, पब्लिक साइट, नॉलेज बेस और सपोर्ट टिकटों पर एक ही सेशन — पाँच बार नहीं, बस एक बार साइन इन करें।
  • हर साइनअप ईमेल को खाता बनाने से पहले सत्यापित किया जाता है, ताकि बाउंस होने वाले और अमान्य पते कभी भी आपकी टीम तक न पहुँच सकें।
  • चूँकि यह मानकों पर आधारित है, इसलिए पहचान प्रदाता (आइडेंटिटी प्रोवाइडर) को इसके चारों ओर की किसी भी चीज़ को फिर से डिज़ाइन किए बिना बदला जा सकता है — यही वह नो-लॉक-इन नियम है जिसे हम हर दूसरे वेंडर पर लागू करते हैं।

ऑडिटर को सौंपी जा सकने वाली जवाबदेही

हर विशेषाधिकार प्राप्त कार्रवाई एक केवल-जोड़ने योग्य (append-only) ऑडिट रिकॉर्ड लिखती है: किसने किया, उन्होंने क्या किया, किस पर किया, इसके समर्थन में साक्ष्य और मूल आईपी पता। यह लॉग केवल-जोड़ने योग्य है — इसमें इवेंट जोड़े जाते हैं, मौजूदा में बदलाव नहीं किया जाता — और प्रोडक्शन में इसे समय-आधारित खंडों में विभाजित (time-partitioned) किया जाता है ताकि आकार बढ़ने पर भी यह तेज़ बना रहे।

उस लॉग को पढ़ना अपने आप में एक अनुमति है। ओनर और रीड-ओनली मेंबर इसके हकदार हैं, ताकि खाते के लिए ज़िम्मेदार व्यक्ति और उसका ऑडिट करने वाला व्यक्ति दोनों ही ऐसा करने के लिए बढ़े हुए अधिकारों की आवश्यकता के बिना पूरा इतिहास देख सकें।

उसके इर्द-गिर्द बड़ी टीमें जिन नियंत्रणों की मांग करती हैं वे मौजूद हैं: सत्र नीतियां, वैकल्पिक प्रति-संगठन आईपी अनुमति सूचियां, और संवेदनशील कार्रवाइयों पर स्टेप-अप प्रमाणीकरण ताकि कुछ गंभीर करने के लिए केवल एक लाइव सत्र ही पर्याप्त न हो।

अनुमतियाँ आपके साथ कैसे बढ़ती हैं

अनुमति कैटलॉग डेटा है, हार्डकोडेड लॉजिक नहीं — यही कारण है कि इसे प्लेटफ़ॉर्म की पुनः-पाइपलाइनिंग के बिना बढ़ाया जा सकता है।

  • आज 35 बारीक मॉड्यूल.एक्शन (module.action) कुंजियाँ, जिनमें संगठन, सदस्य, API कुंजियाँ, साइट्स, बिलिंग, प्लान, फ्लीट, टिकट, ग्राहक, दुरुपयोग, अभियान, अनुवाद और ऑडिट शामिल हैं।
  • कैटलॉग को हर डिप्लॉयमेंट पर आइडम्पोटेंट तरीके से सीड किया जाता है, और यदि कोई रोल ऐसी अनुमति का संदर्भ देता है जो मौजूद नहीं है, तो वैलिडेशन ज़ोरदार तरीके से विफल हो जाता है — एक टाइपो चुपचाप कुछ भी अनुमति नहीं दे सकता है।
  • नए उत्पाद की क्षमताएं एंडपॉइंट के शिप होने से पहले अपनी अनुमति कुंजियों को कैटलॉग में जोड़ती हैं, ताकि किसी फ़ीचर के लाइव होने के बाद एक्सेस कंट्रोल को कभी भी बाद में न जोड़ा जाए।
  • एक ही सदस्यता को विशिष्ट साइटों या किसी विशिष्ट क्षेत्र तक सीमित करना एक नियोजित सुधार है, न कि ऐसा कुछ जिसे आप आज चालू कर सकें। वर्तमान तरीका उन साइटों को एक चाइल्ड ऑर्गनाइजेशन में रखना और उस व्यक्ति को वहां एक भूमिका देना है — जिससे आपको टेनेंसी ट्री का उपयोग करके वही अलगाव मिलता है।
  • API कुंजियाँ प्रति व्यक्ति के बजाय संगठन स्तर पर जारी की जाती हैं, इसलिए उन्हें इंटिग्रेशन के लिए सेवा क्रेडेंशियल के रूप में मानें और मानवीय पहुँच के लिए मेंबरशिप का उपयोग करें।

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

प्रत्येक भूमिका वास्तव में क्या कर सकती है?

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

क्या मैं किसी को केवल एक साइट का एक्सेस दे सकता हूँ?

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

क्या API कुंजियाँ व्यक्तिगत टीम के सदस्यों से जुड़ी होती हैं?

नहीं — API कुंजियाँ प्रत्येक संगठन के लिए जारी की जाती हैं, जिनमें समान RBAC अनुमतियों से जुड़ी ग्रेन्युलर स्कोप और अलग-अलग सैंडबॉक्स तथा लाइव मोड होते हैं। इन्हें इंटीग्रेशन, CI या Terraform के लिए सेवा क्रेडेंशियल के रूप में उपयोग करें, और लोगों के लिए मेंबरशिप का उपयोग करें। प्रत्येक कुंजी का केवल एक हैश संग्रहीत किया जाता है, प्रत्येक कुंजी यह रिकॉर्ड करती है कि इसका उपयोग अंतिम बार कब किया गया था, और किसी भी कुंजी को स्वतंत्र रूप से निरस्त (revoke) किया जा सकता है।

क्या कोई डेवलपर लाइव साइट पर बदलाव पुश कर सकता है?

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

क्या आप हमारी कंपनी की डायरेक्टरी के लिए SSO का समर्थन करते हैं?

हाँ। आइडेंटिटी Keycloak और OIDC तथा SAML पर काम करती है, इसलिए एंटरप्राइज़ और एजेंसी ग्राहकों के लिए SAML सिंगल साइन-ऑन उपलब्ध है, इसके साथ ही मैजिक-लिंक लॉगिन, ईमेल और पासवर्ड, सोशल प्रोवाइडर्स, पासकीज़ और TOTP टू-फैक्टर ऑथेंटिकेशन भी उपलब्ध है, जिसे पॉलिसी द्वारा लागू किया जाता है। एक सेशन में डैशबोर्ड, पब्लिक साइट और नॉलेज बेस, तथा सपोर्ट टिकट शामिल होते हैं।

मुझे कैसे पता चलेगा कि किसने बदलाव किया है?

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

क्या टीम के सदस्यों को जोड़ने से मेरे भुगतान पर कोई असर पड़ता है?

ये योजनाएँ लोगों के बजाय होस्टिंग क्षमता के आधार पर मूल्यवान होती हैं। उदाहरण के लिए, Footprint-Free लाइन पर, सभी 42 स्तर बिल्कुल एक ही हकदारी सेट साझा करते हैं और केवल उनके द्वारा अनुमति दी जाने वाली साइटों की संख्या से भिन्न होते हैं। मूल्य निर्धारण हमेशा लाइव कैटलॉग से आपकी मुद्रा में प्रस्तुत किया जाता है, इसलिए मूल्य निर्धारण पृष्ठ पर जो आप देखते हैं, वास्तव में वही शुल्क लिया जाता है।

क्या मैं प्रतिबद्ध होने से पहले इसे आज़मा सकता हूँ?

हाँ। Footprint-Free आज़माइश 14 दिनों तक चलती है, इसके लिए किसी कार्ड विवरण की आवश्यकता नहीं होती है और यह अधिकतम 5 साइटों को कवर करती है, जिससे आप भुगतान करने से पहले अपना संगठन स्थापित कर सकते हैं, अपनी टीम को आमंत्रित कर सकते हैं और वास्तविक काम के मुकाबले भूमिकाओं का परीक्षण कर सकते हैं। सशुल्क योजनाओं के पीछे 30-दिन की मनी-बैक गारंटी है।

मिनटों में अपनी टीम सेट अप करें, टिकटों में नहीं

Footprint-Free लाइन पर कार्ड-मुक्त 14-दिन का ट्रायल शुरू करें, अपनी टीम को आमंत्रित करें, और बिना कुछ भुगतान किए वास्तविक साइटों पर भूमिकाओं को काम करते हुए देखें।

निःशुल्क शुरू करें