टोलीहरू र पहुँच

आफ्नो टोलीका प्रत्येक व्यक्तिलाई ठ्याक्कै आवश्यक पर्ने पहुँच दिनुहोस्

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

एउटै खातामा जोडिएका धेरै व्यक्तिहरू, प्रत्येकका आफ्नै सीमित अनुमतिहरू हुन्छन्।
  • ७,००,०००+विश्वभर होस्ट गरिएका साइटहरू
  • 4ग्राहक भूमिकाहरू, प्रारम्भिक डेटा राखिएको र तयार
  • 35विस्तृत अनुमति कुञ्जीहरू
  • १४ दिनकार्ड बिनाको परीक्षण

काम वास्तवमा जहाँ विभाजित हुन्छ त्यहाँ निर्धारण गरिएका चार भूमिकाहरू

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

मालिक

संस्था र यसका उप-खाताहरूको पूर्ण नियन्त्रण: सहायक संस्थाहरू सिर्जना गर्ने, सदस्यहरूलाई आमन्त्रण गर्ने र हटाउने, भूमिकाहरू परिवर्तन गर्ने, API कुञ्जीहरू व्यवस्थापन गर्ने, साइटहरू व्यवस्थापन, पुन: सुरु, निलम्बन र मेटाउने, इनभ्वाइसहरू र भुक्तानी विधिहरू व्यवस्थापन गर्ने, र लेखापरीक्षण लग पढ्ने। दुईवटा कुराहरू जानाजानी यस बाहिर राखिएका छन् — संस्था बन्द गर्ने र फिर्ता रकम जारी गर्ने कार्यहरू कर्मचारीका कार्य हुन्, ग्राहकको भूमिका होइन।

बिलिङ प्रबन्धक

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

विकासकर्ता

पैसा नछोइकन साइटहरूमा काम गर्नुहोस्: साइटहरू हेर्नुहोस् र प्रावधान गर्नुहोस्, सेवाहरू पुन: सुरु गर्नुहोस्, क्यासहरू खाली गर्नुहोस्, API कुञ्जीहरू प्रबन्ध गर्नुहोस्, र समर्थन टिकटहरू उठाउनुहोस् वा जवाफ दिनुहोस्। कुनै बिलिङ दृश्य छैन, कुनै सदस्य व्यवस्थापन छैन, कुनै निलम्बन छैन र कुनै मेटाउने छैन — विनाशकारी र व्यावसायिक कार्यहरू मालिकसँगै रहन्छन्।

पढ्न मात्र मिल्ने

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

तपाईंको वास्तविक संरचनासँग मेल खाने उप-खाताहरू

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

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

पृथकीकरण केवल एप्लिकेसन कोडमा मात्र नभई डाटाबेसमा पनि लागू गरिन्छ। Postgres को पङ्क्ति-स्तर सुरक्षाले प्रत्येक टेनेन्टको क्वेरीलाई कलरको सबट्रीमा सीमित गर्दछ, र त्यो सबट्री बाहिरको कुनै पनि कुराले अनुमति त्रुटिको सट्टा फेला परेन भन्ने परिणाम फर्काउँछ — त्यसैले प्लेटफर्मले अर्को टेनेन्टको संस्था वा साइट अवस्थित छ भनेर कहिल्यै पुष्टि समेत गर्दैन।

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

भूमिकाहरू केवल ड्यासबोर्डको सहजताका लागि मात्र होइनन्। प्लेटफर्ममा प्रवेश गर्ने प्रत्येक माध्यम एउटै अनुमति कुञ्जीहरूमा आधारित हुन्छ, त्यसैले तपाईंको पहुँच नियमहरूलाई बाइपास गर्ने कुनै पनि पछाडिको ढोका छैन।

ड्यासबोर्ड

साइटहरू, बिलिङ, टिकटहरू, सूचनाहरू, जानकारीहरू, API कुञ्जीहरू र टोली व्यवस्थापन एउटै ठाउँमा। इन्टरफेसले साइन-इन गरेको सदस्यको भूमिकाले अनुमति दिएको कुरा मात्र देखाउँछ, त्यसैले मानिसहरूलाई उनीहरूले प्रयोग गर्न नसक्ने नियन्त्रणहरू देखाइँदैन।

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

प्रकाशित गरिएको API त्यही इन्जिन API हो जुन ड्यासबोर्डले प्रयोग गर्दछ। RBAC अनुमतिहरूसँग बाँधिएका विस्तृत दायराहरूका साथ प्रत्येक संस्था अनुसार API कुञ्जीहरू जारी गरिन्छ, र छुट्टाछुट्टै स्यान्डबक्स र लाइभ मोडहरूको अर्थ तपाईं वास्तविक बिलिङ वा प्रोभिजनिङलाई नछोई एकीकरणहरू परीक्षण गर्न सक्नुहुन्छ।

Terraform प्रदायक

साइटहरू, डोमेनहरू, DNS, मेलबक्सहरू र योजनाहरूलाई कोड-को-रूपमा-पूर्वाधारको रूपमा व्यवस्थापन गर्नुहोस् र होस्टिङको व्यवस्था गर्न terraform apply चलाउनुहोस् — अरू सबै थोक जस्तै समान दायराहरूद्वारा शासित।

MCP सर्भर

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

कुञ्जी ह्यान्डलिंग

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

एउटै लगइन, मापदण्डमा आधारित, सबै ठाउँमा

पहिचान Keycloak मा चल्छ, त्यसैले प्रमाणीकरण होस्टिङ प्यानलमा जोडिएको कुनै अनुकूलित लगइन फारमको सट्टा उचित OIDC र SAML हो।

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

जवाफदेहिता जुन तपाईंले लेखापरीक्षकलाई बुझाउन सक्नुहुन्छ

प्रत्येक विशेषाधिकार प्राप्त कार्यले केवल-थप्न-मिल्ने (append-only) अडिट रेकर्ड लेख्छ: कसले गर्‍यो, के गर्‍यो, केमा गर्‍यो, प्रमाणहरू र स्रोत IP ठेगाना। लग केवल थप्न मिल्ने खालको हुन्छ — घटनाहरू थपिन्छन्, सम्पादन गरिँदैन — र उत्पादनमा यो समयअनुसार विभाजन गरिएको हुन्छ ताकि यो बढ्दै जाँदा पनि यसको गति तीव्र रहन्छ।

त्यो लग पढ्नु आफैंमा एउटा अनुमति हो। मालिकहरू र पढ्न मात्र मिल्ने सदस्यहरूसँग यो हुन्छ, जसले गर्दा खाताका लागि जिम्मेवार व्यक्ति र त्यसको अडिट गर्ने व्यक्ति दुवैले त्यसो गर्नका लागि उच्च अधिकारहरूको आवश्यकता बिना नै पूरा इतिहास हेर्न सक्छन्।

त्यसको वरिपरि ठूला टोलीहरूले माग गर्ने नियन्त्रणहरू छन्: सत्र नीतिहरू, प्रति-संस्था ऐच्छिक आईपी अनुमति सूचीहरू, र संवेदनशील कार्यहरूमा चरणबद्ध प्रमाणीकरण ताकि गम्भीर केही गर्नका लागि केवल एक सक्रिय सत्र मात्र पर्याप्त नहोस्।

अनुमतिहरू तपाईंसँग कसरी विस्तार हुन्छन्

अनुमति क्याटलग डेटा हो, हार्डकोड गरिएको लजिक होइन — त्यसैले प्लेटफर्मलाई पुन: संरचना नगरीकनै यसलाई विस्तार गर्न सकिन्छ।

  • संस्थाहरू, सदस्यहरू, API कुञ्जीहरू, साइटहरू, बिलिङ, योजनाहरू, फ्लीट, टिकटहरू, ग्राहकहरू, दुरुपयोग, अभियानहरू, अनुवादहरू र अडिट समेट्ने ३५ वटा विस्तृत module.action कुञ्जीहरू आज उपलब्ध छन्।
  • प्रत्येक डिप्लोयमा क्याटलग आइडम्पोटेन्ट तरिकाले सिड गरिन्छ, र यदि कुनै भूमिकाले अवस्थित नभएको अनुमतिलाई सन्दर्भ गर्दछ भने प्रमाणीकरण स्पष्ट रूपमा असफल हुन्छ — टाइपिङ त्रुटिले चुपचाप केही पनि प्रदान नगर्ने हुन सक्दैन।
  • अन्त्यबिन्दु उपलब्ध हुनुभन्दा अगाडि नै नयाँ उत्पादन क्षमताहरूले आफ्नो अनुमति कुञ्जीहरू सूचीमा थप्छन्, त्यसैले सुविधा प्रत्यक्ष भइसकेपछि पहुँच नियन्त्रणलाई कहिल्यै पनि पछिबाट मिलाउनुपर्दैन।
  • एकल सदस्यताको दायरालाई विशिष्ट साइटहरू वा विशिष्ट क्षेत्रमा सीमित गर्नु एक योजनाबद्ध सुधार हो, यो आजै तपाईंले सक्रिय गर्न सक्ने कुरा होइन। हालको ढाँचा भनेको ती साइटहरूलाई चाइल्ड संस्थामा राख्नु र सम्बन्धित व्यक्तिलाई त्यहाँ भूमिका प्रदान गर्नु हो — जसले तपाईंलाई टेनेन्सी ट्री प्रयोग गरी समान विभाजन प्रदान गर्दछ।
  • API कुञ्जीहरू प्रति व्यक्ति नभई संस्था स्तरमा जारी गरिन्छ, त्यसैले तिनीहरूलाई एकीकरणका लागि सेवा प्रमाण-पत्रको रूपमा लिनुहोस् र मानवीय पहुँचका लागि सदस्यताहरू प्रयोग गर्नुहोस्।

बारम्बार सोधिने प्रश्नहरू

प्रत्येक भूमिकाले वास्तवमा के गर्न सक्छ?

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

के म कसैलाई एउटा मात्र साइटमा पहुँच दिन सक्छु?

अहिले नै प्रति-साइट सेटिङको रूपमा उपलब्ध छैन — एकल सदस्यतालाई निश्चित साइटहरूमा सीमित गर्नु एक योजनाबद्ध सुधार हो। आज तपाईंले टेनेन्सी ट्री (tenancy tree) मार्फत उस्तै प्रकारको पृथकीकरण हासिल गर्न सक्नुहुन्छ: ती साइटहरूलाई शाखा संस्थामा राख्नुहोस् र व्यक्तिलाई त्यहाँ भूमिका दिनुहोस्। भूमिकाहरू संस्थागत रूपमा प्रदान गरिने भएकाले, त्यो पहुँच तपाईंको खातामा रहेको अरू कुनै पनि कुरामा लागू हुँदैन।

के API कुञ्जीहरू टोलीका व्यक्तिगत सदस्यहरूसँग बाँधिएका छन्?

होइन — API कुञ्जीहरू प्रति संस्था जारी गरिन्छ, जसमा उही RBAC अनुमतिहरूसँग जोडिएका विस्तृत दायराहरू र छुट्टै sandbox र live मोडहरू हुन्छन्। तिनीहरूलाई एकीकरण, CI वा Terraform का लागि सेवा प्रमाणहरूको रूपमा प्रयोग गर्नुहोस्, र मानिसहरूका लागि सदस्यताहरू प्रयोग गर्नुहोस्। प्रत्येक कुञ्जीको ह्यास मात्र भण्डारण गरिन्छ, प्रत्येक कुञ्जीले यसलाई पछिल्लो पटक कहिले प्रयोग गरिएको थियो भन्ने रेकर्ड गर्दछ, र कुनै पनि कुञ्जीलाई छुट्टै खारेज गर्न सकिन्छ।

के विकासकर्ताले प्रत्यक्ष साइटमा परिवर्तनहरू पठाउन सक्छ?

विकासकर्ता (डेभलपर) भूमिकाले साइटहरू हेर्ने र व्यवस्थापन गर्ने, सेवाहरू पुन: सुरु गर्ने, क्यासहरू खाली गर्ने, API कुञ्जीहरू व्यवस्थापन गर्ने र टिकटहरू सम्हाल्ने कार्यहरू समेट्छ। यसमा प्रत्यक्ष साइटमा प्रकाशित गर्ने अधिकार समावेश हुँदैन, त्यसैले यदि तपाईं कसैलाई परिवर्तनहरू लागू गर्न सक्षम बनाउन चाहनुहुन्छ भने, त्यो पहुँच मालिकसँग हुनुपर्छ। भूमिकाहरू प्रति संस्थाअनुसार हुन्छन्, त्यसैले तपाईंले फरक खातामा फरक भूमिका राख्न सक्नुहुन्छ।

के तपाईं हाम्रो कम्पनी डाइरेक्टरीका लागि SSO समर्थन गर्नुहुन्छ?

हो। पहिचान व्यवस्थापन OIDC र SAML सहित Keycloak मा सञ्चालन हुन्छ, त्यसैले नीतिद्वारा अनिवार्य गरिएको म्याजिक-लिङ्क लगइन, इमेल र पासवर्ड, सामाजिक लगइन प्रदायकहरू, पासकीहरू र TOTP दुई-चरण प्रमाणीकरणका साथै इन्टरप्राइज र एजेन्सी ग्राहकहरूका लागि SAML एकल साइन-अन उपलब्ध छ। एउटै सत्रले ड्यासबोर्ड, सार्वजनिक साइट, ज्ञानकोष र समर्थन टिकटहरू समेट्छ।

कसैले केही परिवर्तन गर्‍यो भनेर मैले कसरी थाहा पाउने?

प्रत्येक विशेषाधिकार प्राप्त कार्यलाई कर्ता, कार्य, लक्ष्य, समर्थन गर्ने प्रमाण र IP ठेगाना रेकर्ड गर्ने थप-मात्र अडिट लगमा लेखिन्छ। यसलाई पढ्नु आफैंमा एक अनुमति हो, जुन मालिक र पढ्न-मात्र दुवै भूमिकाहरूसँग हुन्छ, जसले गर्दा खाता मालिक र लेखापरीक्षकले समान इतिहास समीक्षा गर्न सक्छन्।

टोलीका सदस्यहरू थप्दा मैले तिर्ने रकम परिवर्तन हुन्छ?

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

के म प्रतिबद्ध हुनु अघि यो परीक्षण गर्न सक्छु?

हो। Footprint-Free परीक्षण १४ दिनसम्म चल्छ, यसका लागि कुनै कार्ड विवरण चाहिँदैन र ५ वटासम्म साइटहरू समेट्छ, त्यसैले तपाईंले कुनै पनि भुक्तानी गर्नुअघि आफ्नो संस्था सेटअप गर्न, आफ्नो टोलीलाई आमन्त्रण गर्न र वास्तविक काममा भूमिकाहरू परीक्षण गर्न सक्नुहुन्छ। सशुल्क योजनाहरूमा ३०-दिने पैसा फिर्ताको ग्यारेन्टी छ।

टिकटहरूको झन्झट बिना, मिनेटमै आफ्नो टोली सेटअप गर्नुहोस्

Footprint-Free लाइनमा कार्ड-रहित १४-दिने परीक्षण सुरु गर्नुहोस्, आफ्नो टोलीलाई आमन्त्रित गर्नुहोस्, र कुनै पनि भुक्तानी गर्नुअघि वास्तविक साइटहरूमा भूमिकाहरूले कसरी काम गर्छन् हेर्नुहोस्।

निःशुल्क सुरु गर्नुहोस्