संघ आणि प्रवेश

तुमच्या टीममधील प्रत्येक व्यक्तीला त्यांना हवा असलेला अचूक प्रवेश द्या

चार ग्राहक भूमिका, उप-खाती जी तुमच्या व्यवसायाच्या प्रत्यक्ष संरचनेशी जुळतात, प्रति-संघटना API की, सिंगल साइन-ऑन आणि प्रत्येक विशेषाधिकारप्राप्त कृतीमागे एक ऑडिट लॉग. डॅशबोर्ड, API, CLI, Terraform आणि आमच्या MCP सर्व्हरवर हाच प्रवेश मॉडेल चालतो. उपलब्धता: Terraform प्रदाता सक्रिय विकासात आहे आणि अद्याप उपलब्ध नाही. येथे वर्णन केलेल्या इतर सर्व गोष्टी आज लाइव्ह आहेत.

  • ६,५०,०००+जगभरात होस्ट केलेली साइट्स
  • ग्राहक भूमिका, सिडेड आणि तयार
  • ३५बारीक परवानग्या कीज
  • १४ दिवसकार्ड-मुक्त चाचणी

चार भूमिका, जिथे काम खऱ्या अर्थाने विभागले जाते तिथे आखलेल्या

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

मालक

संस्था आणि तिची उप-खाती यांवर पूर्ण नियंत्रण: चाइल्ड संस्था तयार करणे, सदस्यांना आमंत्रित करणे आणि काढून टाकणे, भूमिका बदलणे, API की व्यवस्थापित करणे, साइट्स प्रोव्हिजन करणे, रीस्टार्ट करणे, निलंबित करणे आणि हटवणे, बीजक (invoices) आणि पेमेंट पद्धती व्यवस्थापित करणे, आणि ऑडिट लॉग वाचणे. यामध्ये दोन गोष्टी जाणीवपूर्वक वगळल्या आहेत — संस्था बंद करणे आणि रिफंड जारी करणे हे कर्मचारी करतात, ग्राहकाची भूमिका नाही.

बिलिंग मॅनेजर

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

डेव्हलपर

पैशांना हात लावल्याशिवाय साइट्सवर काम करा: साइट्स पाहणे आणि तयार करणे, सेवा रीस्टार्ट करणे, कॅशे साफ करणे, API की व्यवस्थापित करणे आणि सपोर्ट तिकीट वाढवणे किंवा त्यांना उत्तर देणे. कोणतेही बिलिंग दृश्य नाही, सदस्य व्यवस्थापन नाही, सस्पेंड आणि डिलीट करणे नाही — विध्वंसक आणि व्यावसायिक क्रिया मालकाकडेच राहतात.

फक्त-वाचनीय

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

तुमच्या प्रत्यक्ष रचनेशी जुळणारी सब-अकाउंट्स

टेनन्सी ही एक ट्री (वृक्ष) रचना आहे, फ्लॅट सूची नाही. एक रिसेलर संस्था तिच्या क्लायंट संस्थांच्या वर असते आणि साईट्स त्यांच्या खाली असतात. टीम मेंबर ही एक मेंबरशिप असते — एक युजर, एक संस्था, एक रोल — त्यामुळे एकच मूळ घटक दोन जणांच्या टीमला, शेकडो क्लायंट खात्यांचे व्यवस्थापन करणाऱ्या एजन्सीला आणि स्वतःच्या ब्रँडखाली सब-अकाउंट्स चालवणाऱ्या रिसेलरला ताकद देतो.

प्रत्येक संस्थेसाठी भूमिका स्वतंत्रपणे दिल्या जातात आणि त्यांची अंमलबजावणीही संस्थेनुसारच होते. एका संस्थेतील भूमिका दुसऱ्या, असंबंधित संस्थेत कोणताही प्रवेश देत नाही — एकाच लॉगीनवरून, एक कंत्राटदार एका क्लायंट खात्यावर डेव्हलपर आणि दुसऱ्या खात्यावर रीड-ओन्ली असू शकतो. तथापि, प्रवेश तुमच्या स्वतःच्या हायरार्कीमध्ये खालील बाजूस लागू होतो: मूळ (पैरंट) संस्थेतील भूमिका तिच्या अंतर्गत असलेल्या उप-संस्थांना लागू होते, याद्वारेच रीसेलर आणि एजन्सी त्यांच्या क्लायंटचे व्यवस्थापन करतात.

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

प्रत्येक पृष्ठभागावर समान परवानग्या

भूमिका ही केवळ डॅशबोर्डवरील सोय नाही. प्लॅटफॉर्मवर प्रवेश करण्याचा प्रत्येक मार्ग समान परवानगी की शी जुळतो, त्यामुळे तुमच्या प्रवेश नियमांना बायपास करणारे कोणतेही बॅक डोअर नाही.

डॅशबोर्ड

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

पब्लिक एपीआय आणि सीएलआय

प्रकाशित API तीच इंजिन API आहे जी डॅशबोर्ड वापरतो. RBAC परवानगीशी जोडलेल्या सविस्तर स्कोपसह प्रत्येक संस्थेसाठी API की जारी केल्या जातात आणि स्वतंत्र सेंडबॉक्स व लाईव्ह मोड्समुळे वास्तविक बिलिंग किंवा प्रोव्हिजनingला हात न लावता तुम्ही इंटिग्रेशन्सची चाचणी घेऊ शकता.

टेरफॉर्म प्रोव्हायडर

साइट्स, डोमेन, DNS, मेलबॉक्स आणि प्लॅन्स इन्फ्रास्ट्रक्चर-आस-कोड म्हणून व्यवस्थापित करा आणि होस्टिंग प्रोव्हिजन करण्यासाठी terraform apply चालवा — इतर सर्वांसारख्याच स्कोप्सद्वारे नियंत्रित.

MCP सर्व्हर

Claude Code, Cursor, ChatGPT, Claude Desktop किंवा कोणतंही MCP-सक्षम साधन कनेक्ट करा. टोकन्स एका संस्थेसाठी आणि तिच्या RBAC परवानग्यांसाठी मर्यादित असतात, प्रति साधन रद्द करण्यायोग्य असतात, विनाशात्मक कृतींवर पुष्टीकरण, खर्च मर्यादा आणि संपूर्ण ऑडिट ट्रेल असतो.

किल्ली हाताळणी

प्रत्येक API की चा केवळ एक हॅश साठवला जातो — मूळ की कधीही नाही. प्रत्येक की ला एक नाव आणि एक दृश्यमान उपसर्जक (प्रिफिक्स) असतो जेणेकरून तुम्ही त्या ओळखू शकता, त्यांचा शेवटी वापर कधी झाला याची नोंद ठेऊ शकता, आणि इतर कशासूनही न अडकता त्या स्वतंत्रपणे रद्द करू शकता.

एक लॉगिन, मानकांवर आधारित, सर्वांसाठी

ओळख Keycloak वर चालते, त्यामुळे प्रमाणेच प्रमाणीकरण हे होस्टिंग पॅनेलला जोडलेल्या सानुकूल लॉगिन फॉर्मऐवजी योग्य OIDC आणि SAML आहे.

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

ऑडिटरसिंग सैलस देता येईल अशी उत्तरदायित्व

प्रत्येक विशेषाधिकारप्राप्त कृत्य (privileged action) अपेंड-ओन्ली (append-only) ऑडिट रेकॉर्ड नोंदवते: कोणी केले, काय केले, कशावर केले, त्याला पाठबळ देणारा पुरावा आणि मूळ आयपी (IP) ॲड्रेस. हा लॉग अपेंड-ओन्ली आहे — इव्हेंट्स जोडले जातात, ते आहेत तिथे संपादित केले जात नाहीत — आणि प्रोडक्शनमध्ये तो वेळेनुसार विभाजित (time-partitioned) केला जातो, ज्यामुळे तो जसा वाढतो तसा त्याचा वेग कायम राहतो.

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

त्याभोवती मोठ्या संघांनी मागितलेली नियंत्रणे आहेत: सत्र धोरणे, पर्यायी प्रति-संघटना IP अनुमती सूची, आणि संवेदनशील कृतींवर स्टेप-अप प्रमाणीकरण जेणेकरून केवळ लाईव्ह सत्र काहीतरी गंभीर करण्यासाठी पुरेसे ठरणार नाही.

परवानग्या तुमच्यासोबत कशा वाढतात

परवान्यांचे कॅटलॉग हा डेटा आहे, हार्डकोडेड लॉजिक नाही — म्हणूनच प्लॅटफॉर्मची पुनर्रचना न करता यात वाढ करता येते.

  • आज ३५ ग्रॅम्युलर module.action की आहेत, ज्या संस्था, सदस्य, API की, साइट्स, बिलिंग, प्लॅन्स, फ्लीट, तिकीट, ग्राहक, गैरवापर, मोहिमा, भाषांतरे आणि ऑडिट यांना सामावून घेतात.
  • कॅटलॉग प्रत्येक वेळी डिप्लॉय करताना आयडempotent पद्धतीने भरला जातो, आणि एखादी भूमिका अस्तित्वात नसलेल्या परवानगीचा संदर्भ देत असल्यास व्हॅलिडेशन जोरात अयशस्वी ठरते — टायपो मुळे कोणतीही परवानगी मुकपणे दिली जाऊ शकत नाही.
  • नवीन उत्पादनाची क्षमता एन्डकॉप शिप होण्यापूर्वी तिची परवानगी की कॅटलॉगमध्ये जोडते, त्यामुळे वैशिष्ट्य थेट लाइव्ह झाल्यानंतर प्रवेश नियंत्रण कधीही मागे लावले जात नाही.
  • एकाच मेंबरशिपची व्याप्ती विशिष्ट साईट्स किंवा विशिष्ट प्रदेशांपुरtsी मर्यादित करणे हे भविष्यात नियोजित केलेले सुधारणात्मक काम आहे, आजच्या आज चालू करता येईल असे नाही. सध्याची पद्धत म्हणजे त्या साईट्सना एका चाईल्ड ऑर्गनायझेशनमध्ये (child organisation) ठेवून तेथील व्यक्तीला भूमिका देणे - ज्यायोगे तुम्हाला टेनन्सी ट्रीचा वापर करून तीच विभक्तता मिळवता येते.
  • API की प्रत्येक व्यक्तीऐवजी संस्थेच्या स्तरावर जारी केले जातात, त्यामुळे इंटिग्रेशनसाठी त्यांना सर्व्हिस क्रेडेन्शियल्स म्हणून माना आणि मानवी प्रवेशासाठी मेंबरशिपचा वापर करा.

सतत विचारले जाणारे प्रश्न

प्रत्येक भूमिका प्रत्यक्षात काय करू शकते?

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

मी कोणालातरी फक्त एका साइटवर प्रवेश देऊ शकतो का?

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

API की (keys) वैयक्तिक टीम सदस्यांशी जोडलेल्या असतात का?

नाही — API की (keys) संस्थेनुसार जारी केल्या जातात, ज्यामध्ये समान RBAC परवानगीशी जोडलेले ग्रॅन्युलर स्कोप आणि स्वतंत्र सँडबॉक्स व लाईव्ह मोड असतात. इंटिग्रेशन्स, CI किंवा Terraform साठी त्यांना सर्व्हिस क्रेडेन्शियल्स म्हणून वापर करा आणि लोकांसाठी मेंबरशिप्सचा वापर करा. प्रत्येक कीचा फक्त एक हॅश साठवला जातो, प्रत्येक की ती शेवटची कधी वापरली गेली हे रेकॉर्ड करते आणि कोणतीही की स्वतंत्रपणे रद्द केली जाऊ शकते.

एखादा डेव्हलपर थेट लाईव्ह साईटवर बदल पुश (push) करू शकतो का?

डेव्हलपर भूमिकेमध्ये साइट्स पाहणे आणि तयार करणे, सेवा रीस्टार्ट करणे, कॅशे साफ करणे, API की व्यवस्थापित करणे आणि तिकीट हाताळणे यांचा समावेश होतो. या भूमिकेमुळे लाइव्ह साइटवर प्रकाशन करण्याचे अधिकार मिळत नाहीत, त्यामुळे जर तुम्हाला कोणाला बदल लाईव्ह करण्याची परवानगी द्यायची असेल, तर तो अधिकार मालकाकडे (ओनरकडे) असणे आवश्यक आहे. भूमिका या प्रत्येक संस्थेनुसार (ऑर्गनायझेशननुसार) असतात, त्यामुळे वेगवेगळ्या खात्यावर तुमच्याकडे वेगवेगळी भूमिका असू शकते.

आमच्या कंपनी डिरेक्टरीसाठी तुम्ही SSO ला सपोर्ट करता का?

होय. ओळख Keycloak वर OIDC आणि SAML सह चालते, त्यामुळे एंटरप्राइझ आणि एजन्सी ग्राहकांसाठीमॅजिक-लिंक लॉगिन, ईमेल आणि पासवर्ड, सोशल प्रदाते, पासkeys आणि TOTP टू-फॅक्टर प्रमाणीकरण यांच्यासोबत SAML सिंगल साइन-ऑन उपलब्ध आहे, ज्याची अंमलबजावणी धोरणाद्वारे केली जाते. एका सत्रात डॅशबोर्ड, सार्वजनिक साइट आणि नॉलेज बेस आणि सपोर्ट तिकिटे समाविष्ट आहेत.

बदला को णे केला हे मला कसे कळेल?

प्रत्येक विशेषाधिकारप्राप्त कृत्य एका ॲपेंड-ओन्ली (फक्त जोडता येणाऱ्या) ऑडिट लॉगमध्ये नोंदवले जाते, ज्यामध्ये कृत्य करणारी व्यक्ती, कृत्य, ते कोणावर केले गेले ते लक्ष्य, समर्थक पुरावे आणि IP ॲड्रेस यांची नोंद केली जाते. ते वाचणे हा स्वतःमध्येच एक अधिकार आहे, जो मालक (Owner) आणि फक्त-वाचनासाठी (Read-only) या दोन्ही भूमिकांकडे असतो, त्यामुळे खाते मालक आणि ऑडिटर दोघेही समान इतिहासाचे पुनरावलोकन करू शकतात.

टीम सदस्यांना जोडल्याने मी भरत असलेल्या रकमेत बदल होतो का?

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

मी प्रतिबद्ध hoण्यापूर्वी हे वापरून पाहू शकतो का?

होय. Footprint-Free चा ट्रायल १४ दिवस चालतो, यासाठी कार्ड तपशीलांची गरज नसते आणि हा ५ साईट्सपर्यंत कव्हर करतो, त्यामुळे तुम्ही पैसे देण्यापूर्वी तुमचे डिव्हाइस सेटअप करू शकता, तुमच्या टीमला आमंत्रण देऊ शकता आणि वास्तविक कामावर रोल्सची चाचणी घेऊ शकता. सशुल्क प्लॅन्ससाठी ३० दिवसांची मनी-बॅक गॅरंटी उपलब्ध आहे.

काहींच्या नाही, तर मिनिटांत तुमच्या टीमची रचना करा

फूटप्रिंट-फ्री (Footprint-Free) लाइनवर कार्डशिवाय १४ दिवसांची चाचणी सुरू करा, तुमच्या टीमला आमंत्रित करा आणि कोणतेही पैसे देण्यापूर्वी प्रत्यक्ष साइट्सवर भूमिका कशा काम करतात ते पहा.

विनाशुल्क सुरू करा