---
doc-schema-version: 1
read_when:
    - आप कई उपयोगकर्ताओं या संगठनों के लिए OpenClaw होस्ट कर रहे हैं
    - आपको टेनेंट वर्कलोड के लिए एक आइसोलेशन सीमा चुननी होगी
summary: प्रत्येक टेनेंट के लिए एक पृथक OpenClaw Gateway सेल के रूप में कई टेनेंट विश्वास डोमेन होस्ट करें
title: बहु-किरायेदार होस्टिंग
x-i18n:
    generated_at: "2026-07-16T14:53:33Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    prompt_version: 32
    provider: openai
    source_hash: 383d32331b45d40db6fb4ff8242dd9a3cf8898a3ccab19f0372cd06bbd83fc05
    source_path: gateway/multi-tenant-hosting.md
    workflow: 16
---

# बहु-किरायेदार होस्टिंग

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

`openclaw fleet` प्रत्येक पृथक इंस्टेंस को एक **सेल** कहता है। सेल एक सुदृढ़ कंटेनर में पूर्ण Gateway होता है, जिसकी अपनी स्थिति, क्रेडेंशियल, कार्यस्थान, चैनल खाते, टोकन और केवल लूपबैक वाला होस्ट पोर्ट होता है।

Fleet **प्रायोगिक** है: इसके कमांड, फ़्लैग और कंटेनर प्रोफ़ाइल रिलीज़ के बीच बिना किसी बहिष्करण अवधि के बदल सकते हैं।

Fleet का परीक्षण Linux और macOS होस्ट पर किया गया है। Windows होस्ट का फ़िलहाल परीक्षण नहीं किया गया है।

## प्रत्येक किरायेदार को सेल की आवश्यकता क्यों है

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

प्रत्येक किरायेदार के लिए एक सेल का उपयोग करें, ताकि हर विश्वास डोमेन के पास अलग Gateway प्रक्रिया, कंटेनर, स्थायी स्थिति ट्री और Gateway क्रेडेंशियल हो। यह [Gateway सुरक्षा मॉडल](/hi/gateway/security) का पालन करता है: परस्पर अविश्वसनीय उपयोगकर्ताओं को एक OpenClaw प्रक्रिया या एक OS उपयोगकर्ता में साथ न रखें।

## आर्किटेक्चर

Fleet CLI होस्ट-साइड जीवनचक्र पर्यवेक्षक है। यह OpenClaw स्थिति डेटाबेस में सेल दर्ज करता है और स्थानीय Docker या Podman रनटाइम से उनके कंटेनर बनाने, निरीक्षण करने, शुरू करने, रोकने, बदलने और हटाने को कहता है। रिमोट रनटाइम एंडपॉइंट समर्थित नहीं हैं, क्योंकि Fleet के बाइंड पथ और लूपबैक URL स्थानीय होस्ट से संबंधित होते हैं। Fleet किरायेदार संदेशों को प्रॉक्सी नहीं करता और सेल के बीच कोई साझा एप्लिकेशन-स्तरीय डेटा पथ नहीं जोड़ता।

प्रत्येक सेल अपने उपयोगकर्ता-परिभाषित ब्रिज नेटवर्क पर आधिकारिक `ghcr.io/openclaw/openclaw` इमेज चलाता है। अलग ब्रिज प्रदाताओं और चैनलों के लिए आउटबाउंड NAT पहुँच बनाए रखते हुए सेल के बीच सीधे कंटेनर-IP ट्रैफ़िक को रोकते हैं। आउटबाउंड निकास डिफ़ॉल्ट रूप से अप्रतिबंधित होता है। Podman सेल प्रकाशित लूपबैक Gateway पोर्ट को बनाए रखते हुए निकास अवरुद्ध करने के लिए `--network internal` का उपयोग कर सकते हैं। Docker के आंतरिक नेटवर्क उस प्रकाशित पोर्ट को निष्क्रिय कर देते हैं, इसलिए Fleet इस संयोजन को अस्वीकार करता है; इसके बजाय `DOCKER-USER` चेन जैसे होस्ट फ़ायरवॉल नियमों से Docker निकास नीति लागू करें। सेल Gateway कंटेनर के भीतर पोर्ट `18789` पर सुनता है, जबकि रनटाइम इसे होस्ट पर केवल `127.0.0.1:<allocated-port>` पर प्रकाशित करता है। रिमोट पहुँच आवश्यक होने पर ऑपरेटर उस लूपबैक एंडपॉइंट के आगे अनुमोदित रिवर्स प्रॉक्सी, SSH टनल या टेलनेट रख सकता है।

स्थायी Gateway स्थिति `<state-dir>/fleet/cells/<tenant>/` से आती है और `/home/node/.openclaw` पर माउंट होती है। प्रमाणीकरण-प्रोफ़ाइल एन्क्रिप्शन कुंजियाँ अलग `<state-dir>/fleet/auth-profile-secrets/<tenant>/` होस्ट पथ से आती हैं और आधिकारिक [Docker स्थायित्व लेआउट](/hi/install/docker#storage-and-persistence) के अनुरूप `/home/node/.config/openclaw` पर माउंट होती हैं। कुंजी सामान्य स्थिति माउंट के अंतर्गत नेस्टेड नहीं होती। प्रत्येक किरायेदार के चैनल खाते उनका स्वामित्व रखने वाले सेल के भीतर समाप्त होते हैं; Fleet कोई साझा चैनल खाता या इनबाउंड संदेश राउटर प्रदान नहीं करता।

आधिकारिक इमेज डिफ़ॉल्ट रूप से UID 1000 वाले गैर-रूट `node` उपयोगकर्ता का उपयोग करती है। Fleet होस्ट-संगत उपयोगकर्ता मैपिंग का उपयोग करता है, ताकि निजी बाइंड माउंट लिखने योग्य बने रहें: Podman `keep-id` का उपयोग करता है, रूटफ़ुल Docker आह्वान करने वाली गैर-रूट पहचान का उपयोग करता है और रूटलेस Docker कंटेनर रूट को विशेषाधिकार-रहित डेमन उपयोगकर्ता से मैप करता है। होस्ट SELinux सक्रिय होने पर Docker और Podman निजी `:Z` रीलेबल लागू करते हैं। कंटेनर प्रोफ़ाइल विशेषाधिकार-युक्त होस्ट सुविधाओं से बचती है और रूटलेस-अनुकूल है, लेकिन रूटलेस संचालन होस्ट रनटाइम का विकल्प और पूर्वापेक्षा है, Fleet इसे स्वतः सक्षम नहीं करता।

## विश्वास सीमा

बहु-किरायेदारी किरायेदारों को एक-दूसरे से सुरक्षित रखती है। Fleet ऑपरेटर और होस्ट पर प्रत्येक किरायेदार विश्वास करता है। समझौता किए गए होस्ट के विरुद्ध प्रतिरोध इसका लक्ष्य नहीं है।

इसका अर्थ है कि होस्ट व्यवस्थापक कंटेनर कॉन्फ़िगरेशन और परिवेश का निरीक्षण कर सकता है, माउंट किया गया सेल डेटा पढ़ सकता है, इमेज बदल सकता है या कंटेनर में प्रवेश कर सकता है। Gateway टोकन और `--env` के साथ दिए गए मान Docker या Podman निरीक्षण के माध्यम से व्यवस्थापक को दिखाई देते हैं। तदनुसार होस्ट नियंत्रणों, प्रशासनिक पहुँच नीति, निगरानी, बैकअप और अनुमोदित सीक्रेट मैनेजर का उपयोग करें।

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

## पृथक्करण क्रम

होस्ट किए जाने वाले किरायेदारों से मेल खाने वाली सीमा चुनें:

1. **सुदृढ़ कंटेनर बेसलाइन।** Fleet सभी Linux क्षमताएँ हटा देता है, `no-new-privileges` सक्षम करता है, PID, मेमोरी, CPU और वैकल्पिक लिखने योग्य-लेयर डिस्क सीमाएँ लागू करता है, अलग स्थायी माउंट और प्रत्येक सेल के लिए अलग नेटवर्क उपयोग करता है और केवल होस्ट लूपबैक पर प्रकाशित करता है। ब्रिज नेटवर्किंग निकास को अप्रतिबंधित छोड़ती है; जब किसी सेल को आउटबाउंड कनेक्शन आरंभ नहीं करने चाहिए, तब Podman `--network internal` या Docker होस्ट फ़ायरवॉल नीति का उपयोग करें। ऑपरेटर और होस्ट पर विश्वास करने वाले किरायेदारों के लिए यह डिफ़ॉल्ट प्रोफ़ाइल है।
2. **अधिक सशक्त कंटेनर या VM पृथक्करण।** अधिक जोखिम वाले कार्यभारों के लिए Docker या Podman को gVisor या Kata Containers जैसे अधिक सशक्त OCI पृथक्करण रनटाइम का उपयोग करने हेतु कॉन्फ़िगर करें, या सेल को microVM में रखें। यह रनटाइम या अवसंरचना कॉन्फ़िगरेशन है; Fleet का `--runtime docker|podman` विकल्प कंटेनर CLI चुनता है, OCI पृथक्करण बैकएंड नहीं। Docker के [वैकल्पिक कंटेनर रनटाइम](https://docs.docker.com/engine/daemon/alternative-runtimes/) और [Docker VM रनटाइम मार्गदर्शिका](/hi/install/docker-vm-runtime) देखें।
3. **अविश्वसनीय किरायेदारों के लिए अलग मशीनें।** अविश्वसनीय किरायेदारों को एक OpenClaw प्रक्रिया या OS उपयोगकर्ता में साथ न रखें। जब किरायेदार एक ही होस्ट ऑपरेटर पर विश्वास नहीं करते या उन्हें अधिक सशक्त प्रशासनिक सीमा चाहिए, तब अलग रनटाइम प्रशासन वाले अलग VM या भौतिक होस्ट का उपयोग करें।

इस क्रम का कोई भी स्तर OpenClaw एप्लिकेशन विश्वास मॉडल को नहीं बदलता: एक Gateway एक विश्वसनीय ऑपरेटर डोमेन ही रहता है।

## त्वरित शुरुआत

एक सेल बनाएँ। कमांड जनरेट किया गया Gateway टोकन एक बार प्रिंट करता है, इसलिए उसे तुरंत संग्रहित करें:

```bash
openclaw fleet create acme
```

Fleet होस्ट पर रिपोर्ट किया गया `http://127.0.0.1:<port>` URL खोलें, उस किरायेदार के टोकन से प्रमाणित करें और सेल के भीतर प्रदाता क्रेडेंशियल तथा चैनल खाते कॉन्फ़िगर करें।

कंटेनर स्थिति और Gateway की सक्रियता जाँचें:

```bash
openclaw fleet status acme
```

होस्ट पोर्ट, माउंट किया गया डेटा, संसाधन प्रोफ़ाइल, उपयोगकर्ता द्वारा दिया गया परिवेश और Gateway टोकन सुरक्षित रखते हुए अपग्रेड करें:

```bash
openclaw fleet upgrade acme
```

किरायेदार डेटा बनाए रखते हुए कंटेनर और रजिस्ट्री पंक्ति हटाएँ:

```bash
openclaw fleet rm acme --force
```

स्थायी किरायेदार डेटा भी हटाने के लिए `--purge-data` जोड़ें। पूर्ण विलोपन के लिए `--force` आवश्यक है, यह अपरिवर्तनीय है और कुछ भी हटाने से पहले समाधान किए गए पथ की समावेशन जाँच करता है:

```bash
openclaw fleet rm acme --purge-data --force
```

हर कमांड और विकल्प के लिए [`openclaw fleet` CLI संदर्भ](/hi/cli/fleet) देखें।

## वर्तमान दायरा

Fleet ये सुविधाएँ प्रदान नहीं करता:

- साझा चैनल खाते या साझा इनग्रेस राउटर
- पूर्ण OpenClaw इंस्टेंस के बजाय छोटे किए गए प्रत्येक-किरायेदार होस्ट प्रक्रियाएँ
- एक पर्यवेक्षक द्वारा प्रबंधित रिमोट सेल होस्ट
- किरायेदार स्व-सेवा पोर्टल, बिलिंग प्लेन या प्रत्यायोजित प्रशासन UI

इन क्षमताओं के लिए स्पष्ट पहचान, रूटिंग, प्राधिकरण और विफलता-डोमेन अनुबंधों की आवश्यकता है। एक Gateway या उसके क्रेडेंशियल को किरायेदारों के बीच साझा करके इनका अनुमानित विकल्प न बनाएँ। Fleet एकल-होस्ट जीवनचक्र पर्यवेक्षक है; बहु-मशीन, पहचान-शासित Fleet के लिए अलग नियंत्रण-प्लेन परत आवश्यक है।

## संबंधित

- [`openclaw fleet`](/hi/cli/fleet)
- [Gateway सुरक्षा](/hi/gateway/security)
- [एकाधिक Gateway](/hi/gateway/multiple-gateways)
- [Docker](/hi/install/docker)
- [Podman](/hi/install/podman)