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 का इससे मिलान होना आवश्यक है:../acme जैसी ट्रैवर्सल स्ट्रिंग अस्वीकार कर दी जाती हैं।
ID कंटेनर नाम का हिस्सा बन जाती है: openclaw-cell-<tenant>।
fleet create
एक cell बनाएँ और उसे शुरू करें:
--env को दोहराकर टेनेंट-विशिष्ट पर्यावरण चर पास करें:
बनाने के विकल्प
स्वचालित आवंटन
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 का निरीक्षण करें:
ok, failed या skipped होता है। /healthz Gateway के सक्रिय होने को प्रमाणित करता है, प्रत्येक कॉन्फ़िगर किए गए चैनल या Plugin की पूर्ण तत्परता को नहीं। जाँच के लिए कोई उपयोग योग्य स्थानीय एंडपॉइंट न होने पर प्रोब छोड़ दिया जाता है।
fleet logs
किसी cell के कंटेनर लॉग को सीधे टर्मिनल पर स्ट्रीम करें:
--follow समाप्त करने के लिए Ctrl-C दबाएँ। लॉग आउटपुट एक संशोधन फ़िल्टर से होकर गुजरता है, जो टर्मिनल तक कुछ भी पहुँचने से पहले cell के वर्तमान Gateway टोकन को <redacted> से बदल देता है।
fleet logs में --json मोड नहीं है, क्योंकि कंटेनर लॉग एक कच्ची stdout/stderr स्ट्रीम हैं। स्क्रिप्ट के लिए आउटपुट को --tail से सीमित करें और सामान्य शेल पुनर्निर्देशन या पाइपलाइन का उपयोग करें।
fleet start, fleet stop, और fleet restart
किसी मौजूदा सेल को उसके दर्ज किए गए रनटाइम से नियंत्रित करें:
fleet upgrade
दर्ज की गई इमेज को फिर से पुल करें और सेल कंटेनर को बदलें:
--env के साथ मूल रूप से दिए गए मान सुरक्षित रखता है। माउंट की गई स्थिति कंटेनर प्रतिस्थापन के बाद भी बनी रहती है; लक्ष्य इमेज के साथ इमेज-डिफ़ॉल्ट परिवेश बदल सकता है।
प्रतिस्थापन केवल तभी प्रतिबद्ध किया जाता है जब उसका Gateway सेल के लूपबैक पोर्ट पर /healthz का उत्तर देता है, जो आधिकारिक कंपोज़ फ़ाइल द्वारा उपयोग किए जाने वाले स्वास्थ्य अनुबंध से मेल खाता है। जो प्रतिस्थापन बाहर निकल जाता है, क्रैश-लूप में फँसता है या लगभग एक मिनट के भीतर स्वस्थ नहीं होता, उसे हटा दिया जाता है और पिछला कंटेनर पुनर्स्थापित कर दिया जाता है, ताकि कोई खराब इमेज किसी कार्यशील सेल को बंद न कर दे।
Gateway टोकन को जानबूझकर Fleet रजिस्ट्री में संग्रहीत नहीं किया जाता। पुराना कंटेनर हटाने से पहले, 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
रनटाइम या फ़ाइल सिस्टम स्थिति बदले बिना प्रत्येक सेल या एक टेनेंट का ऑडिट करें:
fleet rm
टेनेंट डेटा रखते हुए किसी रुके हुए सेल को रनटाइम और रजिस्ट्री से हटाएँ:
--force आवश्यक है:
--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 आउटपुट का वर्णन करती है, न कि होस्ट प्रशासक के विरुद्ध सुरक्षा का।