استضافة زملاء OpenBot للذكاء الاصطناعي على VPS

ما تحصل عليه عند استضافة زملاء OpenBot للذكاء الاصطناعي ذاتياً

تستضيف زملاء OpenBot للذكاء الاصطناعي ذاتياً عبر تشغيل خادم بوابة واحد وحاوية واحدة لكل روبوت على أجهزة تتحكم فيها. تحتوي كل حاوية روبوت على متصفح Chromium ومساحة عمل volume خاصة بها، مع ملف تعريف متصفح يستمر بين الجلسات. تمر كل عملية ينفذها الروبوت على جهاز كمبيوتر أو ملف أو خادم MCP (بروتوكول سياق النموذج) أو مكوّن واجهة مستخدم عبر تلك البوابة. تتحقق البوابة من العملية مقابل سياسة قبل تنفيذها، وتسجلها بعد ذلك. إذا كانت حلقة الوكيل التي تغلفها البوابة غير مألوفة لك، فإن المسار التدريجي في تعلّم وكلاء الذكاء الاصطناعي من الصفر يجعلك تكتب حلقة صغيرة بنفسك قبل أن تمنح الروبوت متصفحاً وبيانات تسجيل الدخول الخاصة بك.

تنشر CopilotKit برنامج OpenBot بموجب ترخيص MIT على github.com/CopilotKit/openbot. نُشر الإصدار الموسوم الأول، v0.0.1، في 17 August 2026، ويصف المشروع نفسه بأنه إصدار alpha وتطويره نشط. تعامل معه على أنه تصميم جاد، مع وجود جوانب مبكرة تحتاج إلى تحسين.

الجزء المثير للاهتمام في هذه البنية هو أيضاً الجزء الأعلى تكلفة. يستهلك توفير متصفح لكل وكيل معظم الذاكرة التي ينسى كثيرون التخطيط لها، لذلك نحدد الحجم قبل التثبيت هنا.

كيف تحدد البوابة كل إجراء

خادم API على المنفذ 3001 هو المسار الوحيد إلى حاسوب bot. قبل تنفيذ أي إجراء في المتصفح، تحدد البوابة الهدف من لقطة الصفحة، وتقيّم قواعد سياسة CEL (لغة التعبيرات الشائعة) مقابل السياق، وتكتب صفاً في سجل التدقيق يتضمن القرار، ثم تستدعي الحاوية فقط بعد ذلك. إذا فشل التنفيذ بعد ذلك، تكتب صفاً ثانياً. توضّح الوثائق الحد الفاصل بوضوح: الحاسوب لا يحدد السياسة، بل إن بوابة الخادم هي حد تنفيذ الإجراءات. لهذا الفصل اسم خارج OpenBot، لأن الحلقة وتعريفات الأدوات وفحوصات الأذونات وحالة الجلسة تشكّل معاً الغلاف المحيط بالنموذج، وهذه البوابة هي جانب الأذونات منه.

تعمل السياسة وفق مبدأ الرفض الافتراضي، وتُقيَّم قواعد الرفض قبل قواعد السماح. اتجاه الفشل أهم من صياغة القاعدة. السياسة المفقودة لا تسمح بأي شيء، والقاعدة المعطلة تفشل باتجاه الحظر، سواء كانت قاعدة رفض أو قاعدة سماح. لذلك يؤدي الخطأ في سياستك إلى توقف bot، لا إلى تحركه بحرية داخل حساباتك. تتحكم هذه الطبقة في ما يفعله bot، لا في ما يقرأه. لذلك تبقى الصفحة التي تتضمن تعليمات موجهة إلى agent مشكلة منفصلة، وهي سطح prompt injection نفسه الذي تواجهه عندما تسلّم agent نتائج من مثيل SearXNG الخاص بك.

يُحفظ سجل التدقيق في PostgreSQL، لذلك يبقى بعد إعادة التشغيل. تُسجَّل عمليات تسليم التحكم بصفتها computer.help_requested وcomputer.control_taken وcomputer.control_released. هكذا ترى bot يطلب تدخّل إنسان، وترى الإنسان يعيد التحكم. تُسجَّل الأسرار على شكل عدد الأحرف، ولا تُسجَّل قيمها مطلقاً. تسجّل عمليات الملفات المسار والحجم، ولا تسجّل المحتوى مطلقاً. إذا أردت حد التحكم نفسه من دون متصفح خلفه، فتتناول وضع إجراءات AI agent خلف الموافقات هذه الحالة الأضيق.

ما مقدار RAM ومساحة القرص التي يستهلكها Bot واحد

ينشر المشروع أرقاماً مقاسة لـBot واحد على arm64. هذه هي أرقام تحديد الحجم الوحيدة التي تنشرها OpenBot، وهي تصف Bot واحداً على بنية واحدة. لذلك استخدمها كنقطة بداية، لا كخطة سعة.

[
  {
    "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
  }
]

بلغت الذاكرة القصوى المقاسة 0.55 GB لـBot واحد، بينما الحد الأدنى الموثق هو 2 GB، والتوصية هي 4 GB. الفرق بين القياس والحد الأدنى يوفّر مساحة لنمو Chromium تحت الحمل، لأن استهلاك المتصفح للذاكرة يرتبط بالصفحات المفتوحة فيه، وليس بحالته عندما يكون خاملاً. يقترب استهلاك CPU في وضع الخمول من الصفر، إذ يبلغ 0.06 من نواة واحدة عند الحد الأعلى للنطاق المقاس. لذلك لا يذهب معظم ما تشتريه إلى CPU. بل إلى القرص. تبلغ مساحة الصورة وحدها 5.3 GB، مقابل volume موصى به بسعة 10 GB. ويرجع ذلك إلى أن الصورة تتضمن ملفات Playwright الثنائية الخاصة بـFirefox وWebKit إلى جانب Chromium.

لا يوضح أي من ذلك تكلفة تشغيل عدة Bots معاً، ولا ينشر المشروع رقماً لهذه الحالة. الحد الأدنى الموثق هو الرقم الذي يفضّل المشروع نشره، وليس رقماً قاسه أحد أثناء الحمل. ولهذا أيضاً يعتمد الاختيار بين PhotoPrism وImmich على حدود RAM الدنيا المقاسة لديهما، لا على الأرقام المنشورة. قِس استهلاكك بنفسك. شغّل Bot واحداً، وأسند إليه مهمة فعلية مع إبقاء صفحة مفتوحة، وراقب الحاوية أثناء عملها.

docker stats --no-stream
free -m

استخدم قيمة العمود MEM USAGE الخاصة بحاوية Bot بوصفها قيمة Bot الواحد، ثم أضف gateway وPostgreSQL، وبعد ذلك اضرب قيمة Bot الواحد في عدد Bots التي تتوقع وجودها في الوقت نفسه. يحتفظ Bot الخامل بعملية متصفح، لذلك ينطبق معامل الضرب على Bots الموجودة، لا على Bots المشغولة فقط. الحساب هو نفسه المستخدم في تحديد RAM وCPU لـVPS يشغّل coding agent، ويغطي تشغيل متصفح headless للوكلاء على VPS جانب المتصفح من هذا الحساب.

تؤثر إحدى تفاصيل Chromium في الخطط الصغيرة. يشغّل OpenBot Chromium باستخدام --disable-dev-shm-usage، لذلك يكتب المتصفح إلى /tmp بدلاً من /dev/shm. يمنع ذلك التعطل الذي يحدث على المضيفين ذوي /dev/shm الصغير، لكنه ينقل الضغط إلى نظام الملفات الجذر، وهذا سبب إضافي يجعل مساحة القرص الموصى بها أكبر من مساحة الصورة.

كيف تستضيف OpenBot ذاتياً على VPS؟

تحتاج إلى Docker وBun بإصدار 1.3 أو أحدث، ومشروع CopilotKit Intelligence، ومفتاح API للنموذج. تتوقع وثائق التطوير أيضاً وجود lsof وpython3 وcurl على الخادم. استنسخ إصداراً موسوماً بدلاً من main، لأن main في مشروع alpha يتغير دون تحذير.

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

جهّز مشروع Intelligence. تكتب هذه الأوامر الثلاثة مفتاح وقت التشغيل ورمز الترخيص في ملف البيئة لديك.

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

أنشئ المفتاح الذي يشفّر بيانات الاعتماد المخزنة، وضع الناتج في .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. يبلّغ البرنامج النصي عن تعارضات المنافذ، ويترك الخدمة المطابقة التي تعمل مسبقاً دون تغيير، لذلك من الآمن تشغيله مرتين.

اختبره من الخادم نفسه قبل إتاحة أي شيء للعامة.

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 خاصاً بالخادم. أما السطر الذي يقرأ 0.0.0.0:3001 فيعني أن أي جهة يمكنها توجيه حركة الشبكة إلى الخادم تستطيع الوصول إليه.

الصورة الوحّدة للحاوية

تتضمن وثائق النشر أيضاً صورة واحدة تحتوي على التطبيق وواجهة API وChromium، وتخدم على المنفذ 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 داخل الحاوية وتطبّق عمليات الترحيل عند بدء التشغيل. ويحافظ الحجم المُسمّى على سجل التدقيق عند إعادة النشر، ومن دونه تتخلّص كل عملية إعادة بناء من هذا السجل. إذا وجّهت 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"

تترك هذه الصورة منفذ المتصفح غير منشور عمداً. كما تستبعد supervisor، لأن supervisor يحتاج إلى Docker socket، وهو غير متاح في المنصات عديمة الخوادم. ومن دون supervisor، تشترك كل bot في متصفح واحد، وبالتالي في مجموعة واحدة من بيانات تسجيل الدخول، ما يلغي العزل الذي جعل تشغيل حاويات منفصلة لكل bot مفيداً. إذا كان سبب وجودك هنا هو استخدام بيانات تسجيل دخول منفصلة لكل bot، فشغّل مكدس compose مع ضبط COMPUTER_SUPERVISOR_URL وSUPERVISOR_TOKEN، على مضيف تقبل فيه هذه المقايضة. يمكن لعملية تتصل بـDocker socket بدء حاوية ذات امتيازات، ولذلك تكون عملياً root على المضيف. وهذا سبب وجيه لإبقاء OpenBot على جهاز مستقل، بالنهج نفسه المتّبع في منح وكلاء البرمجة جهازاً افتراضياً مؤقتاً.

سبب كون 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 في متصفحك، ويُعد ذلك سياقاً آمناً. لذلك تعمل ملفات تعريف ارتباط تسجيل الدخول وميزات المتصفح التي تحتاج إليها الشاشة المباشرة. والطريقة الأخرى هي إيقاف وضع المستخدم الواحد وإعداد موفّر هوية فعلي. تتوفر Google وMicrosoft Entra وOkta وSAML وOIDC. يحتاج أي موفّر أيضاً إلى BETTER_AUTH_SECRET بطول 32 حرفاً أو أكثر، وإلى ضبط BETTER_AUTH_URL على عنوان URL الأساسي العام لواجهة API من أجل عمليات رد OAuth، وإلى INITIAL_ADMIN_EMAILS وTRUSTED_ORIGINS. يجب أن تكون بيانات اعتماد الموفّر مكتملة، لأن إعداد الموفّر جزئياً يمنع بدء التشغيل بدلاً من الرجوع إلى الوصول المفتوح. إذا كان سبب إضافة الحسابات هو رغبة كل فرد في الفريق في امتلاك وكيل خاص به بدلاً من متصفح خاص به، فإن OneCLI مصمم لهذا النموذج منذ البداية، مع وكيل معزول في sandbox لكل شخص، والاحتفاظ بمفاتيح النماذج في بوابة واحدة.

إذا كان التطبيق متاحاً عبر اسم عام، فضع TLS (أمان طبقة النقل) أمامه. لا تُعد الصفحة المقدّمة عبر http:// في أي مكان غير localhost سياقاً آمناً، ولذلك لا تُخزَّن ملفات تعريف الارتباط المعلّمة بـSecure، ويفشل تسجيل الدخول بطريقة تبدو كأنها خلل في OpenBot.

حصِّن المنافذ ذات المستوى الأدنى

تذكر الملاحظة الأمنية الخاصة بـOpenBot أن نقاط نهاية الخدمات ذات المستوى الأدنى محمية بواسطة رموز، وأنه يجب إبقاؤها خاصة، وألّا تُستخدم لتجاوز البوابة. الرموز هي طبقة الحماية الثانية. أما الطبقة الأولى فهي ألّا يكون الوصول إلى المنفذ ممكناً إطلاقاً.

يستمع agent-computer على المنفذ 4100 ويتطلب COMPUTER_TOKEN. وتستمع نقاط نهاية bot على المنفذين 4200 و4201. ويستمع supervisor على المنفذ 4500 في المضيف، وعلى المنفذ 4300 داخل حاويته. ويستمع PostgreSQL على المنفذ 5432. لا ينبغي لأي من هذه المنافذ أن يكون على واجهة عامة. وفي عملية نشر لمستخدم واحد، ينطبق ذلك أيضاً على التطبيق وواجهة API.

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

هناك فخ يقع فيه من يفترض أن الجدار الناري كافٍ. يؤدي نشر منفذ حاوية باستخدام -p 3001:3001 إلى جعل Docker يثبّت قاعدة DNAT، ولذلك تُعالَج حركة الشبكة في مسار FORWARD ولا تمر مطلقاً عبر السلسلة INPUT التي يفرض عليها الرفض الافتراضي في ufw حظره. يظل المنفذ مفتوحاً رغم أن ufw status ما زال يعرض Status: active. اربط المنفذ المنشور بواجهة loopback ضمن عملية الربط نفسها، مثل -p 127.0.0.1:3001:3001، أو حدّد عنوان المضيف في ملف compose. تحقّق باستخدام ss -ltnp، وليس باستخدام ufw status. لا يقتصر هذا الفخ على OpenBot، لذا نفّذ الفحص نفسه على كل حاوية أخرى نشرتَ منافذها على الخادم، بما في ذلك أي خدمة توفّر مكتبة Jellyfin أُعيد بناؤها لتصبح متجر فيديوهات من حقبة التسعينيات.

OpenBot ليس حزمة تعمل دون اتصال

اذكر ذلك قبل التخطيط للنشر. يعتمد OpenBot على مشروع CopilotKit Intelligence، الذي يحتفظ بسلاسل المحادثات الدائمة وذاكرة المحادثات خارج خادمك. يتحقق الخادم عند بدء التشغيل من INTELLIGENCE_API_URL وINTELLIGENCE_GATEWAY_WS_URL وINTELLIGENCE_API_KEY وCOPILOTKIT_LICENSE_TOKEN، ويجب أن تكون القيم الأربع موجودة معاً، وإلا يفشل بدء التشغيل. تتوفر خطة مجانية اعتباراً من August 2026، كما أن Intelligence قابل للاستضافة الذاتية، لذلك يمكن تنفيذ نشر محلي بالكامل، لكن ذلك يتطلب عملاً أكثر مما يوضحه دليل البدء السريع.

النموذج هو التبعية الخارجية الثانية. لا يتضمن الصندوق أي نموذج. يقبل BOT_PROVIDER القيمة openai أو anthropic أو google، بينما يوجّه OPENAI_BASE_URL مسار OpenAI إلى أي endpoint متوافق. وهنا يأتي تشغيل Ollama على VPS لاستضافة LLM ذاتياً إذا أردت إبقاء الرموز المميزة على أجهزتك. يتطلب التحكم في المتصفح الكثير من النموذج، لذلك اختبر نموذجاً محلياً في مهمة فعلية قبل اعتماده.

شغِّل نسخة متماثلة واحدة مؤقتاً

يخزّن الـgateway لقطات الصفحات في ذاكرة عملية الخادم. عند تشغيل نسختين متماثلتين، لا تكون اللقطة التي تلتقطها إحدى العمليتين مرئية للعملية الأخرى. لذلك تفشل الإجراءات بشكل متقطع مع أخطاء تفيد بعدم العثور على العنصر، وتبدو هذه الأخطاء عشوائية. توضح وثائق النشر ذلك صراحة: شغِّل نسخة متماثلة واحدة، واضبط الحد الأقصى لعدد المثيلات في منصتك على 1. ينتهي هذا القيد عندما ينتقل تخزين اللقطات مؤقتاً إلى قاعدة البيانات. حتى ذلك الحين، وسِّع OpenBot بزيادة موارد الخادم، لا بإضافة خوادم. وتظل العزلة بين الروبوتات ناتجة عن الحاويات المخصصة لكل روبوت، بالطريقة نفسها التي تحافظ بها بيئات عزل الوكلاء المستضافة ذاتياً على أخطاء وكيل واحد بعيداً عن الوكلاء الآخرين.

أوضاع الفشل وما ستراه

يتوقف التشغيل فوراً بعد إكمال .env. يتحقق الخادم من الإعدادات قبل أن يقدّم أي خدمة. تؤدي كتلة Intelligence غير المكتملة، أو غياب KEY_ENCRYPTION_KEY، أو استخدام موفّر OAuth مع معرّف عميل دون سر، إلى إيقاف التشغيل بدلاً من الاستمرار مع تدهور صامت. اقرأ الخطأ الأول، وأصلح ذلك الحقل، ثم شغّل الخادم مجدداً.

تفشل عمليات الترحيل على قاعدة بيانات مُدارة. لا يكون الامتداد vector مفعّلاً افتراضياً، لذلك تصل عملية الترحيل إلى نوع عمود لا يعرفه PostgreSQL. اتصل باستخدام حساب superuser، ونفّذ CREATE EXTENSION vector;، ثم أعد تشغيل خطوة الترحيل.

يُحمّل التطبيق، لكن تسجيل الدخول لا يستمر. أنت تقدّم الخدمة عبر http:// عادي على عنوان عام، وهذا ليس سياقاً آمناً، لذلك تُهمَل ملف تعريف الارتباط Secure. ضع TLS أمام التطبيق، أو استخدم نفق SSH حتى يرى المتصفح localhost.

تستخدم الروبوتات بيانات تسجيل دخول مشتركة رغم أنك توقعت فصلها. لا يعمل المشرف، لذلك لا يوجد جهاز مستقل لكل روبوت، وتستخدم جميع الروبوتات المتصفح المشترك. تأكد من ضبط COMPUTER_SUPERVISOR_URL ومن قدرة المشرف على الوصول إلى مقبس Docker.

يتوقف أحد الروبوتات ويطلب المساعدة. هذا يعني أن التصميم يعمل كما هو مقصود. يسجل مسار التدقيق computer.help_requested، وتتولى التحكم في الشاشة المباشرة، وتُسجَّل عملية التسليم على الجانبين.

FAQ

هل من الآمن ترك OPENBOT_SINGLE_USER مفعّلاً عند نشره على VPS؟

فقط عندما يتعذر الوصول إلى البوابة من الإنترنت. يقبل OPENBOT_SINGLE_USER=true كل طلب باعتباره صادراً عن مسؤول واحد من دون تسجيل دخول، لذلك فإن أي شخص يستطيع فتح المنفذ يملك عملية النشر وبيانات الاعتماد المخزّنة والمتصفح الذي سجّل الدخول. يكون ذلك مقبولاً عندما تكون كل المنافذ مرتبطة بـ127.0.0.1، وتصل إلى التطبيق عبر نفق SSH أو واجهة شبكة خاصة. على واجهة عامة، عطّله واضبط Google أو Microsoft Entra أو Okta أو OIDC مع BETTER_AUTH_SECRET وBETTER_AUTH_URL وINITIAL_ADMIN_EMAILS وTRUSTED_ORIGINS.

ما مقدار RAM الذي يحتاج إليه روبوت OpenBot واحد؟

تضع الأرقام المنشورة للمشروع، بالنسبة إلى Bot واحد على arm64، ذروة الذاكرة عند 0.55 GB، مع 2 GB كحد أدنى موثّق و4 GB كقيمة موصى بها. لا يوجد رقم منشور لعدة روبوتات تعمل في الوقت نفسه، لأن كل روبوت يحتفظ بعملية Chromium مستقلة. شغّل روبوتاً واحداً على مهمة فعلية، واقرأ ذاكرة حاويته في docker stats، ثم أضف ذاكرة البوابة وقاعدة البيانات، واضرب الناتج في عدد الروبوتات التي تتوقع تشغيلها في الوقت نفسه.

هل أحتاج إلى حساب CopilotKit لاستضافة OpenBot ذاتياً؟

نعم. يعتمد OpenBot على مشروع CopilotKit Intelligence للاحتفاظ الدائم بالمحادثات والذاكرة، ويرفض الخادم البدء ما لم يتم ضبط عنوان Intelligence API URL وعنوان WebSocket للبوابة ومفتاح API ورمز الترخيص. تتوفر خطة مجانية اعتباراً من August 2026، ويمكن استضافة Intelligence ذاتياً، لذا يمكن إزالة الاعتماد على الخدمة المستضافة مع بذل جهد إضافي. كما يجب أن توفّر مفتاح API الخاص بك للنموذج، لأن OpenBot لا يتضمن أي نموذج.

لماذا يحصل كل روبوت على متصفحه الخاص بدلاً من مشاركة متصفح واحد؟

لأن ملف تعريف المتصفح يمثل هوية. يعني المتصفح المشترك ملفات تعريف ارتباط وجلسات مشتركة، لذلك فإن تسجيل روبوت واحد الدخول إلى حساب ما يعني تسجيل كل الروبوتات الدخول إلى ذلك الحساب. تمنح الحاويات المنفصلة لكل روبوت ملف تعريف خاصاً وتسجيلات دخول خاصة به. وتتمثل الكلفة في الذاكرة، لأن عملية Chromium لكل روبوت هي أكبر عنصر منفرد في تقدير الموارد.

ما منافذ OpenBot التي ينبغي فتحها في جدار الحماية؟

لا تفتح أياً من المنافذ ذات المستوى الأدنى. يبقى agent-computer على 4100، ونقطتا نهاية الروبوت على 4200 و4201، وsupervisor على 4500، وPostgreSQL على 5432 خاصة. يحميها المشروع بالرموز، ويطلب منك إبقاءها غير قابلة للوصول على أي حال. انشر فقط ما يحتاج الشخص إلى فتحه، وتذكّر أن منفذ الحاوية المنشور باستخدام -p 3001:3001 يمكن الوصول إليه بغض النظر عن قاعدة ufw الافتراضية التي ترفض الاتصالات، لأن قاعدة DNAT في Docker تضع تلك الحركة في مسار FORWARD بدلاً من INPUT.