OpenBot AI coworkers को VPS पर self-host कैसे करें

OpenBot AI coworkers को self-host करने पर आपको क्या मिलता है

आप OpenBot AI coworkers को अपने नियंत्रण वाले हार्डवेयर पर एक gateway सर्वर और प्रति bot एक container चलाकर self-host करते हैं। प्रत्येक bot container में अपना स्वयं का Chromium browser और अपना workspace volume होता है, जिसमें एक browser profile होती है जो sessions के बीच बनी रहती है। एक bot द्वारा कंप्यूटर, फ़ाइल, MCP (model context protocol) सर्वर या UI घटक पर की जाने वाली प्रत्येक क्रिया उस gateway से होकर गुजरती है, जो इसे होने से पहले एक policy के विरुद्ध जाँचता है और होने के बाद उसे record करता है।

OpenBot को CopilotKit द्वारा MIT license के तहत github.com/CopilotKit/openbot पर प्रकाशित किया गया है। पहला tagged release, v0.0.1, 17 August 2026 को प्रकाशित किया गया था, और यह प्रोजेक्ट स्वयं को alpha और सक्रिय विकास के अधीन बताता है। इसे शुरुआती कमियों वाले एक गंभीर डिज़ाइन के रूप में देखें।

उस architecture का दिलचस्प हिस्सा ही उसका महंगा हिस्सा भी है। हर agent के लिए एक browser वह memory cost है जिसे अधिकांश लोग plan करना भूल जाते हैं, इसलिए यहाँ install करने से पहले sizing करना आवश्यक है।

गेटवे हर क्रिया का निर्णय कैसे लेता है

पोर्ट 3001 पर स्थित API server ही bot के कंप्यूटर तक पहुँचने का एकमात्र रास्ता है। ब्राउज़र की कोई भी क्रिया शुरू होने से पहले, गेटवे पेज स्नैपशॉट से लक्ष्य (target) को निर्धारित करता है, संदर्भ (context) के आधार पर CEL (common expression language) पॉलिसी नियमों का मूल्यांकन करता है, निर्णय को दर्ज करने के लिए एक ऑडिट रो (audit row) लिखता है, और उसके बाद ही कंटेनर को कॉल करता है। यदि इसके बाद निष्पादन (execution) विफल हो जाता है, तो यह दूसरी रो लिखता है। दस्तावेज़ इस सीमा को स्पष्ट रूप से बताते हैं: कंप्यूटर पॉलिसी का निर्णय नहीं लेता है, सर्वर गेटवे ही क्रिया की सीमा है।

पॉलिसी 'deny-by-default' (डिफ़ॉल्ट रूप से अस्वीकार) है, और 'allow' नियमों से पहले 'deny' नियमों का मूल्यांकन किया जाता है। नियम के सिंटैक्स से अधिक विफलता की दिशा मायने रखती है। कोई पॉलिसी न होने पर कुछ भी अनुमति नहीं मिलती है, और एक त्रुटिपूर्ण नियम चाहे वह 'deny' नियम हो या 'allow' नियम, ब्लॉक करने की दिशा में विफल होता है। इसलिए, आपकी पॉलिसी में गलती होने पर bot के आपके खातों पर अनियंत्रित होने के बजाय, bot के अटक जाने की संभावना रहती है।

ऑडिट ट्रेल PostgreSQL में रहता है, इसलिए यह रीस्टार्ट होने के बाद भी सुरक्षित रहता है। कंट्रोल हैंडओवर को computer.help_requested, computer.control_taken और computer.control_released के रूप में रिकॉर्ड किया जाता है। इसी तरह आप देख सकते हैं कि कब एक bot इंसान से मदद मांगता है और कब इंसान वापस कंट्रोल लेता है। सीक्रेट्स को कैरेक्टर काउंट के रूप में रिकॉर्ड किया जाता है, कभी भी वैल्यू के रूप में नहीं। फ़ाइल ऑपरेशंस में पाथ और साइज़ रिकॉर्ड किया जाता है, कभी भी सामग्री (contents) नहीं। यदि आप बिना ब्राउज़र के भी यही कंट्रोल बाउंड्री चाहते हैं, तो gating AI agent actions behind approvals उस सीमित स्थिति को कवर करता है।

एक बॉट के लिए RAM और डिस्क की लागत

यह प्रोजेक्ट arm64 पर एक सिंगल Bot के लिए मापे गए आंकड़े प्रकाशित करता है। OpenBot केवल यही साइजिंग नंबर जारी करता है, और ये एक आर्किटेक्चर पर एक बॉट का विवरण देते हैं, इसलिए इन्हें क्षमता योजना (capacity plan) के बजाय शुरुआती बिंदु के रूप में देखें।

[
  {
    "label": "Measured, one Bot",
    "memory_gb": 0.55,
    "disk_gb": 5.3,
    "vcpu": 0.06
  },
  {
    "label": "Documented minimum",
    "memory_gb": 2,
    "disk_gb": 8,
    "vcpu": 1
  },
  {
    "label": "Documented recommended",
    "memory_gb": 4,
    "disk_gb": 10,
    "vcpu": 2
  }
]

एक Bot के लिए पीक मेमोरी 0.55 GB मापी गई थी, जबकि दस्तावेजीकृत न्यूनतम 2 GB है और अनुशंसित 4 GB है। माप और न्यूनतम के बीच का अंतर Chromium के लिए लोड के तहत बढ़ने की जगह है, क्योंकि ब्राउज़र का मेमोरी उपयोग खुले हुए पेजों पर निर्भर करता है, न कि स्थिर प्रक्रिया पर। Idle CPU लगभग शून्य है, जो मापी गई सीमा के ऊपरी स्तर पर एक कोर का 0.06 है, इसलिए CPU वह संसाधन नहीं है जिसके लिए आप खर्च कर रहे हैं। डिस्क वह संसाधन है। केवल इमेज ही 5.3 GB की है, जबकि अनुशंसित वॉल्यूम 10 GB है, और यह इतनी बड़ी इसलिए है क्योंकि इसमें Chromium के साथ-साथ Playwright के Firefox और WebKit बाइनरी भी शामिल हैं।

इनमें से कोई भी आंकड़ा यह नहीं बताता कि कई बॉट्स की कुल लागत क्या होगी, और प्रोजेक्ट इसके लिए कोई आंकड़ा प्रकाशित नहीं करता है। अपना माप स्वयं लें। एक बॉट शुरू करें, उसे पेज खुले होने के साथ एक वास्तविक कार्य दें, और काम करते समय कंटेनर को मॉनिटर करें।

docker stats --no-stream
free -m

बॉट के कंटेनर के लिए MEM USAGE कॉलम को अपने प्रति-बॉट आंकड़े के रूप में लें, इसमें gateway और PostgreSQL को जोड़ें, फिर प्रति-बॉट आंकड़े को उन बॉट्स की संख्या से गुणा करें जिनके एक ही समय में मौजूद रहने की आप अपेक्षा करते हैं। एक idle बॉट भी ब्राउज़र प्रक्रिया को बनाए रखता है, इसलिए यह मल्टीप्लायर उन बॉट्स पर लागू होता है जो मौजूद हैं, न कि केवल उन पर जो व्यस्त हैं। गणना वही है जो coding agent VPS के लिए RAM और CPU की साइजिंग के लिए उपयोग की जाती है, और इसका ब्राउज़र वाला हिस्सा VPS पर एजेंट्स के लिए headless ब्राउज़र चलाना में कवर किया गया है।

Chromium का एक विवरण छोटे प्लान्स को प्रभावित करता है। OpenBot, Chromium को --disable-dev-shm-usage के साथ लॉन्च करता है, इसलिए ब्राउज़र /dev/shm के बजाय /tmp पर लिखता है। यह उन होस्ट्स पर होने वाले क्रैश से बचाता है जिनमें /dev/shm कम होता है, और यह दबाव को आपके root filesystem पर स्थानांतरित कर देता है, जो एक और कारण है कि अनुशंसित डिस्क इमेज से बड़ी है।

VPS पर OpenBot को self-host कैसे करें?

आपको Docker, Bun 1.3 या उससे नया वर्शन, एक CopilotKit Intelligence प्रोजेक्ट और एक मॉडल API key की आवश्यकता होगी। डेवलपमेंट डॉक्यूमेंटेशन यह भी अपेक्षा करता है कि मशीन पर lsof, python3 और curl मौजूद हों। main के बजाय किसी tagged release को clone करें, क्योंकि अल्फा प्रोजेक्ट पर main बिना किसी चेतावनी के बदल जाते हैं।

git clone --branch v0.0.1 https://github.com/CopilotKit/openbot.git
cd openbot
cp .env.example .env

Intelligence प्रोजेक्ट को provision करें। ये तीन कमांड्स रनटाइम की (runtime key) और लाइसेंस टोकन को आपकी एनवायरनमेंट फाइल में लिख देते हैं।

npx --yes copilotkit@latest login
npx --yes copilotkit@latest project select
npx --yes copilotkit@latest license --write

वह की (key) जनरेट करें जो स्टोर्ड क्रेडेंशियल्स को एन्क्रिप्ट करती है, और आउटपुट को .env में KEY_ENCRYPTION_KEY के रूप में डालें। अपनी OPENAI_API_KEY को उसी फाइल में जोड़ें, या BOT_PROVIDER को संबंधित की के साथ anthropic या google पर सेट करें।

openssl rand -base64 32

इसके बाद इंस्टॉल करें और शुरू करें।

bun install
bash scripts/start.sh

scripts/start.sh Docker सर्विसेज को ऊपर लाता है, डेटाबेस माइग्रेशन चलाता है, सर्वर और ऐप को शुरू करता है, और उनकी हेल्थ चेक करता है। जब यह पूरा हो जाता है, तो ऐप पोर्ट 3010 पर और API पोर्ट 3001 पर जवाब देता है। स्क्रिप्ट पोर्ट कॉन्फ्लिक्ट्स की रिपोर्ट करती है और पहले से चल रही मैचिंग सर्विस को नहीं छेड़ती है, इसलिए इसे दो बार चलाना सुरक्षित है।

कुछ भी expose करने से पहले सर्वर से ही इसकी जाँच करें।

curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3010
ss -ltnp | grep -E ':(3010|3001|4100|4500|5432)'

पहले कमांड से मिलने वाला 200 यह दर्शाता है कि ऐप सर्विस दे रहा है। दूसरा कमांड दिखाता है कि वे पोर्ट्स किन एड्रेस पर बाउंड हैं, और VPS पर यही उत्तर मायने रखता है। 127.0.0.1:3001 वाली लाइन का मतलब है कि यह केवल बॉक्स तक सीमित (private) है। 0.0.0.0:3001 वाली लाइन का मतलब है कि कोई भी व्यक्ति जो सर्वर तक रूट कर सकता है, वह इसे एक्सेस कर सकता है।

एकल कंटेनर इमेज

डिप्लॉयमेंट दस्तावेज़ एक एकल इमेज भी प्रदान करते हैं जिसमें ऐप, API और Chromium शामिल हैं, जो port 3001 पर सर्व की जाती है।

docker build -t openbot .
docker run -p 127.0.0.1:3001:3001 --env-file .env \
  -e EMBEDDED_POSTGRES=on -v openbot-data:/var/lib/postgresql/data openbot

EMBEDDED_POSTGRES=on कंटेनर के भीतर PostgreSQL चलाता है और स्टार्टअप पर माइग्रेशन लागू करता है। named volume रिडिप्लॉयमेंट के दौरान ऑडिट हिस्ट्री को सुरक्षित रखता है, और इसके बिना हर बार रीबिल्ड करने पर वह हिस्ट्री डिलीट हो जाती है। यदि आप DATABASE_URL को किसी मैनेज्ड डेटाबेस की ओर पॉइंट करते हैं, तो उस पर vector एक्सटेंशन सक्षम होना चाहिए। RDS, Cloud SQL और Azure Database जैसी मैनेज्ड सेवाएं इस एक्सटेंशन का समर्थन करती हैं, लेकिन उनमें से कोई भी इसे आपके लिए सक्षम नहीं करती है, इसलिए एक नए मैनेज्ड डेटाबेस पर माइग्रेशन विफल हो जाता है क्योंकि vector कॉलम प्रकार अभी मौजूद नहीं होता है।

जब डेटाबेस बाहरी हो, तो माइग्रेशन को एक रिलीज़ स्टेप के रूप में चलाएं।

docker run --rm --env-file .env openbot \
  sh -c "cd /app/server && bun x drizzle-kit migrate --config=drizzle.config.ts"

वह इमेज जानबूझकर ब्राउज़र पोर्ट को पब्लिश नहीं करती है। यह सुपरवाइज़र को भी छोड़ देती है, क्योंकि सुपरवाइज़र को Docker सॉकेट की आवश्यकता होती है, जो सर्वरलेस प्लेटफॉर्म प्रदान नहीं करते हैं। सुपरवाइज़र के बिना, प्रत्येक बॉट एक ही ब्राउज़र साझा करता है और इसलिए लॉगिन का एक ही सेट उपयोग करता है, जो उस आइसोलेशन को समाप्त कर देता है जिसके कारण प्रति-बॉट कंटेनर चलाना सार्थक था। यदि प्रति-बॉट अलग लॉगिन ही आपका उद्देश्य है, तो COMPUTER_SUPERVISOR_URL और SUPERVISOR_TOKEN सेट करके compose स्टैक चलाएं, ऐसे होस्ट पर जहां आप इसके जोखिम को स्वीकार करते हैं। जो प्रोसेस Docker सॉकेट से बात कर सकती है, वह एक प्रिविलेज्ड कंटेनर शुरू कर सकती है, इसलिए व्यावहारिक रूप से वह होस्ट पर root होती है। यह OpenBot को उसकी अपनी मशीन पर रखने का एक अच्छा कारण है, उसी भावना के साथ जैसे कोडिंग एजेंट्स को एक डिस्पोजेबल VM देना।

OPENBOT_SINGLE_USER एक लैपटॉप सेटिंग क्यों है

.env.example, OPENBOT_SINGLE_USER=true के साथ आता है। यह सेटिंग हर अनुरोध को एक एडमिनिस्ट्रेटर के रूप में स्वीकार करती है और साइन-इन प्रक्रिया को पूरी तरह से छोड़ देती है। लैपटॉप पर यह एक सुविधा है, क्योंकि केवल आप ही उस पोर्ट तक पहुँचने वाले एकमात्र क्लाइंट होते हैं। VPS पर इसका मतलब यह है कि पोर्ट 3010 पर पहुँचने वाला पहला व्यक्ति उस सिस्टम का एडमिनिस्ट्रेटर बन जाता है, जो एन्क्रिप्टेड क्रेडेंशियल्स को स्टोर करता है और ऐसे ब्राउज़र को नियंत्रित करता है जिसमें आप पहले से ही अपने अकाउंट्स में लॉग-इन हैं।

इसे चलाने के दो उचित तरीके हैं। OPENBOT_SINGLE_USER=true को बनाए रखें, हर पोर्ट को 127.0.0.1 पर बाइंड करें, और ऐप तक केवल SSH टनल या प्राइवेट नेटवर्क इंटरफेस के माध्यम से पहुँचें।

ssh -N -L 3010:127.0.0.1:3010 -L 3001:127.0.0.1:3001 you@your-vps

इसके बाद ऐप आपके अपने ब्राउज़र में http://localhost:3010 पर उपलब्ध होता है, जिसे एक सुरक्षित संदर्भ (secure context) माना जाता है। इसलिए साइन-इन कुकीज़ और लाइव स्क्रीन के लिए आवश्यक ब्राउज़र फीचर्स, दोनों काम करते हैं। दूसरा तरीका सिंगल-यूज़र मोड को बंद करना और एक वास्तविक आइडेंटिटी प्रोवाइडर को कॉन्फ़िगर करना है। Google, Microsoft Entra, Okta, SAML और OIDC समर्थित हैं। किसी भी प्रोवाइडर के लिए 32 या उससे अधिक कैरेक्टर वाला BETTER_AUTH_SECRET, OAuth कॉलबैक के लिए पब्लिक API बेस URL पर सेट BETTER_AUTH_URL, INITIAL_ADMIN_EMAILS, और TRUSTED_ORIGINS की आवश्यकता होती है। प्रोवाइडर क्रेडेंशियल्स का पूर्ण होना अनिवार्य है, क्योंकि अधूरा कॉन्फ़िगरेशन ओपन एक्सेस पर वापस जाने के बजाय स्टार्टअप को रोक देता है।

यदि ऐप किसी पब्लिक नाम पर उपलब्ध है, तो इसके सामने TLS (ट्रांसपोर्ट लेयर सिक्योरिटी) लगाएँ। localhost के अलावा किसी भी अन्य स्थान पर सादे http:// के माध्यम से सर्व किया गया पेज एक सुरक्षित संदर्भ नहीं है। इसलिए Secure के रूप में चिह्नित कुकीज़ स्टोर नहीं होती हैं और साइन-इन इस तरह विफल हो जाता है जैसे कि OpenBot में कोई बग हो।

निचले स्तर के ports को firewall से सुरक्षित करें

OpenBot की अपनी सुरक्षा टिप्पणी में कहा गया है कि निचले स्तर के service endpoints tokens द्वारा सुरक्षित हैं, आपको उन्हें निजी रखना चाहिए, और आपको gateway को bypass करने के लिए उनका उपयोग नहीं करना चाहिए। Tokens सुरक्षा की दूसरी परत हैं। पहली परत यह है कि port तक बिल्कुल भी पहुँचा न जा सके।

Agent-computer 4100 पर listen करता है और इसके लिए COMPUTER_TOKEN की आवश्यकता होती है। Bot endpoints 4200 और 4201 पर listen करते हैं। Supervisor host पर 4500 पर और अपने container के अंदर 4300 पर listen करता है। PostgreSQL 5432 पर listen करता है। इनमें से कोई भी public interface पर नहीं होना चाहिए, और single-user deployment में app और API भी public नहीं होने चाहिए।

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

यहाँ एक ऐसी समस्या है जो उन लोगों को प्रभावित करती है जो यह मान लेते हैं कि firewall पर्याप्त है। -p 3001:3001 के साथ container port publish करने पर Docker एक DNAT rule install कर देता है। इससे traffic FORWARD path में handle होता है और कभी भी उस INPUT chain से नहीं गुजरता जिसे ufw की default deny नीति नियंत्रित करती है। Port खुला रहता है जबकि ufw status अभी भी Status: active दिखाता है। Published port को mapping में ही loopback पर bind करें, जैसे -p 127.0.0.1:3001:3001, या अपनी compose file में host address सेट करें। ufw status के बजाय ss -ltnp से पुष्टि करें।

OpenBot एक ऑफलाइन स्टैक नहीं है

डिप्लॉयमेंट की योजना बनाने से पहले इसे समझ लें। OpenBot एक CopilotKit Intelligence प्रोजेक्ट पर निर्भर करता है, जो आपके सर्वर के बाहर स्थायी थ्रेड्स और बातचीत की मेमोरी को सुरक्षित रखता है। सर्वर स्टार्टअप के समय INTELLIGENCE_API_URL, INTELLIGENCE_GATEWAY_WS_URL, INTELLIGENCE_API_KEY और COPILOTKIT_LICENSE_TOKEN को वैलिडेट करता है, और स्टार्टअप सफल होने के लिए इन चारों का एक साथ मौजूद होना अनिवार्य है। अगस्त 2026 तक एक फ्री प्लान उपलब्ध है, और Intelligence को स्वयं भी होस्ट किया जा सकता है, इसलिए क्विकस्टार्ट में बताए गए तरीके से अधिक मेहनत करके पूरी तरह से लोकल डिप्लॉयमेंट संभव है।

मॉडल दूसरी बाहरी निर्भरता है। बॉक्स में कुछ भी पहले से इंस्टॉल होकर नहीं आता है। BOT_PROVIDER, openai, anthropic या google को स्वीकार करता है, और OPENAI_BASE_URL, OpenAI पाथ को किसी भी संगत एंडपॉइंट की ओर निर्देशित करता है। यदि आप चाहते हैं कि टोकन आपके अपने हार्डवेयर पर रहें, तो यहाँ VPS पर Ollama चलाकर LLM को सेल्फ-होस्ट करना उपयोगी है। ब्राउज़र कंट्रोल एक मॉडल से बहुत अधिक अपेक्षाएं रखता है, इसलिए किसी भी मॉडल को फाइनल करने से पहले उसे किसी वास्तविक कार्य पर टेस्ट जरूर करें।

फिलहाल एक replica चलाएं

Gateway सर्वर प्रोसेस मेमोरी में पेज स्नैपशॉट को कैश करता है। दो replicas होने पर, एक प्रोसेस द्वारा लिया गया स्नैपशॉट दूसरे को दिखाई नहीं देता है। इस कारण, element-not-found एरर के साथ क्रियाएं बीच-बीच में विफल हो जाती हैं, जो यादृच्छिक (random) प्रतीत होती हैं। डिप्लॉयमेंट दस्तावेज़ स्पष्ट हैं: केवल एक replica चलाएं और अपने प्लेटफॉर्म की अधिकतम इंस्टेंस संख्या को 1 पर पिन करें। यह सीमा तब समाप्त होगी जब स्नैपशॉट कैशिंग डेटाबेस में स्थानांतरित हो जाएगी। तब तक, आप OpenBot को अधिक बॉक्स जोड़कर नहीं, बल्कि बॉक्स का आकार बढ़ाकर स्केल करें। बॉट्स के बीच अलगाव अभी भी प्रति-बॉट कंटेनर्स से आता है, ठीक उसी तरह जैसे self-hosted agent sandboxes एक एजेंट की गलतियों को दूसरों से दूर रखते हैं।

विफलता के प्रकार और आप क्या देखेंगे

.env भरने के तुरंत बाद स्टार्टअप बंद हो जाता है। सर्वर किसी भी सेवा को शुरू करने से पहले कॉन्फ़िगरेशन को मान्य करता है। एक अधूरा Intelligence ब्लॉक, एक गायब KEY_ENCRYPTION_KEY, या बिना secret के client ID वाला OAuth प्रदाता, चुपचाप खराब होने के बजाय स्टार्टअप को रोक देते हैं। पहली त्रुटि पढ़ें, उस एक फ़ील्ड को ठीक करें, और फिर से शुरू करें।

Managed database पर माइग्रेशन विफल हो जाते हैं। vector एक्सटेंशन डिफ़ॉल्ट रूप से सक्षम नहीं होता है, इसलिए माइग्रेशन एक ऐसे कॉलम प्रकार पर पहुँच जाता है जिसे PostgreSQL नहीं पहचानता है। Superuser के रूप में कनेक्ट करें, CREATE EXTENSION vector; चलाएँ, और फिर माइग्रेशन चरण को पुनः चलाएँ।

ऐप लोड होता है लेकिन साइन-इन कभी भी स्थायी नहीं रहता। आप सार्वजनिक पते पर सादे http:// के माध्यम से सेवा दे रहे हैं, जो एक सुरक्षित संदर्भ नहीं है, इसलिए Secure कुकी को हटा दिया जाता है। सामने TLS लगाएँ, या SSH टनल का उपयोग करें ताकि ब्राउज़र को localhost दिखाई दे।

बॉट्स उन लॉगिन को साझा करते हैं जिनके अलग होने की आपने अपेक्षा की थी। Supervisor नहीं चल रहा है, इसलिए प्रति-बॉट कंप्यूटर नहीं है और प्रत्येक बॉट साझा ब्राउज़र का उपयोग करता है। पुष्टि करें कि COMPUTER_SUPERVISOR_URL सेट है और Supervisor Docker सॉकेट तक पहुँच सकता है।

एक बॉट रुक जाता है और मदद मांगता है। यह डिज़ाइन के अनुसार काम कर रहा है। ऑडिट ट्रेल computer.help_requested को रिकॉर्ड करता है, आप लाइव स्क्रीन पर नियंत्रण लेते हैं, और हैंडओवर दोनों पक्षों पर रिकॉर्ड किया जाता है।

FAQ

क्या VPS deployment के लिए OPENBOT_SINGLE_USER को ऑन रखना सुरक्षित है?

केवल तभी, जब gateway तक इंटरनेट से न पहुँचा जा सके। OPENBOT_SINGLE_USER=true बिना किसी sign-in के हर request को एक administrator के रूप में स्वीकार करता है, इसलिए जो कोई भी port खोल सकता है, वह deployment, उसमें संग्रहीत credentials और sign-in किए गए browser का मालिक बन जाता है। यह तब स्वीकार्य है जब हर port 127.0.0.1 पर bound हो और आप SSH tunnel या private network interface के माध्यम से app तक पहुँचें। Public interface पर, इसे बंद कर दें और Google, Microsoft Entra, Okta या OIDC को BETTER_AUTH_SECRET, BETTER_AUTH_URL, INITIAL_ADMIN_EMAILS और TRUSTED_ORIGINS के साथ configure करें।

एक OpenBot को कितनी RAM की आवश्यकता होती है?

arm64 पर एक single Bot के लिए project के प्रकाशित आंकड़े peak memory को 0.55 GB बताते हैं, जिसमें 2 GB को documented न्यूनतम और 4 GB को अनुशंसित माना गया है। एक साथ कई bots के लिए कोई प्रकाशित आंकड़ा नहीं है, क्योंकि प्रत्येक bot का अपना Chromium होता है। एक वास्तविक task पर एक bot चलाएं, docker stats में उस container की memory पढ़ें, gateway और database को जोड़ें, फिर उन bots की संख्या से गुणा करें जिन्हें आप एक ही समय में चलाने की उम्मीद करते हैं।

क्या OpenBot को self-host करने के लिए मुझे CopilotKit account की आवश्यकता है?

हाँ। OpenBot टिकाऊ threads और memory के लिए CopilotKit Intelligence project पर निर्भर करता है, और server तब तक start होने से मना कर देता है जब तक कि Intelligence API URL, gateway WebSocket URL, API key और license token सेट न हों। अगस्त 2026 तक एक free plan उपलब्ध है, और Intelligence को self-host किया जा सकता है, इसलिए अतिरिक्त काम के साथ hosted dependency को हटाया जा सकता है। आप अपनी स्वयं की model API key भी प्रदान करते हैं, क्योंकि OpenBot के साथ कोई model नहीं आता है।

प्रत्येक bot को अपना browser क्यों मिलता है, बजाय एक साझा करने के?

क्योंकि एक browser profile एक पहचान है। एक साझा browser का मतलब है साझा cookies और साझा sessions, इसलिए एक account में sign-in किया गया एक bot, उस account में sign-in किए गए हर bot के समान है। Per-bot containers प्रत्येक coworker को अपनी profile और अपने logins देते हैं। इसकी कीमत memory है, क्योंकि प्रति bot एक Chromium sizing में सबसे बड़ा एकल घटक है।

firewall पर कौन से OpenBot ports खुले होने चाहिए?

निचले स्तर के ports में से कोई भी नहीं। 4100 पर agent-computer, 4200 और 4201 पर bot endpoints, 4500 पर supervisor और 5432 पर PostgreSQL, ये सभी private रहने चाहिए। project इन्हें tokens के साथ सुरक्षित करता है और आग्रह करता है कि आप इन्हें वैसे भी पहुंच से बाहर रखें। केवल वही publish करें जिसे किसी व्यक्ति को खोलने की आवश्यकता है, और याद रखें कि -p 3001:3001 के साथ publish किया गया container port ufw के default-deny rule के बावजूद पहुंच योग्य होता है, क्योंकि Docker का DNAT rule उस traffic को INPUT के बजाय FORWARD path में डाल देता है।