آموزش میزبانی شخصی OpenBot AI روی VPS

آنچه با میزبانی شخصی همکاران OpenBot AI به دست می‌آورید

شما همکاران OpenBot AI را با اجرای یک سرور gateway به همراه یک container برای هر ربات روی سخت‌افزاری که کنترل آن را در دست دارید، به صورت self-host میزبانی می‌کنید. هر container ربات، مرورگر Chromium اختصاصی و volume فضای کاری (workspace) خود را به همراه دارد و از یک پروفایل مرورگر استفاده می‌کند که بین نشست‌ها باقی می‌ماند. هر عملی که ربات روی یک کامپیوتر، فایل، سرور MCP (پروتکل زمینه مدل) یا یک مؤلفه رابط کاربری انجام می‌دهد، از طریق آن gateway عبور می‌کند؛ gateway پیش از انجام عملیات آن را با سیاست‌های امنیتی تطبیق داده و پس از انجام، ثبت (log) می‌کند.

OpenBot توسط CopilotKit تحت مجوز MIT در github.com/CopilotKit/openbot منتشر شده است. اولین نسخه برچسب‌گذاری‌شده، v0.0.1، در تاریخ 17 اوت 2026 منتشر شد و این پروژه خود را در مرحله آلفا و در حال توسعه فعال معرفی می‌کند. با آن به عنوان یک طراحی جدی با لبه‌های ناهموار اولیه برخورد کنید.

بخش جالب این معماری، همان بخش پرهزینه آن است. مرورگر برای هر عامل، هزینه حافظه‌ای است که اکثر افراد فراموش می‌کنند برای آن برنامه‌ریزی کنند؛ بنابراین در اینجا، تعیین اندازه (sizing) پیش از نصب انجام می‌شود.

نحوه تصمیم‌گیری گیت‌وی برای هر عملیات

سرور API روی پورت 3001 تنها مسیر دسترسی به کامپیوتر یک بات است. پیش از اجرای هر عملیات در مرورگر، گیت‌وی هدف را از روی snapshot صفحه تشخیص می‌دهد، قوانین خط‌مشی CEL (Common Expression Language) را بر اساس context ارزیابی می‌کند، یک ردیف audit حاوی تصمیم می‌نویسد و تنها پس از آن container را فراخوانی می‌کند. اگر پس از این مرحله اجرا با شکست مواجه شود، یک ردیف دوم ثبت می‌شود. مستندات مرز را به‌وضوح بیان می‌کنند: کامپیوتر تصمیم‌گیرنده خط‌مشی نیست، بلکه سرور گیت‌وی مرز عملیاتی است.

خط‌مشی به‌صورت پیش‌فرض deny-by-default است و قوانین deny پیش از قوانین allow ارزیابی می‌شوند. جهت شکست (failure) اهمیت بیشتری نسبت به نحو (syntax) قوانین دارد. نبود خط‌مشی به معنای عدم اجازه برای هر عملیاتی است و یک قانون معیوب، چه deny باشد و چه allow، منجر به مسدودسازی می‌شود؛ بنابراین اشتباه در خط‌مشی شما باعث گیر کردن بات می‌شود، نه آزاد شدن آن در حساب‌های کاربری‌تان.

ردپای audit در PostgreSQL ذخیره می‌شود، بنابراین پس از restart باقی می‌ماند. انتقال کنترل با computer.help_requested، computer.control_taken و computer.control_released ثبت می‌شود؛ این همان روشی است که از طریق آن می‌بینید یک بات درخواست کمک از انسان دارد و چگونه انسان کنترل را پس می‌گیرد. Secretها به‌صورت تعداد کاراکتر ثبت می‌شوند و هرگز مقدار آن‌ها ذخیره نمی‌شود. عملیات فایل، مسیر و اندازه را ثبت می‌کنند و هرگز محتوای فایل را ذخیره نمی‌کنند. اگر به همان مرز کنترلی بدون وجود مرورگر در پس‌زمینه نیاز دارید، محدود کردن عملیات ایجنت‌های هوش مصنوعی با تاییدیه این مورد خاص‌تر را پوشش می‌دهد.

هزینه رم و دیسک برای یک بات

این پروژه ارقام اندازه‌گیری‌شده برای یک بات واحد روی arm64 را منتشر می‌کند. این‌ها تنها اعداد مربوط به تعیین ظرفیت هستند که OpenBot ارائه می‌دهد و چون فقط یک بات را روی یک معماری توصیف می‌کنند، آن‌ها را به‌عنوان نقطه شروع در نظر بگیرید، نه یک طرح ظرفیت‌سنجی کامل.

[
  {
    "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 گیگابایت اندازه‌گیری شده است، در حالی که حداقلِ مستندشده 2 گیگابایت و مقدار توصیه‌شده 4 گیگابایت است. فاصله بین مقدار اندازه‌گیری‌شده و حداقل، فضایی برای رشد Chromium تحت بار است، زیرا مصرف حافظه مرورگر با تعداد صفحات باز تغییر می‌کند و نه با پردازشی که در حالت استراحت است. مصرف CPU در حالت بیکار نزدیک به صفر است و در بالاترین حدِ بازه اندازه‌گیری‌شده، 0.06 از یک هسته است؛ بنابراین CPU چیزی نیست که بابت آن هزینه می‌کنید، بلکه دیسک است. حجم ایمیج به‌تنهایی 5.3 گیگابایت است، در حالی که حجم توصیه‌شده برای دیسک 10 گیگابایت می‌باشد. دلیل این حجم زیاد، وجود باینری‌های Firefox و WebKit مربوط به Playwright در کنار Chromium است.

هیچ‌کدام از این‌ها هزینه چندین بات در کنار هم را به شما نمی‌گوید و پروژه هیچ رقمی برای آن منتشر نکرده است. خودتان اندازه‌گیری کنید. یک بات را اجرا کنید، یک وظیفه واقعی با یک صفحه باز به آن بدهید و در حین کار، container را مانیتور کنید.

docker stats --no-stream
free -m

ستون MEM USAGE برای container بات را به‌عنوان رقمِ هر بات در نظر بگیرید، gateway و PostgreSQL را به آن اضافه کنید و سپس رقمِ هر بات را در تعداد بات‌هایی که انتظار دارید هم‌زمان وجود داشته باشند، ضرب کنید. یک باتِ بیکار همچنان یک پردازش مرورگر را نگه می‌دارد، بنابراین این ضریب برای تمام بات‌های موجود اعمال می‌شود، نه فقط بات‌هایی که مشغول کار هستند. محاسبات همان روشی است که برای تعیین اندازه رم و CPU برای یک VPS عامل کدنویسی استفاده می‌شود و بخش مرورگر آن در اجرای مرورگر headless برای عامل‌ها روی یک VPS پوشش داده شده است.

یک جزئیات مربوط به Chromium بر پلن‌های کوچک تأثیر می‌گذارد. OpenBot برنامه Chromium را با پرچم --disable-dev-shm-usage اجرا می‌کند، بنابراین مرورگر به‌جای /dev/shm در مسیر /tmp می‌نویسد. این کار از کرش کردن در میزبان‌هایی که /dev/shm کوچکی دارند جلوگیری می‌کند و فشار را به فایل‌سیستم ریشه شما منتقل می‌کند؛ این یکی دیگر از دلایلی است که دیسک توصیه‌شده بزرگ‌تر از حجم ایمیج است.

چگونه OpenBot را روی یک VPS میزبانی کنیم؟

شما به Docker، نسخه 1.3 یا جدیدتر Bun، یک پروژه CopilotKit Intelligence و یک API key برای مدل نیاز دارید. مستندات توسعه همچنین انتظار دارند که lsof، python3 و curl روی سیستم نصب باشند. به جای main، یک نسخه tagged را clone کنید، زیرا main در یک پروژه آلفا بدون هشدار تغییر می‌کند.

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

پروژه Intelligence را آماده‌سازی کنید. این سه دستور، کلید runtime و توکن لایسنس را در فایل environment شما می‌نویسند.

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 را بالا می‌آورد، migrationهای دیتابیس را اجرا می‌کند، سرور و برنامه را استارت می‌زند و سلامت آن‌ها را بررسی می‌کند. پس از پایان، برنامه روی پورت 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 از دستور اول به این معنی است که برنامه در حال سرویس‌دهی است. دستور دوم نشان می‌دهد که آن پورت‌ها به چه آدرس‌هایی bind شده‌اند، و این همان پاسخی است که در یک VPS اهمیت دارد. خطی که 127.0.0.1:3001 را نشان می‌دهد، خصوصی و محدود به همان سرور است. خطی که 0.0.0.0:3001 را نشان می‌دهد به این معنی است که هر کسی که بتواند به سرور route داشته باشد، می‌تواند به آن دسترسی پیدا کند.

تصویر کانتینر واحد

مستندات استقرار، یک تصویر واحد را نیز ارائه می‌دهند که شامل برنامه، 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 را درون کانتینر اجرا کرده و مهاجرت‌ها (migrations) را در زمان شروع به کار اعمال می‌کند. یک volume نام‌گذاری‌شده، تاریخچه حسابرسی (audit history) را در طول redeploy حفظ می‌کند؛ بدون آن، هر بار بازسازی (rebuild)، آن تاریخچه را از بین می‌برد. اگر DATABASE_URL را به یک دیتابیس مدیریت‌شده متصل کنید، باید افزونه vector روی آن فعال باشد. سرویس‌های مدیریت‌شده مانند RDS، Cloud SQL و Azure Database از این افزونه پشتیبانی می‌کنند، اما هیچ‌کدام آن را به‌صورت پیش‌فرض برای شما فعال نمی‌کنند؛ بنابراین مهاجرت روی یک دیتابیس مدیریت‌شدهٔ تازه، به دلیل عدم وجود نوع ستون vector با شکست مواجه می‌شود.

هنگامی که دیتابیس خارجی است، مهاجرت‌ها را به‌عنوان یک مرحله از release اجرا کنید.

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

آن تصویر به‌طور عمدی پورت مرورگر را منتشر (publish) نمی‌کند. همچنین شامل supervisor نیست، زیرا supervisor به Docker socket نیاز دارد که پلتفرم‌های serverless آن را ارائه نمی‌دهند. بدون supervisor، هر ربات از یک مرورگر و در نتیجه یک مجموعه لاگین مشترک استفاده می‌کند؛ این امر باعث از بین رفتن ایزولاسیونی می‌شود که اجرای کانتینرهای مجزا برای هر ربات را ارزشمند می‌کرد. اگر دلیل حضور شما در اینجا، داشتن لاگین‌های مجزا برای هر ربات است، stack مربوط به compose را با تنظیم COMPUTER_SUPERVISOR_URL و SUPERVISOR_TOKEN روی میزبانی اجرا کنید که این معامله (trade-off) را می‌پذیرید. فرآیندی که می‌تواند با Docker socket ارتباط برقرار کند، قادر است یک کانتینر با دسترسی ممتاز (privileged) ایجاد کند، بنابراین در عمل، دسترسی root روی میزبان دارد. این دلیل خوبی است که OpenBot را روی ماشین اختصاصی خودش نگه دارید، با همان رویکردی که در اختصاص یک VM یک‌بارمصرف به عوامل برنامه‌نویس مطرح شد.

چرا OPENBOT_SINGLE_USER یک تنظیم مخصوص لپ‌تاپ است

.env.example با OPENBOT_SINGLE_USER=true عرضه می‌شود. این تنظیم، تمام درخواست‌ها را به عنوان یک مدیر سیستم می‌پذیرد و مرحله ورود به سیستم را به‌طور کامل نادیده می‌گیرد. روی یک لپ‌تاپ، این موضوع یک مزیت است، زیرا تنها کلاینتی که به این پورت دسترسی دارد، خود شما هستید. اما روی یک VPS، این یعنی اولین کسی که به پورت 3010 برسد، به مدیر سیستمی تبدیل می‌شود که اعتبارنامه‌های رمزنگاری‌شده را ذخیره می‌کند و مرورگری را کنترل می‌کند که از قبل در حساب‌های شما وارد شده است.

دو روش اصولی برای اجرای آن وجود دارد. OPENBOT_SINGLE_USER=true را حفظ کنید، تمام پورت‌ها را روی 127.0.0.1 bind کنید و فقط از طریق یک تونل SSH یا یک رابط شبکه خصوصی به برنامه دسترسی پیدا کنید.

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

در این حالت، برنامه در مرورگر شخصی شما در http://localhost:3010 در دسترس خواهد بود که یک بستر امن محسوب می‌شود؛ بنابراین کوکی‌های ورود و قابلیت‌های مرورگر که برای صفحه زنده (live screen) نیاز است، هر دو کار می‌کنند. روش دیگر، غیرفعال کردن حالت تک‌کاربره و پیکربندی یک ارائه‌دهنده هویت (Identity Provider) واقعی است. Google، Microsoft Entra، Okta، SAML و OIDC پشتیبانی می‌شوند. هر ارائه‌دهنده‌ای همچنین به BETTER_AUTH_SECRET با طول 32 کاراکتر یا بیشتر، BETTER_AUTH_URL تنظیم‌شده روی آدرس پایه API عمومی برای callbackهای OAuth، INITIAL_ADMIN_EMAILS و TRUSTED_ORIGINS نیاز دارد. اعتبارنامه‌های ارائه‌دهنده باید کامل باشند، زیرا یک ارائه‌دهنده ناقص پیکربندی‌شده، به‌جای بازگشت به حالت دسترسی آزاد، از راه‌اندازی برنامه جلوگیری می‌کند.

اگر برنامه از طریق یک نام دامنه عمومی قابل دسترسی است، حتماً از TLS (امنیت لایه انتقال) در مقابل آن استفاده کنید. صفحه‌ای که از طریق http:// ساده و روی هر چیزی غیر از localhost ارائه شود، یک بستر امن نیست؛ بنابراین کوکی‌های علامت‌گذاری‌شده با Secure ذخیره نمی‌شوند و ورود به سیستم با خطایی مواجه می‌شود که شبیه به یک باگ در OpenBot به نظر می‌رسد.

محدودسازی پورت‌های سطح پایین با فایروال

یادداشت امنیتی خود OpenBot بیان می‌کند که نقاط پایانی (endpoints) سرویس‌های سطح پایین توسط توکن‌ها محافظت می‌شوند، باید خصوصی نگه داشته شوند و نباید برای دور زدن gateway از آن‌ها استفاده کرد. توکن‌ها لایه دوم محافظت هستند. لایه اول این است که پورت اصلاً در دسترس نباشد.

کامپیوتر عامل (agent-computer) روی پورت 4100 گوش می‌دهد و به COMPUTER_TOKEN نیاز دارد. نقاط پایانی ربات روی پورت‌های 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 که سیاست پیش‌فرض deny در ufw بر آن حاکم است، عبور نکند. پورت باز می‌ماند در حالی که ufw status همچنان Status: active را نمایش می‌دهد. پورت منتشر شده را در خودِ نگاشت (mapping) به loopback متصل کنید، مانند -p 127.0.0.1:3001:3001، یا آدرس میزبان را در فایل compose خود تنظیم کنید. این موضوع را با ss -ltnp تأیید کنید، نه با ufw status.

نرم‌افزار OpenBot یک پشته آفلاین نیست

این موضوع را پیش از برنامه‌ریزی برای استقرار در نظر بگیرید. OpenBot به یک پروژه CopilotKit Intelligence وابسته است که رشته‌های گفتگو و حافظه مکالمات را خارج از سرور شما نگهداری می‌کند. سرور در هنگام راه‌اندازی، مقادیر INTELLIGENCE_API_URL، INTELLIGENCE_GATEWAY_WS_URL، INTELLIGENCE_API_KEY و COPILOTKIT_LICENSE_TOKEN را اعتبارسنجی می‌کند و هر چهار مورد باید همزمان موجود باشند، در غیر این صورت راه‌اندازی با شکست مواجه می‌شود. از اوت 2026 یک طرح رایگان در دسترس است و Intelligence خود قابلیت self-host شدن را دارد، بنابراین با صرف زمان بیشتر نسبت به آنچه در quickstart آمده، استقرار کاملاً محلی نیز امکان‌پذیر است.

مدل، دومین وابستگی خارجی است. هیچ‌چیز به صورت پیش‌فرض همراه نرم‌افزار ارائه نمی‌شود. BOT_PROVIDER مقادیر openai، anthropic یا google را می‌پذیرد و OPENAI_BASE_URL مسیر OpenAI را به هر endpoint سازگاری هدایت می‌کند؛ این همان جایی است که اجرای Ollama روی یک VPS برای میزبانی محلی LLM کاربرد پیدا می‌کند، اگر می‌خواهید توکن‌ها روی سخت‌افزار خودتان باقی بمانند. کنترل مرورگر نیازمند توان پردازشی بالایی از مدل است، بنابراین پیش از نهایی کردن تصمیم، یک مدل محلی را روی یک وظیفه واقعی تست کنید.

اجرای یک نسخه (replica) در حال حاضر

درگاه (gateway)، اسنپ‌شات‌های صفحات را در حافظهٔ پردازش سرور کش می‌کند. با وجود دو نسخه، اسنپ‌شاتی که توسط یک پردازش گرفته می‌شود برای دیگری قابل مشاهده نیست؛ در نتیجه عملیات به‌طور متناوب با خطاهای element-not-found که تصادفی به نظر می‌رسند، شکست می‌خورند. مستندات استقرار صریحاً بیان می‌کنند: فقط یک نسخه اجرا کنید و حداکثر تعداد instance پلتفرم خود را روی 1 قفل کنید. این محدودیت زمانی پایان می‌یابد که کش کردن اسنپ‌شات‌ها به دیتابیس منتقل شود. تا آن زمان، مقیاس‌پذیری OpenBot را با ارتقای سخت‌افزار سرور (بزرگ‌تر کردن باکس) انجام دهید، نه با افزودن باکس‌های بیشتر. ایزولاسیون بین بات‌ها همچنان از طریق کانتینرهای مخصوص هر بات تأمین می‌شود، دقیقاً همان‌طور که سندباکس‌های agent خودمیزبان از تأثیر خطاهای یک agent بر سایرین جلوگیری می‌کنند.

حالت‌های شکست و آنچه مشاهده خواهید کرد

خروج از برنامه بلافاصله پس از تکمیل .env. سرور پیش از ارائه هرگونه سرویس، پیکربندی را اعتبارسنجی می‌کند. یک بلوک Intelligence ناقص، یک KEY_ENCRYPTION_KEY گمشده، یا یک ارائه‌دهنده OAuth که دارای Client ID است اما Secret ندارد، همگی باعث توقف راه‌اندازی می‌شوند و برنامه به جای کارکرد ناقص، متوقف می‌شود. اولین خطا را بخوانید، آن فیلد خاص را اصلاح کنید و دوباره شروع کنید.

شکست در Migration روی دیتابیس مدیریت‌شده. افزونه vector به‌صورت پیش‌فرض فعال نیست، بنابراین Migration با نوع ستونی مواجه می‌شود که PostgreSQL آن را نمی‌شناسد. با دسترسی Superuser متصل شوید، دستور CREATE EXTENSION vector; را اجرا کنید و سپس مرحله Migration را دوباره انجام دهید.

برنامه بارگذاری می‌شود اما ورود به سیستم پایدار نمی‌ماند. شما در حال سرویس‌دهی از طریق http:// ساده روی یک آدرس عمومی هستید که یک بستر امن محسوب نمی‌شود، بنابراین کوکی Secure نادیده گرفته می‌شود. از TLS در لایه جلویی استفاده کنید یا از SSH tunnel بهره ببرید تا مرورگر localhost را مشاهده کند.

بات‌ها از لاگین‌های مشترکی استفاده می‌کنند که انتظار داشتید جدا باشند. سرویس Supervisor در حال اجرا نیست، بنابراین هیچ محیط مجزایی برای هر بات وجود ندارد و همه بات‌ها از مرورگر مشترک استفاده می‌کنند. اطمینان حاصل کنید که COMPUTER_SUPERVISOR_URL تنظیم شده است و Supervisor می‌تواند به Docker socket دسترسی داشته باشد.

یک بات متوقف می‌شود و درخواست کمک می‌کند. این دقیقاً نحوه عملکرد طراحی سیستم است. مسیر حسابرسی (Audit trail) مقدار computer.help_requested را ثبت می‌کند، شما کنترل را در صفحه زنده به دست می‌گیرید و این انتقال در هر دو سمت ثبت می‌شود.

FAQ

آیا فعال گذاشتن OPENBOT_SINGLE_USER برای استقرار روی VPS امن است؟

فقط زمانی که gateway از طریق اینترنت قابل دسترسی نباشد. 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 پیکربندی کنید.

هر بات OpenBot به چه مقدار RAM نیاز دارد؟

ارقام منتشرشده توسط پروژه برای یک بات واحد روی arm64، اوج مصرف حافظه را 0.55 گیگابایت اعلام کرده است؛ با 2 گیگابایت به‌عنوان حداقلِ مستند و 4 گیگابایت به‌عنوان مقدار توصیه‌شده. هیچ رقم رسمی برای چندین بات به‌صورت هم‌زمان وجود ندارد، زیرا هر بات یک نمونه Chromium اختصاصی خود را اجرا می‌کند. یک بات را روی یک وظیفه واقعی اجرا کنید، میزان حافظه آن container را در docker stats بخوانید، مقدار مصرف gateway و دیتابیس را به آن اضافه کنید و سپس در تعداد بات‌هایی که انتظار دارید هم‌زمان فعال باشند، ضرب کنید.

آیا برای self-host کردن OpenBot به حساب CopilotKit نیاز دارم؟

بله. OpenBot برای رشته‌های گفتگو (threads) و حافظه پایدار به یک پروژه CopilotKit Intelligence وابسته است و سرور تا زمانی که URL مربوط به Intelligence API، URL مربوط به WebSocket در gateway، کلید API و توکن لایسنس تنظیم نشوند، اجرا نمی‌شود. از اوت 2026 یک طرح رایگان در دسترس است و Intelligence نیز قابلیت self-host شدن دارد، بنابراین با صرف تلاش بیشتر می‌توان وابستگی به سرویس میزبانی‌شده را حذف کرد. شما همچنین باید کلید API مدل خود را ارائه دهید، زیرا هیچ مدلی به‌صورت پیش‌فرض همراه با OpenBot عرضه نمی‌شود.

چرا هر بات به‌جای اشتراک‌گذاری، مرورگر اختصاصی خود را دارد؟

زیرا پروفایل مرورگر به معنای هویت است. مرورگر مشترک به معنای کوکی‌ها و نشست‌های (sessions) مشترک است؛ بنابراین اگر یک بات به حسابی وارد شود، تمام بات‌ها به آن حساب وارد می‌شوند. کانتینرهای مجزا برای هر بات باعث می‌شود هر همکار، پروفایل و ورودهای (logins) مخصوص به خود را داشته باشد. هزینه این کار مصرف حافظه است، چرا که Chromium برای هر بات، بزرگ‌ترین بخش در محاسبات ابعادی (sizing) محسوب می‌شود.

کدام پورت‌های OpenBot باید روی فایروال باز باشند؟

هیچ‌کدام از پورت‌های سطح پایین. agent-computer روی 4100، نقاط پایانی بات روی 4200 و 4201، ناظر (supervisor) روی 4500 و PostgreSQL روی 5432 همگی باید خصوصی باقی بمانند. این پروژه آن‌ها را با توکن‌ها محافظت می‌کند و توصیه می‌کند که به‌هرحال آن‌ها را غیرقابل‌دسترس نگه دارید. فقط مواردی را منتشر کنید که یک کاربر برای باز کردن نیاز دارد و به یاد داشته باشید که پورت کانتینری که با -p 3001:3001 منتشر شده است، صرف‌نظر از قانون default-deny در ufw، قابل‌دسترسی است؛ زیرا قانون DNAT در Docker، آن ترافیک را به‌جای INPUT در مسیر FORWARD قرار می‌دهد.