इस पेज पर
इस पेज पर
Get started
बेड़ा
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-टोकन चरों को ओवरराइड करने के प्रयासों को अस्वीकार करता है।
बनाने के विकल्प
| विकल्प | डिफ़ॉल्ट | विवरण |
|---|---|---|
--image <ref> |
ghcr.io/openclaw/openclaw:latest |
cell के लिए कंटेनर इमेज। |
--runtime <runtime> |
docker |
कंटेनर CLI: docker या podman। |
--port <number> |
19100 से स्वचालित रूप से आवंटित |
लूपबैक होस्ट पोर्ट। स्पष्ट रूप से चयनित पोर्ट किसी अन्य पंजीकृत cell से संबंधित नहीं होना चाहिए। |
--memory <value> |
2g |
Docker/Podman सिंटैक्स में कंटेनर मेमोरी सीमा। |
--cpus <value> |
2 |
कंटेनर CPU सीमा। |
--disk <size> |
कोई नहीं | जब स्टोरेज बैकएंड कोटा का समर्थन करता हो, तब कंटेनर की लिखने योग्य परत को सीमित करें। |
--network <mode> |
bridge |
आउटबाउंड नेटवर्क मोड: bridge या internal। |
--pids-limit <number> |
512 |
कंटेनर में प्रक्रियाओं की अधिकतम संख्या। |
--env <KEY=VALUE> |
कोई नहीं | cell को पर्यावरण चर पास करें। एकाधिक मानों के लिए दोहराएँ। |
--gateway-token <value> |
यादृच्छिक 32-वर्णीय हेक्साडेसिमल टोकन | जनरेट करने के बजाय दिया गया Gateway टोकन उपयोग करें। टोकन प्रबंधन देखें। |
--no-start |
cell शुरू होता है | कंटेनर को शुरू किए बिना बनाएँ। |
--json |
मानव-पठनीय आउटपुट | मशीन-पठनीय आउटपुट प्रिंट करें। |
स्वचालित आवंटन 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 केवल कंटेनर की लिखने योग्य परत को सीमित करता है। बाइंड-माउंट की गई प्रति-टेनेंट स्थिति और प्रमाणीकरण डायरेक्टरियाँ होस्ट स्टोरेज बनी रहती हैं; जब उन डायरेक्टरियों को भी कठोर सीमा की आवश्यकता हो, तब होस्ट फ़ाइल सिस्टम प्रोजेक्ट कोटा का उपयोग करें।
| रनटाइम/स्टोरेज बैकएंड | --disk समर्थन |
|---|---|
| XFS पर Docker overlay2 | XFS pquota माउंट विकल्प आवश्यक है। |
| Docker btrfs या zfs | स्टोरेज ड्राइवर द्वारा समर्थित। |
| Podman overlay | XFS बैकिंग स्टोरेज आवश्यक है। |
| अन्य बैकएंड | डेमन त्रुटि और Fleet के बैकएंड मार्गदर्शन के साथ कंटेनर निर्माण विफल हो जाता है। |
इग्रेस नीति
| मोड | Docker | Podman |
|---|---|---|
bridge |
समर्थित; डिफ़ॉल्ट रूप से आउटबाउंड इग्रेस अप्रतिबंधित है। | समर्थित; डिफ़ॉल्ट रूप से आउटबाउंड इग्रेस अप्रतिबंधित है। |
internal |
अस्वीकार किया जाता है क्योंकि Docker किसी आंतरिक नेटवर्क पर प्रकाशित लूपबैक Gateway पोर्ट को बनाए नहीं रखता। | समर्थित; आउटबाउंड इग्रेस अवरुद्ध रहने के दौरान लूपबैक Gateway प्रकाशित रहता है। |
Docker के लिए ब्रिज मोड बनाए रखें और DOCKER-USER चेन जैसे होस्ट फ़ायरवॉल नियमों के साथ आउटबाउंड नीति लागू करें।
fleet list
cells को टेनेंट-ID क्रम में सूचीबद्ध करें:
तालिका में ये शामिल हैं:
| कॉलम | अर्थ |
|---|---|
tenant |
टेनेंट ID। |
state |
Docker या Podman निरीक्षण से प्राप्त लाइव कंटेनर स्थिति। unknown का अर्थ है कि रनटाइम अनुपलब्ध था, या cell के नाम वाला कंटेनर मौजूद है लेकिन उसके Fleet स्वामित्व लेबल रजिस्ट्री रिकॉर्ड से मेल नहीं खाते (टकराव या छेड़छाड़ का संकेत—कार्रवाई करने से पहले उसका मैन्युअल निरीक्षण करें)। |
port |
cell Gateway से मैप किया गया लूपबैक होस्ट पोर्ट। |
image |
रिकॉर्ड की गई कंटेनर इमेज। |
created |
cell निर्माण समय। |
Docker या Podman अनुपलब्ध होने पर रजिस्ट्री पंक्तियाँ दिखाई देती रहती हैं; केवल लाइव स्थिति unknown हो जाती है।
fleet status
किसी एक cell का निरीक्षण करें:
स्थिति 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 रजिस्ट्री में संग्रहीत नहीं किया जाता। पुराना कंटेनर हटाने से पहले, 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 इन परिवेश मानों के साथ आधिकारिक इमेज के कंटेनर पाथ को पिन करता है:
| वेरिएबल | कंटेनर मान |
|---|---|
HOME |
/home/node |
OPENCLAW_HOME |
/home/node |
OPENCLAW_STATE_DIR |
/home/node/.openclaw |
OPENCLAW_CONFIG_PATH |
/home/node/.openclaw/openclaw.json |
OPENCLAW_WORKSPACE_DIR |
/home/node/.openclaw/workspace |
OPENCLAW_GATEWAY_TOKEN |
जेनरेट किया गया या दिया गया सेल टोकन |
आधिकारिक इमेज डिफ़ॉल्ट रूप से 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 प्रत्येक सेल पर निम्न प्रोफ़ाइल लागू करता है:
| नियंत्रण | लागू प्रोफ़ाइल | कारण |
|---|---|---|
| Linux क्षमताएँ | --cap-drop=ALL |
Gateway एक Node.js प्रक्रिया है और उसे किसी अतिरिक्त Linux क्षमता की आवश्यकता नहीं है। |
| विशेषाधिकार वृद्धि | --security-opt no-new-privileges |
प्रक्रियाओं को setuid या setgid बाइनरी के माध्यम से विशेषाधिकार प्राप्त करने से रोकता है। |
| इनिट प्रक्रिया | --init |
वंशज प्रक्रियाओं को रीप करता है और कंटेनर जीवनचक्र सिग्नल अग्रेषित करता है। |
| प्रक्रिया सीमा | डिफ़ॉल्ट रूप से --pids-limit 512 |
फोर्क और प्रक्रिया समाप्ति को सीमित करता है। |
| मेमोरी सीमा | डिफ़ॉल्ट रूप से --memory 2g |
सेल के मेमोरी उपयोग को सीमित करता है। |
| CPU सीमा | डिफ़ॉल्ट रूप से --cpus 2 |
सेल के CPU उपयोग को सीमित करता है। |
| लिखने योग्य-लेयर डिस्क | वैकल्पिक --disk |
जब रनटाइम स्टोरेज बैकएंड कोटा का समर्थन करता है, तब कंटेनर लेयर को सीमित करता है। |
| रीस्टार्ट नीति | --restart unless-stopped |
जानबूझकर रोके जाने को ओवरराइड किए बिना विफल सेल को रीस्टार्ट करता है। |
| होस्ट प्रकाशन | केवल 127.0.0.1:<host-port>:18789 |
Gateway को वाइल्डकार्ड होस्ट इंटरफ़ेस से दूर रखता है। |
| सेल नेटवर्क | प्रत्येक सेल के लिए एक ब्रिज या Podman आंतरिक नेटवर्क | कंटेनर-IP ट्रैफ़िक को अलग करता है और वैकल्पिक रूप से Podman के आउटबाउंड इग्रेस को अवरुद्ध करता है। |
| कंटेनर पहचान | होस्ट से मेल खाने वाली उपयोगकर्ता मैपिंग | विश्व प्रवेश दिए बिना निजी बाइंड माउंट को लिखने योग्य रखता है। |
| स्थायी स्थिति | प्रति-सेल माउंट; कोई साझा स्थिति माउंट नहीं | टेनेंट कॉन्फ़िगरेशन, क्रेडेंशियल, सत्र और वर्कस्पेस को उस टेनेंट के डेटा ट्री में रखता है। |
| कंटेनर कमांड | node dist/index.js gateway --bind lan --port 18789 |
कंटेनर नेटवर्क पर सुनता है ताकि केवल-लूपबैक होस्ट पोर्ट मैपिंग उस तक पहुँच सके। |
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 आउटपुट का वर्णन करती है, न कि होस्ट प्रशासक के विरुद्ध सुरक्षा का।