SSD Nodes Learn Hosting plans →
गाइड Matt Connorलेखक: Matt Connor · अपडेट किया गया: 2026-08-28

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

OpenBot को self-host करने का तरीका जानें जहाँ हर AI coworker का अपना container और browser होता है। जानें कि gateway कैसे क्रियाएं नियंत्रित करता है और प्रति bot कितनी RAM चाहिए।

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

आप अपने नियंत्रण वाले हार्डवेयर पर एक gateway server और प्रति bot एक container चलाकर OpenBot AI coworkers को self-host करते हैं। प्रत्येक bot container में अपना Chromium browser और अपना workspace volume होता है, जिसमें एक browser profile होती है जो sessions के बीच बनी रहती है। एक bot कंप्यूटर, फाइल, MCP (model context protocol) server या UI component पर जो भी क्रिया करता है, वह उस gateway से होकर गुजरती है। gateway क्रिया होने से पहले उसे एक policy के विरुद्ध जाँचता है और होने के बाद उसे record करता है। यदि वह agent loop जिसे gateway wrap करता है, अभी भी आपके लिए नया है, तो learning AI agents from scratch में दिया गया staged path आपको bot को browser और अपने logins देने से पहले खुद एक छोटा loop लिखने का निर्देश देता है।

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

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

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

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

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

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

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

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

ChartOpenBot published resource figures, one Bot on arm64 (August 2026)
The data behind this chart
[
  {
    "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 बाइनरी भी साथ में देती है।

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

docker stats --no-stream
free -m

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

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

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 करें। ये तीन कमांड्स रनटाइम key और लाइसेंस टोकन को आपकी environment file में लिख देते हैं।

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 को संबंधित key के साथ 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 यह दर्शाता है कि ऐप चल रहा है। दूसरा कमांड यह दिखाता है कि वे पोर्ट्स किन एड्रेस पर bound हैं, और 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 की आवश्यकता होती है। प्रोवाइडर क्रेडेंशियल्स पूर्ण होने चाहिए, क्योंकि अधूरा कॉन्फ़िगरेशन ओपन एक्सेस पर वापस जाने के बजाय स्टार्टअप को रोक देता है। यदि आप अकाउंट्स इसलिए जोड़ रहे हैं क्योंकि टीम का हर व्यक्ति अपने ब्राउज़र के बजाय अपना खुद का एजेंट चाहता है, तो OneCLI शुरुआत से ही इसी ढांचे के आधार पर बनाया गया है, जिसमें प्रति व्यक्ति एक सैंडबॉक्स एजेंट होता है और मॉडल कीज़ एक सिंगल गेटवे में सुरक्षित रहती हैं।

यदि ऐप किसी पब्लिक नाम पर एक्सेस किया जा सकता है, तो इसके आगे 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 से कोई विशेष संबंध नहीं है, इसलिए उस box पर publish किए गए अपने हर दूसरे container के लिए भी यही जाँच करें, जिसमें वह भी शामिल है जो 90 के दशक के वीडियो स्टोर के रूप में पुनर्निर्मित Jellyfin library को serve कर रहा है।

OpenBot एक offline stack नहीं है

deployment की योजना बनाने से पहले यह स्पष्ट कर लें। OpenBot एक CopilotKit Intelligence project पर निर्भर करता है, जो आपके सर्वर के बाहर durable threads और conversation memory को सुरक्षित रखता है। सर्वर startup के समय INTELLIGENCE_API_URL, INTELLIGENCE_GATEWAY_WS_URL, INTELLIGENCE_API_KEY और COPILOTKIT_LICENSE_TOKEN को validate करता है, और startup सफल होने के लिए इन चारों का एक साथ मौजूद होना अनिवार्य है। अगस्त 2026 तक एक free plan उपलब्ध है, और Intelligence को स्वयं-होस्ट (self-host) भी किया जा सकता है, इसलिए quickstart में दिखाए गए तरीके से अधिक मेहनत करके पूरी तरह से local deployment संभव है।

model दूसरी बाहरी निर्भरता है। बॉक्स में कुछ भी पहले से शामिल (ship) नहीं होता है। BOT_PROVIDER, openai, anthropic या google को स्वीकार करता है, और OPENAI_BASE_URL, OpenAI path को किसी भी compatible endpoint की ओर निर्देशित करता है। यदि आप चाहते हैं कि tokens आपके अपने hardware पर रहें, तो यहाँ LLM को self-host करने के लिए VPS पर Ollama चलाना का उपयोग किया जा सकता है। Browser control एक model से काफी अधिक अपेक्षाएं रखता है, इसलिए किसी भी निर्णय को अंतिम रूप देने से पहले एक वास्तविक कार्य पर local model का परीक्षण अवश्य करें।

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

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

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

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

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

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

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

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

FAQ

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

केवल तभी जब gateway तक इंटरनेट से न पहुँचा जा सके। OPENBOT_SINGLE_USER=true बिना साइन-इन के हर अनुरोध को एक एडमिनिस्ट्रेटर के रूप में स्वीकार करता है, इसलिए जो कोई भी पोर्ट खोल सकता है, वह deployment, उसमें संग्रहीत क्रेडेंशियल्स और साइन-इन किए गए ब्राउज़र का मालिक बन जाता है। यह तब स्वीकार्य है जब हर पोर्ट 127.0.0.1 पर बाइंड हो और आप SSH टनल या प्राइवेट नेटवर्क इंटरफेस के माध्यम से ऐप तक पहुँचें। पब्लिक इंटरफेस पर, इसे बंद कर दें और BETTER_AUTH_SECRET, BETTER_AUTH_URL, INITIAL_ADMIN_EMAILS तथा TRUSTED_ORIGINS के साथ Google, Microsoft Entra, Okta या OIDC को कॉन्फ़िगर करें।

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

arm64 पर एक सिंगल बॉट के लिए प्रोजेक्ट के प्रकाशित आंकड़े पीक मेमोरी को 0.55 GB बताते हैं, जिसमें 2 GB न्यूनतम और 4 GB अनुशंसित है। एक साथ कई बॉट्स के लिए कोई प्रकाशित आंकड़ा नहीं है, क्योंकि प्रत्येक बॉट का अपना Chromium होता है। एक वास्तविक कार्य पर एक बॉट चलाएं, docker stats में उस कंटेनर की मेमोरी पढ़ें, gateway और डेटाबेस को जोड़ें, फिर उन बॉट्स की संख्या से गुणा करें जिन्हें आप एक ही समय में चलाना चाहते हैं।

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

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

प्रत्येक बॉट को अपना ब्राउज़र क्यों मिलता है, साझा क्यों नहीं?

क्योंकि ब्राउज़र प्रोफाइल एक पहचान है। एक साझा ब्राउज़र का मतलब है साझा कुकीज़ और साझा सत्र, इसलिए एक अकाउंट में साइन-इन किया गया एक बॉट उस अकाउंट में साइन-इन किए गए सभी बॉट्स के बराबर होता है। प्रति-बॉट कंटेनर प्रत्येक वर्कर को अपनी प्रोफाइल और अपने लॉगिन देते हैं। इसकी कीमत मेमोरी है, क्योंकि प्रति बॉट एक Chromium साइजिंग में सबसे बड़ा एकल आइटम है।

फायरवॉल पर कौन से OpenBot पोर्ट खुले होने चाहिए?

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