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

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

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

एक खाते से जुड़े कई लोग, प्रत्येक के पास अपनी स्वयं की सीमित अनुमतियाँ हैं।
  • 7,00,000+दुनिया भर में होस्ट की गई साइटें
  • 4ग्राहक भूमिकाएं, सीड की गईं और तैयार हैं
  • 35विस्तृत अनुमति कुंजियाँ
  • 14 दिनबिना कार्ड का ट्रायल

चार भूमिकाएँ, जहाँ वास्तव में कार्य विभाजित होता है वहाँ निर्धारित

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

स्वामी

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

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

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

डेवलपर

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

केवल पढ़ने के लिए

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

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

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

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

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

प्रत्येक सतह पर समान अनुमतियाँ

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

डैशबोर्ड

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

सार्वजनिक API और CLI

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

Terraform प्रदाता

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

MCP सर्वर

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

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

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

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

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

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

जवाबदेही जिसे आप किसी लेखापरीक्षक को सौंप सकते हैं

प्रत्येक विशेषाधिकार प्राप्त क्रिया केवल जोड़ने योग्य ऑडिट रिकॉर्ड लिखती है: इसे किसने किया, उन्होंने क्या किया, किस पर किया, सहायक साक्ष्य और स्रोत IP पता। यह लॉग केवल जोड़ने योग्य है — घटनाओं को जोड़ा जाता है, उसी स्थान पर संपादित नहीं किया जाता है — और प्रोडक्शन में यह समय-विभाजित होता है ताकि बढ़ने के साथ-साथ यह तेज़ बना रहे।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

हाँ। पहचान प्रणाली OIDC और SAML के साथ Keycloak पर चलती है, इसलिए नीति द्वारा अनिवार्य TOTP दो-चरणीय प्रमाणीकरण, पासकी (passkeys), सोशल प्रदाता, ईमेल व पासवर्ड और मैजिक-लिंक लॉगिन के साथ-साथ एंटरप्राइज़ और एजेंसी ग्राहकों के लिए SAML सिंगल साइन-ऑन उपलब्ध है। एक ही सत्र डैशबोर्ड, सार्वजनिक साइट, ज्ञानकोष (नॉलेज बेस) और सहायता टिकटों को कवर करता है।

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

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

क्या टीम के सदस्यों को जोड़ने से मेरे भुगतान की जाने वाली राशि में बदलाव होता है?

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

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

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

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

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

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