मुख्य सामग्री पर जाएं

​
openclaw fleet

openclaw fleet cells कहलाने वाले पूर्ण OpenClaw इंस्टेंस का प्रबंधन करता है। प्रत्येक cell का अपना Gateway, स्थिति, क्रेडेंशियल, चैनल खाते, कंटेनर और केवल लूपबैक वाला होस्ट पोर्ट होता है। प्रत्येक टेनेंट विश्वास-सीमा के लिए एक cell का उपयोग करें; प्रतिकूल बहु-टेनेंट सीमा के रूप में एक साझा Gateway का उपयोग न करें। Fleet प्रायोगिक है। कमांड नाम, फ़्लैग, आउटपुट स्वरूप और कंटेनर प्रोफ़ाइल रिलीज़ के बीच बिना किसी बहिष्करण अवधि के बदल सकते हैं। Fleet Docker और Podman का समर्थन करता है। डिफ़ॉल्ट इमेज ghcr.io/openclaw/openclaw:latest है। Fleet का परीक्षण Linux और macOS होस्ट पर किया जाता है। Windows होस्ट वर्तमान में अपरीक्षित हैं।

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

fleet create जनरेट किया गया Gateway टोकन cell URL के साथ एक बार प्रिंट करता है। टोकन को तुरंत संग्रहीत करें, फिर प्रत्येक टेनेंट के चैनल खातों को उस टेनेंट के cell के भीतर कॉन्फ़िगर करें।

​
टेनेंट ID

टेनेंट ID का इससे मेल खाना आवश्यक है:
यह 1 से 40 लोअरकेस अक्षरों, अंकों और आंतरिक हाइफ़न की अनुमति देता है। ID का आरंभ और अंत किसी अक्षर या अंक से होना आवश्यक है। अपरकेस अक्षर, अंडरस्कोर, स्लैश, डॉट, रिक्त स्थान और ../acme जैसी ट्रैवर्सल स्ट्रिंग अस्वीकार कर दी जाती हैं। ID कंटेनर नाम का हिस्सा बन जाता है: openclaw-cell-<tenant>।

​
fleet create

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

​
निर्माण विकल्प

स्वचालित आवंटन 19100 या उससे ऊपर का पहला अप्रयुक्त रजिस्ट्री पोर्ट चुनता है। Fleet डुप्लिकेट टेनेंट ID और किसी अन्य cell को पहले से आवंटित स्पष्ट पोर्ट अस्वीकार करता है। इमेज संदर्भ एक कंटेनर-रनटाइम आर्ग्युमेंट के रूप में पास किए जाते हैं। रिक्त संदर्भ और - से शुरू होने वाले मान अस्वीकार कर दिए जाते हैं, ताकि किसी इमेज को Docker या Podman विकल्प के रूप में न समझा जा सके। चुना गया Docker या Podman एंडपॉइंट स्थानीय होना चाहिए। Fleet पोर्ट आरक्षित करने या स्थानीय स्थिति बनाने से पहले रिमोट Docker कॉन्टेक्स्ट, DOCKER_HOST एंडपॉइंट और रिमोट Podman सेवाओं को अस्वीकार करता है। रिमोट cell होस्ट समर्थित नहीं हैं। जब Fleet कोई नया cell शुरू करता है, तो create उसके Gateway द्वारा /healthz का उत्तर देने के लिए लगभग एक मिनट तक प्रतीक्षा करता है। यदि cell स्वस्थ नहीं होता, तो Fleet उसके कंटेनर और रजिस्ट्री पंक्ति को fleet status, fleet logs या स्पष्ट निष्कासन के लिए यथावत रखता है। --no-start इस स्वास्थ्य गेट को छोड़ देता है। किसी अस्वस्थ नए cell का जनरेट किया गया Gateway टोकन खोता नहीं है—वह कंटेनर पर्यावरण (docker|podman inspect) में बना रहता है, और क्योंकि cell ने अभी तक कोई ट्रैफ़िक नहीं संभाला है, इसलिए fleet rm --force के बाद नया create करना हमेशा एक सुरक्षित विकल्प है।

​
डाइजेस्ट द्वारा पिन करना

Create और upgrade --image ghcr.io/openclaw/openclaw@sha256:<digest> जैसे डाइजेस्ट-पिन किए गए इमेज संदर्भ स्वीकार करते हैं। Fleet इमेज संदर्भ को ज्यों का त्यों Docker या Podman को पास करता है, जिससे ऑपरेटर किसी cell को बदलते टैग के बजाय अपरिवर्तनीय इमेज बाइट्स पर रख सकता है। Create परिणाम में टेनेंट ID, कंटेनर नाम, होस्ट पोर्ट, Gateway टोकन और स्थानीय URL शामिल होते हैं। JSON आउटपुट में भी परिणाम को गोपनीय मानें, क्योंकि इसमें टोकन होता है।

​
डिस्क सीमाएँ

--disk केवल कंटेनर की लिखने योग्य परत को सीमित करता है। बाइंड-माउंट की गई प्रति-टेनेंट स्थिति और प्रमाणीकरण डायरेक्टरियाँ होस्ट स्टोरेज बनी रहती हैं; जब उन डायरेक्टरियों को भी कठोर सीमा की आवश्यकता हो, तब होस्ट फ़ाइल सिस्टम प्रोजेक्ट कोटा का उपयोग करें।

​
निर्गमन नीति

Docker के लिए, ब्रिज मोड बनाए रखें और DOCKER-USER चेन जैसे होस्ट फ़ायरवॉल नियमों से आउटबाउंड नीति लागू करें।

​
fleet list

cells को टेनेंट-ID क्रम में सूचीबद्ध करें:
तालिका में ये शामिल होते हैं: Docker या Podman अनुपलब्ध होने पर भी रजिस्ट्री पंक्तियाँ दिखाई देती रहती हैं; केवल लाइव स्थिति unknown हो जाती है।

​
fleet status

एक cell का निरीक्षण करें:
Status Fleet रजिस्ट्री पंक्ति, लाइव कंटेनर निरीक्षण और इसके लिए एक संक्षिप्त सर्वोत्तम-प्रयास अनुरोध को संयोजित करता है:
स्वास्थ्य परिणाम ok, failed या skipped होता है। /healthz Gateway की सक्रियता प्रमाणित करता है, प्रत्येक कॉन्फ़िगर किए गए चैनल या plugin की पूर्ण तत्परता नहीं। जाँचने के लिए कोई उपयोगी स्थानीय एंडपॉइंट न होने पर प्रोब छोड़ दिया जाता है।

​
fleet logs

किसी cell के कंटेनर लॉग सीधे टर्मिनल पर स्ट्रीम करें:
Fleet कोई भी लॉग पढ़ने से पहले पंजीकृत कंटेनर के स्वामित्व लेबल सत्यापित करता है, इसलिए यह अपेक्षित cell नाम का उपयोग करने वाले किसी बाहरी कंटेनर को अस्वीकार करता है। स्ट्रीम उस निरीक्षित कंटेनर ID पर पिन होती है, इसलिए समानांतर प्रतिस्थापन इसे किसी नई जनरेशन पर पुनर्निर्देशित नहीं कर सकता। ऑपरेटर द्वारा रोके जाने को कमांड विफलता माने बिना --follow समाप्त करने के लिए Ctrl-C दबाएँ। किसी भी सामग्री के टर्मिनल तक पहुँचने से पहले लॉग आउटपुट को एक संपादन फ़िल्टर से गुज़ारा जाता है, जो cell के वर्तमान Gateway टोकन को <redacted> से बदल देता है। fleet logs में --json मोड नहीं है, क्योंकि कंटेनर लॉग एक अपरिष्कृत stdout/stderr स्ट्रीम हैं। स्क्रिप्ट के लिए, आउटपुट को --tail से सीमित करें और सामान्य शेल पुनर्निर्देशन या पाइपलाइन का उपयोग करें।

​
fleet start, fleet stop, और fleet restart

किसी मौजूदा सेल को उसके दर्ज किए गए रनटाइम से नियंत्रित करें:
ये कमांड पंजीकृत कंटेनर नाम पर काम करते हैं। यदि टेनेंट अज्ञात है या दर्ज किया गया रनटाइम कार्रवाई नहीं कर सकता, तो ये विफल हो जाते हैं।

​
fleet upgrade

दर्ज की गई इमेज को फिर से पुल करें और सेल कंटेनर को बदलें:
सेल को किसी अन्य इमेज पर ले जाएँ:
अपग्रेड लक्ष्य इमेज को पुल करता है, मौजूदा कंटेनर और प्रति-सेल नेटवर्क का निरीक्षण करता है, कंटेनर को रोककर हटाता है, फिर उसे दोबारा बनाकर शुरू करता है। प्रतिस्थापन वही होस्ट पोर्ट, डेटा डायरेक्टरियाँ, प्रति-सेल ब्रिज नेटवर्क, रनटाइम प्रोफ़ाइल, संसाधन सीमाएँ, रीस्टार्ट नीति, Fleet-प्रबंधित परिवेश और मूल रूप से --env के साथ दिए गए मान सुरक्षित रखता है। माउंट की गई स्थिति कंटेनर प्रतिस्थापन के बाद भी बनी रहती है; लक्ष्य इमेज के साथ इमेज-डिफ़ॉल्ट परिवेश बदल सकता है। प्रतिस्थापन तभी प्रतिबद्ध किया जाता है, जब उसका Gateway सेल के लूपबैक पोर्ट पर /healthz का उत्तर देता है और आधिकारिक कंपोज़ फ़ाइल द्वारा उपयोग किए जाने वाले स्वास्थ्य अनुबंध से मेल खाता है। जो प्रतिस्थापन बंद हो जाता है, क्रैश-लूप में चला जाता है या लगभग एक मिनट में स्वस्थ नहीं हो पाता, उसे हटा दिया जाता है और पिछला कंटेनर पुनर्स्थापित कर दिया जाता है, ताकि कोई खराब इमेज कार्यरत सेल को बंद न कर दे। Gateway टोकन को जानबूझकर फ्लीट रजिस्ट्री में संग्रहीत नहीं किया जाता। पुराना कंटेनर हटाने से पहले, Fleet उसका परिवेश पढ़ता है और OPENCLAW_GATEWAY_TOKEN को प्रतिस्थापन में ले जाता है। यदि टोकन आपके नियंत्रण में कहीं और मौजूद नहीं है, तो अपग्रेड से पहले पुराने कंटेनर को मैन्युअल रूप से न हटाएँ।

​
fleet backup और fleet restore

रुके हुए एक सेल का बैकअप लें:
उस आर्काइव को पंजीकृत सेल में पुनर्स्थापित करें:
ये होस्ट-ऑपरेटर-विशेषाधिकार वाले कमांड हैं। आर्काइव में टेनेंट स्थिति और प्रमाणीकरण सीक्रेट होते हैं, इन्हें मोड 0600 के साथ बनाया जाता है और इन्हें क्रेडेंशियल की तरह संग्रहीत करना अनिवार्य है। बैकअप किसी चल रहे सेल को अस्वीकार करता है, ताकि SQLite स्थिति को संगत रूप से कैप्चर किया जा सके। जब तक --force न दिया जाए, पुनर्स्थापना किसी चल रहे सेल को अस्वीकार करती है, केवल उस टेनेंट की स्थिति बदलती है, Gateway टोकन को रोटेट करती है और नया टोकन एक बार प्रिंट करती है। Fleet एक समय में एक टेनेंट का बैकअप लेता है; सभी टेनेंट का बैकअप एक अलग ऑपरेटर कार्रवाई है। पुनर्स्थापना के लिए एक मौजूदा रुका हुआ कंटेनर आवश्यक है, क्योंकि उसकी निरीक्षित रनटाइम प्रोफ़ाइल प्रतिस्थापन की सीमाएँ, उपयोगकर्ता मैपिंग, परिवेश का उद्गम और इमेज प्रदान करती है। यदि पंजीकृत कंटेनर को बाहरी तरीके से हटा दिया गया था, तो पहले --purge-data के बिना fleet rm <tenant> --force चलाएँ, इच्छित इमेज और --no-start के साथ सेल को दोबारा बनाएँ, फिर पुनर्स्थापना का पुनः प्रयास करें। पहला निष्कासन दोनों टेनेंट डेटा डायरेक्टरियों को अक्षुण्ण रखता है। दोनों कमांड आर्काइव या निकाले गए फ़ाइल डेटा की सीमा तय करने के लिए --max-bytes <bytes> स्वीकार करते हैं, और दोनों आर्काइव पाथ सेगमेंट के लिए दस लाख की समान निश्चित सीमा लागू करते हैं, ताकि केवल-मेटाडेटा वाले आर्काइव बम होस्ट इनोड समाप्त न कर सकें और प्रत्येक स्वीकृत बैकअप पुनर्स्थापित करने योग्य रहे। बैकअप --out <path> स्वीकार करता है और दोनों कमांड --json का समर्थन करते हैं। आर्काइव में केवल नियमित फ़ाइलें और डायरेक्टरियाँ होती हैं। बैकअप कभी भी सिमलिंक, हार्ड लिंक, सॉकेट या डिवाइस नोड का अनुसरण या संग्रह नहीं करता; छोड़ी गई प्रविष्टियों की संख्या परिणाम में बताई जाती है। पुनर्स्थापना किसी अन्य प्रविष्टि प्रकार वाले आर्काइव को अस्वीकार करती है। पुनः बनाए जा सकने वाले सिमलिंक ट्री, जैसे वर्कस्पेस node_modules, को पुनर्स्थापना के बाद सेल के भीतर दोबारा इंस्टॉल करना आवश्यक है।

​
fleet doctor

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

​
fleet rm

टेनेंट डेटा रखते हुए किसी रुके हुए सेल को रनटाइम और रजिस्ट्री से हटाएँ:
चल रहे कंटेनर के लिए --force आवश्यक है:
सेल डेटा को भी स्थायी रूप से हटाएँ:
Fleet सेल के समर्पित ब्रिज नेटवर्क को हटाने से पहले सेल कंटेनर को हटाता है। --purge-data के लिए --force आवश्यक है। पुनरावर्ती विलोपन से पहले, Fleet दोनों Fleet-स्वामित्व वाले रूट और दोनों प्रति-टेनेंट डायरेक्टरियों को रिज़ॉल्व करता है। प्रत्येक लक्ष्य बिल्कुल अपेक्षित टेनेंट लीफ़ होना चाहिए, अपने रूट के सख्ती से भीतर होना चाहिए और सिमलिंक नहीं होना चाहिए। ये अंतर्वेशन जाँचें किसी दूषित रजिस्ट्री पाथ या क्रॉस-टेनेंट सिमलिंक को विलोपन कहीं और पुनर्निर्देशित करने से रोकती हैं। यदि कोई बिल्कुल अपेक्षित टेनेंट डायरेक्टरी पहले से अनुपस्थित है, तो पर्ज का पुनः प्रयास किया जा सकता है। इससे बाद का आह्वान आंशिक फ़ाइल सिस्टम विफलता के बाद सफ़ाई पूरी कर सकता है, जबकि अभी भी मौजूद डायरेक्टरियों के लिए पाथ जाँचों में ढील नहीं दी जाती।

​
स्टोरेज और कंटेनर लेआउट

सेल स्थिति और प्रमाणीकरण-प्रोफ़ाइल एन्क्रिप्शन कुंजियाँ सक्रिय OpenClaw स्थिति डायरेक्टरी के अंतर्गत अलग-अलग प्रति-टेनेंट होस्ट पाथ का उपयोग करती हैं:
पहली डायरेक्टरी /home/node/.openclaw पर माउंट की जाती है। दूसरी /home/node/.config/openclaw पर माउंट की जाती है, जो आधिकारिक Docker सेटअप के एन्क्रिप्शन-कुंजी माउंट से मेल खाती है। इसलिए एन्क्रिप्शन कुंजी सामान्य स्थिति माउंट के नीचे उजागर नहीं होती या केवल सेल-स्थिति डायरेक्टरी का बैकअप लेने अथवा साझा करने पर शामिल नहीं होती। दोनों डायरेक्टरियाँ सामान्य निष्कासन और अपग्रेड के बाद भी बनी रहती हैं; fleet rm --purge-data --force अलग-अलग अंतर्वेशन जाँचों के बाद दोनों को हटा देता है। पहली बार शुरू करने से पहले, Fleet सेल कॉन्फ़िगरेशन को gateway.mode=local, टोकन प्रमाणीकरण, LAN कंटेनर बाइंड और आवंटित होस्ट पोर्ट के लिए Control UI ओरिजिन के साथ आरंभ करता है। टोकन मान उस कॉन्फ़िगरेशन में नहीं लिखा जाता; वह कंटेनर परिवेश में रहता है। Fleet इन परिवेश मानों के साथ आधिकारिक इमेज के कंटेनर पाथ को पिन करता है: आधिकारिक इमेज डिफ़ॉल्ट रूप से UID 1000 वाले गैर-रूट node उपयोगकर्ता का उपयोग करती है। Fleet निजी 0700 बाइंड माउंट को सभी के लिए सुलभ बनाए बिना लिखने योग्य रखता है। रूटफ़ुल Docker सेल को आह्वान करने वाले गैर-रूट UID और GID के साथ चलाता है; रूटलेस Docker कंटेनर UID 0 का उपयोग करता है, जो डेमन के उपयोगकर्ता नेमस्पेस के भीतर आह्वान करने वाले गैर-विशेषाधिकार प्राप्त होस्ट उपयोगकर्ता से मैप होता है। Podman आह्वान करने वाले UID और GID के साथ keep-id का उपयोग करता है। जब Fleet स्वयं किसी रूटफ़ुल रनटाइम के विरुद्ध रूट के रूप में चलता है, तो यह इमेज उपयोगकर्ता को बनाए रखता है और प्रारंभिक माउंट फ़ाइलें UID/GID 1000 को सौंपता है। SELinux होस्ट पर, Docker और Podman माउंट को निजी :Z रीलेबल मिलता है। यदि आप सेल डेटा पुनर्स्थापित या स्थानांतरित करते हैं, तो बाइंड-माउंट किए गए पाथ को प्रभावी कंटेनर उपयोगकर्ता के लिए लिखने योग्य रखें। प्रोफ़ाइल रूटलेस-अनुकूल है, लेकिन Docker या Podman को होस्ट पर रूटलेस संचालन के लिए पहले से कॉन्फ़िगर किया जाना चाहिए; Fleet किसी रूटफ़ुल डेमन को रूटलेस में परिवर्तित नहीं करता।

​
सुरक्षा प्रोफ़ाइल

Fleet प्रत्येक सेल पर निम्न प्रोफ़ाइल लागू करता है: Fleet कभी भी /var/run/docker.sock माउंट नहीं करता, --privileged या होस्ट नेटवर्किंग का उपयोग नहीं करता और क्षमताएँ नहीं जोड़ता। प्रति-सेल ब्रिज क्रॉस-सेल पृथक्करण सीमा है, आउटबाउंड फ़ायरवॉल नहीं: सेल प्रदाताओं और चैनलों के लिए आवश्यक नेटवर्क ईग्रेस बनाए रखते हैं। लूपबैक पोर्ट के आगे ऐसा प्रॉक्सी, SSH टनल या टेलनेट कॉन्फ़िगरेशन रखें, जो आपके परिनियोजन से मेल खाता हो। http://127.0.0.1:<port> केवल Fleet होस्ट से सीधे पहुँच योग्य है। यह प्रोफ़ाइल टेनेंट कंटेनरों को अलग करती है, लेकिन यह टेनेंट को Fleet ऑपरेटर, कंटेनर रनटाइम प्रशासक या किसी समझौता किए गए होस्ट से सुरक्षित नहीं करती। पूर्ण विश्वास मॉडल और अधिक सशक्त पृथक्करण विकल्पों के लिए बहु-टेनेंट होस्टिंग देखें।

​
टोकन प्रबंधन

डिफ़ॉल्ट रूप से, fleet create क्रिप्टोग्राफ़िक रूप से यादृच्छिक 32-वर्णीय हेक्साडेसिमल Gateway टोकन जनरेट करता है और उसे निर्माण परिणाम में एक बार प्रिंट करता है। उसे अपने स्वीकृत सीक्रेट मैनेजर में संग्रहीत करें और निर्माण आउटपुट को लॉग में कैप्चर करने से बचें। --gateway-token स्थानीय प्रक्रिया आर्ग्युमेंट में एक कस्टम टोकन रखता है, जो शेल इतिहास में बना रह सकता है या प्रक्रिया सूचियों में दिखाई दे सकता है। जब तक किसी मौजूदा सीक्रेट-प्रबंधन कार्यप्रवाह को दिए गए मान की आवश्यकता न हो, जनरेट किए गए टोकन को प्राथमिकता दें। टोकन और --env के साथ दिया गया प्रत्येक मान कंटेनर परिवेश में रहता है। Fleet उन्हें अल्पकालिक मोड-0600 परिवेश फ़ाइल में लिखता है, Docker या Podman को केवल उस फ़ाइल का पाथ देता है और रनटाइम कमांड समाप्त होने के बाद उसे हटा देता है। openclaw fleet create --gateway-token ... या --env KEY=VALUE में स्पष्ट रूप से टाइप किए गए मान फिर भी बाहरी openclaw प्रक्रिया आर्ग्युमेंट और शेल इतिहास में दिखाई दे सकते हैं। कंटेनर एनवायरनमेंट मान विश्वसनीय होस्ट ऑपरेटर से छिपे नहीं होते: Docker या Podman प्रशासक कंटेनर निरीक्षण के माध्यम से उन्हें पढ़ सकते हैं। Fleet की “केवल एक बार दिखाया गया” टिप्पणी सामान्य CLI आउटपुट का वर्णन करती है, न कि होस्ट प्रशासक के विरुद्ध सुरक्षा का।

​
संबंधित