راهنمای میزبانی شخصی OpenBot AI روی سرور مجازی VPS

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

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

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

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

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

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

سیاست پیش‌فرض بر پایه deny است و قوانین deny پیش از قوانین allow ارزیابی می‌شوند. جهت شکست بیش از نحو قوانین اهمیت دارد. نبود سیاست به معنای اجازه به هیچ‌چیز است و یک قانون خراب، چه deny باشد چه allow، منجر به مسدودسازی می‌شود؛ بنابراین اشتباه در سیاست‌گذاری شما باعث متوقف شدن بات می‌شود، نه رها شدن بات در حساب‌های کاربری‌تان. این لایه بر آنچه بات انجام می‌دهد نظارت دارد، نه آنچه می‌خواند؛ بنابراین صفحه‌ای که حاوی دستورالعمل‌هایی برای عامل (agent) است، همچنان یک مشکل جداگانه باقی می‌ماند که همان سطح حمله prompt injection است که هنگام ارائه نتایج از نمونه SearXNG خود به یک عامل با آن مواجه می‌شوید.

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

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

این پروژه ارقام اندازه‌گیری‌شده برای یک بات واحد روی معماری 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 گیگابایت می‌باشد. این حجم زیاد به این دلیل است که در کنار Chromium، باینری‌های Playwright برای Firefox و WebKit نیز همراه آن عرضه می‌شوند.

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

docker stats --no-stream
free -m

ستون MEM USAGE برای کانتینر بات را به‌عنوان رقمِ هر بات در نظر بگیرید، سپس مصرف 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 مدل نیاز دارید. مستندات توسعه همچنین انتظار دارند که 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 را آماده‌سازی کنید. این سه دستور، کلید زمان اجرا (runtime key) و توکن لایسنس را در فایل محیطی (environment file) شما می‌نویسند.

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

هنگامی که دیتابیس خارجی است، migrationها را به‌عنوان یک مرحله از 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، تمام ربات‌ها از یک مرورگر و در نتیجه از یک مجموعه لاگین مشترک استفاده می‌کنند؛ این موضوع باعث از بین رفتن ایزولاسیونی می‌شود که استفاده از کانتینرهای مجزا برای هر ربات را توجیه‌پذیر می‌کرد. اگر دلیل استفادهٔ شما از این ابزار، داشتن لاگین‌های مجزا برای هر ربات است، compose stack را با تنظیم COMPUTER_SUPERVISOR_URL و SUPERVISOR_TOKEN روی میزبانی اجرا کنید که این معامله (trade-off) را می‌پذیرید. فرآیندی که بتواند با Docker socket ارتباط برقرار کند، می‌تواند یک کانتینر با دسترسی ویژه (privileged) ایجاد کند؛ بنابراین در عمل، این فرآیند دسترسی root روی میزبان دارد. این دلیل خوبی است که OpenBot را روی ماشین اختصاصی خودش اجرا کنید، مشابه رویکرد اختصاص یک VM یک‌بارمصرف به عامل‌های برنامه‌نویسی.

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

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

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

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

در این حالت، برنامه در مرورگر شخصی شما در آدرس http://localhost:3010 در دسترس خواهد بود که یک بستر امن (secure context) محسوب می‌شود؛ بنابراین کوکی‌های ورود و قابلیت‌های مرورگر که برای صفحه زنده (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 نیاز دارد. اعتبارنامه‌های ارائه‌دهنده باید کامل باشند، زیرا یک ارائه‌دهنده نیمه‌پیکربندی‌شده به‌جای بازگشت به دسترسی آزاد، از راه‌اندازی برنامه جلوگیری می‌کند. اگر دلیل شما برای افزودن حساب‌ها این است که هر فرد در تیم به‌جای داشتن مرورگر اختصاصی خود، می‌خواهد یک عامل (agent) مستقل داشته باشد، OneCLI از ابتدا بر اساس همین ساختار طراحی شده است؛ به‌طوری که برای هر نفر یک عامل در محیط ایزوله (sandboxed) وجود دارد و کلیدهای مدل در یک gateway واحد نگهداری می‌شوند.

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

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

یادداشت امنیتی خودِ OpenBot بیان می‌کند که نقاط پایانی سرویس‌های سطح پایین توسط توکن‌ها محافظت می‌شوند، باید آن‌ها را خصوصی نگه دارید و نباید از آن‌ها برای دور زدن 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 نیست، بنابراین همین بررسی را برای هر کانتینر دیگری که روی سیستم منتشر کرده‌اید انجام دهید، از جمله هر چیزی که یک کتابخانه Jellyfin که به شکل یک ویدیو کلوپ دهه 90 بازسازی شده را ارائه می‌دهد.

نرم‌افزار 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 را با بزرگ‌تر کردن سرور (Scale up) انجام دهید، نه با افزودن سرورهای بیشتر (Scale out). جداسازی بین بات‌ها همچنان از طریق کانتینرهای اختصاصی هر بات تأمین می‌شود، همان‌طور که سندباکس‌های عامل‌های خودمیزبان از تأثیر خطاهای یک عامل بر سایرین جلوگیری می‌کنند.

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

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

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

برنامه بارگذاری می‌شود اما ورود به سیستم (Sign-in) پایدار نمی‌ماند. شما در حال ارائه سرویس از طریق 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، آدرس WebSocket مربوط به gateway، کلید API و توکن لایسنس تنظیم نشوند، اجرا نمی‌شود. از اوت 2026 یک طرح رایگان در دسترس است و Intelligence نیز قابلیت self-host شدن دارد، بنابراین با صرف تلاش بیشتر می‌توان وابستگی به سرویس میزبانی‌شده را حذف کرد. همچنین باید کلید API مدل خود را ارائه دهید، زیرا هیچ مدلی به‌صورت پیش‌فرض همراه با OpenBot عرضه نمی‌شود.

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

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

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

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