टोलीहरू र पहुँच
ग्राहकका चार भूमिकाहरू, तपाईंको व्यवसाय वास्तवमा कसरी संरचना गरिएको छ भन्ने कुरालाई प्रतिबिम्बित गर्ने उप-खाताहरू, प्रति-संस्था API कुञ्जीहरू, एकल साइन-अन र प्रत्येक विशेषाधिकार प्राप्त कार्य पछाडि अडिट लग। ड्यासबोर्ड, API, CLI, Terraform र हाम्रो MCP सर्भरमा एउटै पहुँच मोडल चल्छ। उपलब्धता: Terraform प्रदायक सक्रिय विकासको क्रममा छ र अझै उपलब्ध छैन। यहाँ वर्णन गरिएका बाँकी सबै कुराहरू आज सञ्चालनमा छन्।
पहुँच एउटा मात्र अन/अफ स्विच होइन। प्रत्येक ग्राहक संस्था चारवटा भूमिकाहरूसँग आउँछ, जसमा प्रत्येक दानेदार module.action अनुमतिहरूको निश्चित बन्डल हुन्छ — त्यसैले वित्त सम्पर्कले कहिल्यै पनि सर्भर छुँदैन र विकासकर्ताले कहिल्यै पनि इनभोइस देख्दैन।
संस्था र यसका उप-खाताहरूको पूर्ण नियन्त्रण: चाइल्ड संस्थाहरू सिर्जना गर्ने, सदस्यहरूलाई आमन्त्रित गर्ने र हटाउने, भूमिका परिवर्तन गर्ने, API कुञ्जीहरू व्यवस्थापन गर्ने, साइटहरू प्रबन्ध गर्ने, पुन: सुरु गर्ने, निलम्बन गर्ने र मेटाउने, बीजकहरू र भुक्तानी विधिहरू व्यवस्थापन गर्ने, र अडिट लग पढ्ने। जानाजानी यसको दायरा बाहिर राखिएका दुईवटा कुराहरू हुन् — संस्था बन्द गर्ने र फिर्ता (refunds) जारी गर्ने कामहरू ग्राहकको भूमिका नभई कर्मचारीका कार्यहरू हुन्।
सबै कुरा वित्तीय मात्र र अरू केही होइन: बीजकहरू, सदस्यताहरू, भुक्तानी विधिहरू र योजना क्याटलग, साथै संस्थाको दृश्य र यसका सदस्यहरूको सूची। साइटमा कुनै पनि पहुँच छैन — एक वित्तीय सम्पर्क वा बाह्य लेखापालले कुनै पनि कुरा पुन: सुरु, निलम्बन वा मेटाउन सक्दैन।
पैसालाई छोइ नभई साइटहरूमा काम गर्नुहोस्: साइटहरू हेर्नुहोस् र उपलब्ध गराउनुहोस्, सेवाहरू पुन: सुरु गर्नुहोस्, क्यासहरू खाली गर्नुहोस्, API कुञ्जीहरू प्रबन्ध गर्नुहोस्, र समर्थन टिकटहरू उठाउनुहोस् वा जवाफ दिनुहोस्। कुनै बिलिङ दृश्य छैन, कुनै सदस्य व्यवस्थापन छैन, कुनै निलम्बन छैन र कुनै मेटाउने छैन — विनाशकारी र व्यावसायिक कार्यहरू मालिकसँगै रहन्छन्।
सदस्यहरू, साइटहरू, बिलिङ, योजनाहरू, टिकटहरू, अनुवाद स्थिति र अडिट लग—कुनै पनि कुरा परिवर्तन गर्ने क्षमता बिनाको पूर्ण दृश्य। क्लाइन्ट स्टेकहोल्डर, आन्तरिक अडिटर वा भर्खरै सुरु गर्दै गरेका नयाँ कर्मचारीका लागि उपयुक्त भूमिका।
Tenancy भनेको समतल सूची होइन, रूख हो। एक पुनर्विक्रेता संस्था यसका क्लाइन्ट संस्थाहरूभन्दा माथि बस्छ, र साइटहरू तीभन्दा तल बस्छन्। एक टिम सदस्य भनेको सदस्यता हो — एक प्रयोगकर्ता, एक संस्था, एक भूमिका — त्यसैले एउटै आधारभूत तत्त्वले दुई जनाको टिम, सयवटा क्लाइन्ट खाताहरू व्यवस्थापन गर्ने एजेन्सी र आफ्नै ब्रान्ड अन्तर्गत उप-खाताहरू सञ्चालन गर्ने पुनर्विक्रेतालाई शक्ति प्रदान गर्दछ।
भूमिका (Roles) प्रत्येक संस्थाको लागि छुट्टाछुट्टै प्रदान गरिन्छन् र तिनको कार्यान्वयन पनि प्रति संस्था नै हुन्छ। एउटा संस्थाको भूमिकाले अर्को छुट्टै, असंबंधित संस्थामा कुनै पहुँच प्रदान गर्दैन — एउटै लगइनबाट एक ठेकेदार (contractor) एउटा क्लाइन्ट खातामा Developer र दोस्रोमा Read-only हुन सक्छ। यद्यपि, पहुँच तपाईंको आफ्नै पदानुक्रम (hierarchy) मा तलतिर सर्छ: अभिभावक (parent) संस्थाको भूमिका त्यसअन्तर्गत नेस्ट गरिएका संस्थाहरूमा लागू हुन्छ, जसरी reseller हरू र एजेन्सीहरूले आफ्ना क्लाइन्टहरूलाई व्यवस्थापन गर्छन्।
एप्लिकेशन कोडमा मात्र होइन, डेटाबेसमा नै आइसोलेसन लागू गरिएको हुन्छ। Postgres को रो-लेभल सुरक्षाले प्रत्येक टेनेन्टको क्वेरीलाई कलरको सबट्रीमा सीमित गर्छ, र त्यस सबट्री बाहिरको कुनै पनि कुराले अनुमति त्रुटिको सट्टा 'फेला परेन' (not-found) प्रतिक्रिया दिन्छ — जसले गर्दा प्लेटफर्मले अर्को टेनेन्टको संस्था वा साइट अवस्थित छ भन्ने कुरा पनि कहिल्यै पुष्टि गर्दैन।
भूमिका हरू ड्यासबोर्डमा मात्रै सीमित हुने सुविधा होइनन्। प्लेटफर्ममा प्रवेश गर्ने प्रत्येक तरिकाले उही अनुमति कुञ्जीहरूप्रति सङ्केत गर्छन्, त्यसैले तपाईंको पहुँच नियमहरूलाई छल्ने कुनै पनि पछाडिको ढोका हुँदैन।
साइटहरू, बिलिङ, टिकटहरू, सूचनाहरू, नटिप्लिकेसनहरू, API कुञ्जीहरू र टोली व्यवस्थापन एउटै शेलमा। इन्टरफेसले साइन-इन गरेका सदस्यको भूमिकाले अनुमति दिने कुरा मात्र देखाउँछ, त्यसैले मानिसहरूलाई उनीहरूले प्रयोग गर्न नमिल्ने नियन्त्रणहरू देखाइँदैन।
प्रकाशित API त्यही इन्जिन API हो जुन ड्यासबोर्डले प्रयोग गर्छ। API कुञ्जीहरू RBAC अनुमतिहरूसँग जोडिएका दानेदार दायराहरू सहित प्रति संस्था जारी गरिन्छ, र छुट्टै स्यान्डबक्स र लाइभ मोडहरूको मतलब तपाईंले वास्तविक बिलिङ वा प्रबन्धलाई नछोइकन एकीकरणहरूको परीक्षण गर्न सक्नुहुन्छ।
साइटहरू, डोमेनहरू, DNS, मेलबक्सहरू र योजनाहरूलाई इन्फ्रास्ट्रक्चर-एज-कोड (infrastructure-as-code) को रूपमा व्यवस्थापन गर्नुहोस् र होस्टिंग प्रबन्ध गर्न terraform apply चलाउनुहोस् — जुन अन्य सबै कुराहरूसँगै समान दायराहरूद्वारा नियन्त्रित हुन्छ।
Claude Code, Cursor, ChatGPT, Claude Desktop वा कुनै पनि MCP-सक्षम उपकरण जडान गर्नुहोस्। टोकनहरू संस्था र यसका RBAC अनुमतिहरूमा सीमित हुन्छन्, प्रत्येक उपकरणको आधारमा रद्द गर्न सकिने, विनाशकारी कार्यहरूमा पुष्टिकरण, खर्चको सीमा र पूर्ण अडिट ट्रेलसहित हुन्छन्।
प्रत्येक API कुञ्जीको केवल एक ह्यास मात्र भण्डारण गरिन्छ — कहिल्यै पनि कच्चा कुञ्जी होइन। कुञ्जीहरूसँग एउटा नाम र देखिने उपससर्ग हुन्छ जसले गर्दा तपाईँले तिनीहरूलाई छुट्याउन, ती अन्तिम पटक कहिले प्रयोग गरिएका थिए भनेर रेकर्ड गर्न सक्नुहुन्छ, र बाँकीलाई असर नगरी व्यक्तिगत रूपमा खारेज गर्न सकिन्छ।
पely पहिचान Keycloak मा आधारित छ, त्यसैले प्रमाणीकरण हस्टिङ प्यानलमा जोडिएको अनुकूल लगइन फारमको सट्टा वास्तविक OIDC र SAML हो।
प्रत्येक विशेष अधिकार प्राप्त कार्यले एउटा मात्र-थप्न-मिल्ने (append-only) अडिट रेकर्ड लेख्छ: कसले गर्यो, तिनीहरूले के गरे, के माथि गरे, त्यसलाई समर्थन गर्ने प्रमाण र मूल IP ठेगाना। लग मात्र-थप्न-मिल्ने हुन्छ — घटनाहरू थपिन्छन्, ठाउँको ठाउँ सम्पादन गरिँदैन — र प्रोडक्सनमा यो समय-विभाजित (time-partitioned) हुन्छ ताकि यो बढ्दै जाँदा पनि छिटो भइरहन्छ।
त्यो लग पढ्नु आफैँमा एक अनुमति हो। यसलाई मालिकहरू र रिड-ओन्ली सदस्यहरूले राख्छन्, त्यसैले खाताको लागि जिम्मेवार व्यक्ति र यसको लेखापरीक्षण गर्ने व्यक्ति दुवैले त्यसो गर्नको लागि उच्च अधिकारको आवश्यकता बिना नै पूर्ण इतिहास हेर्न सक्छन्।
त्यसको वरिपरि ठूला टोलीसुरुवातले माग गर्ने नियन्त्रणहरू हुन्छन्: सत्र नीतिहरू, वैकल्पिक प्रति-संस्था IP अनुमतिसूचीहरू, र संवेदनशील कार्यहरूमा स्टेप-अप प्रमाणीकरण ताकि कुनै गम्भीर काम गर्न केवल प्रत्यक्ष सत्र मात्र पर्याप्त नहोस्।
अनुमति क्याटलग डेटा हो, हार्डकोड गरिएको तर्क होइन — त्यसैले यसलाई प्लेटफर्मलाई पुन: संरचना नगरी विस्तार गर्न सकिन्छ।
मालिकसँग संस्था र यसका सब-अकाउन्टहरूमा पूर्ण नियन्त्रण हुन्छ, जसमा सदस्यहरू, API कुञ्जीहरू, साइटहरू र भुक्तानी विधिहरू समावेश छन्। बिलिङ म्यानेजरले साइटमा पहुँच नभई इनभ्वाइसहरू, सदस्यताहरू, भुक्तानी विधिहरू र प्लानहरू हेर्छन्। डेभलपरले बिलिङ वा सदस्य नियन्त्रण बिना साइटहरू र API कुञ्जीहरू व्यवस्थापन गर्छन् र टिकटहरू ह्यान्डल गर्छन्। रिड-ओनलीले कुनै पनि कुरा परिवर्तन नगरी सदस्यहरू, साइटहरू, बिलिङ, प्लानहरू, टिकटहरू र अडिट लगर हेर्न सक्छन्।
अहिले प्रति-साइट सेटिङको रूपमा छैन — एकल सदस्यतालाई विशिष्ट साइटहरूमा सीमित गर्ने कुरा योजना गरिएको सुधार हो। आज तपाईंले टेनन्सी ट्रीको साथ त्यही भिन्नता हासिल गर्नुहुन्छ: ती साइटहरूलाई बाल संस्था (child organisation) मा राख्नुहोस् र त्यो व्यक्तिलाई त्यहाँ एउटा भूमिका दिनुहोस्। भूमिका प्रति संस्था प्रदान गरिने हुनाले, त्यो पहुँच तपाईंको खातामा भएका अन्य कुनै पनि कुरामा सर्दैन।
होइन — API कुञ्जीहरू संस्थापिच्छे जारी गरिन्छन्, जसमा समान RBAC अनुमतिहरूसँग जोडिएका दानेदार दायराहरू (scopes) र छुट्टै स्यान्डबक्स तथा लाइभ मोडहरू हुन्छन्। तिनीहरूलाई इन्टिग्रेशन, CI वा Terraform का लागि सेवा प्रमाण पत्र (service credentials) को रूपमा प्रयोग गर्नुहोस्, र मानिसहरूका लागि सदस्यताहरू (memberships) प्रयोग गर्नुहोस्। प्रत्येक कुञ्जीको केवल ह्यास मात्र भण्डारण गरिन्छ, प्रत्येक कुञ्जीले यो अन्तिम पटक कहिले प्रयोग गरिएको थियो भन्ने रेकर्ड राख्छ, र जुनसुकै कुञ्जीलाई पनि छुट्टै खारेज गर्न सकिन्छ।
विकासकर्ताको भूमिकाले साइटहरू हेर्ने र उपलब्ध गराउने, सेवाहरू पुनर्गुरुण गर्ने, क्याचहरू खाली गर्ने, API कुञ्जीहरू व्यवस्थापन गर्ने र टिकटहरू ह्यान्डल गर्ने काम समेट्छ। यसले लाइभ साइटमा प्रकाशन अधिकार बोक्दैन, त्यसैले यदि तपाईं कसैलाई परिवर्तनहरू प्रवर्द्धन गर्न सक्षम बनाउन चाहनुहुन्छ भने, त्यो पहुँच मालिकसँग हुनुपर्छ। भूमिकाहरू प्रति संस्था हुन्छन्, त्यसैले तपाईंले फरक खातामा फरक भूमिका राख्न सक्नुहुन्छ।
हो। पहिचान Keycloak मा OIDC र SAML मार्फत चल्छ, त्यसैले इन्टरप्राइज र एजेन्सी ग्राहकहरूका लागि मजिक-लिंक लगइन, इमेल र पासवर्ड, सामाजिक प्रदायकहरू, पासकीहरू र नीतिद्वारा लागू गरिएको TOTP दुई-कारक प्रमाणीकरणका साथै SAML सिंगल साइन-अन उपलब्ध छ। एउटा सत्रले ड्यासबोर्ड, सार्वजनिक साइट र ज्ञान केन्द्र (knowledge base), र समर्थन टिकटहरू समेट्छ।
प्रत्येक विशेष अधिकार प्राप्त कार्य एक थपिने-मात्र मिल्ने अडिट लगमा रेकर्ड गरिन्छ जसमा कर्ता, कार्य, लक्ष्य, समर्थन गर्ने प्रमाण र IP ठेगाना रेकर्ड हुन्छन्। यसलाई पढ्न पाउनु आफैँमा एक अनुमति हो, जुन मालिक (Owner) र रिड-ओन्ली (Read-only) दुवै भूमिकाहरूमा हुन्छ, त्यसैले खाताको मालिक र अडिटर दुवैले एउटै इतिहास समीक्षा गर्न सक्छन्।
योजनाहरूको मूल्य मानिसहरूको आधारमा नभई होस्टिङ क्षमताको आधारमा तय गरिन्छ। उदाहरणका लागि, Footprint-Free लाइनमा, सबै ४२ वटा तहहरूले समान अधिकार सेट साझा गर्छन् र तिनीहरूले अनुमति दिने साइटहरूको संख्यामा मात्र फरक हुन्छन्। मूल्य निर्धारण सधैं प्रत्यक्ष क्याटलगबाट, तपाईंको मुद्रामा देखाइन्छ, त्यसैले तपाईंले मूल्य निर्धारण पृष्ठमा जे देख्नुहुन्छ त्यही नै वास्तविक रूपमा शुल्क लिइन्छ।
हो। Footprint-Free को परीक्षण अवधि १४ दिनको हुन्छ, यसका लागि कुनै कार्डको विवरण आवश्यक पर्दैन र यसले ५ वटा साइटहरूसम्म समेट्छ, त्यसैले तपाईंले कुनै पनि भुक्तानी गर्नु अघि आफ्नो संस्था सेटअप गर्न, आफ्नो टोलीलाई आमन्त्रित गर्न र वास्तविक कामको बिरूद्ध भूमिकाहरू परीक्षण गर्न सक्नुहुन्छ। सशुल्क योजनाहरूको पछाडि ३०-दिने पैसा फिर्ता गर्ने ग्यारेन्टी छ।
कुनै पनि भुक्तानी नगरी Footprint-Free लाइनमा कार्ड-मुक्त १४ दिने परीक्षण सुरु गर्नुहोस्, आफ्नो टिमलाई आमन्त्रित गर्नुहोस् र वास्तविक साइटहरूमा काम गरिरहेका भूमिकाहरू हेर्नुहोस्।
निःशुल्क सुरु गर्नुहोस्