SSD Nodes Learn Hosting plans →
নির্দেশিকা Matt Connorদ্বারা Matt Connor · আপডেট করা হয়েছে 2026-08-28

VPS-এ OpenBot AI coworker self-host করার পদ্ধতি

VPS-এ OpenBot চালিয়ে প্রতিটি AI coworker-এর জন্য আলাদা container, Chromium এবং workspace volume দিন। gateway কীভাবে action পরীক্ষা ও record করে, আর RAM কত লাগে জানুন।

Self-host করলে OpenBot AI coworker থেকে যা পাবেন

আপনার নিয়ন্ত্রণে থাকা hardware-এ একটি gateway server এবং প্রতিটি bot-এর জন্য একটি করে container চালিয়ে OpenBot AI coworker self-host করবেন। প্রতিটি bot container-এ নিজস্ব Chromium browser এবং নিজস্ব workspace volume থাকে। এতে এমন একটি browser profile থাকে, যা session-এর মধ্যে সংরক্ষিত থাকে। কোনো computer, file, MCP (model context protocol) server বা UI component-এ bot যে কোনো action নিলে তা gateway-এর মধ্য দিয়ে যায়। Gateway action কার্যকর হওয়ার আগে policy অনুযায়ী তা পরীক্ষা করে এবং পরে তা record করে। Gateway যে agent loop-কে wrap করে, সেটি যদি এখনও আপনার কাছে অপরিচিত হয়, তাহলে শুরু থেকে AI agent শেখার পথ অনুসরণ করে আগে নিজে একটি ছোট agent loop লিখতে পারেন। এরপর bot-কে browser এবং আপনার login ব্যবহার করতে দিতে পারেন।

OpenBot, CopilotKit-এর প্রকাশিত একটি project। এটি MIT license-এর অধীনে github.com/CopilotKit/openbot-এ পাওয়া যায়। প্রথম tagged release, v0.0.1, 17 August 2026-এ প্রকাশিত হয়। Project-টি নিজেকে alpha এবং active development-এর অধীনে বলে বর্ণনা করে। তাই এটিকে পরিণত product হিসেবে নয়, বরং প্রাথমিক সীমাবদ্ধতাসহ একটি গুরুত্বপূর্ণ design হিসেবে বিবেচনা করুন।

এই architecture-এর আকর্ষণীয় দিকটিই আবার সবচেয়ে বেশি resource ব্যয় করে। প্রতিটি agent-এর জন্য একটি browser চালাতে হয়। অধিকাংশ ব্যবহারকারী planning-এর সময় এই memory cost বিবেচনা করেন না। তাই এখানে install করার আগে hardware sizing করতে হবে।

গেটওয়ে কীভাবে প্রতিটি কাজের সিদ্ধান্ত নেয়

port 3001-এ চলা API server-ই bot-এর কম্পিউটারে যাওয়ার একমাত্র পথ। কোনো browser action চলার আগে gateway page snapshot থেকে target নির্ধারণ করে, context-এর বিপরীতে CEL (common expression language) policy rule মূল্যায়ন করে, সিদ্ধান্তটি ধারণকারী একটি audit row লেখে, এবং তারপরই container-এ call করে। এরপর execution ব্যর্থ হলে এটি দ্বিতীয় একটি row লেখে। নথিতে boundary-টি স্পষ্টভাবে বলা হয়েছে: policy নির্ধারণ করে না কম্পিউটার; server gateway-ই action boundary। OpenBot-এর বাইরে এই বিভাজনের একটি নাম আছে, কারণ loop, tool definition, permission check এবং session state একসঙ্গে একটি model-কে ঘিরে থাকা harness, আর এই gateway তার permission অংশ।

Policy-তে deny-by-default ব্যবহৃত হয়, এবং allow rule-এর আগে deny rule মূল্যায়ন করা হয়। Rule syntax-এর চেয়ে ব্যর্থতার দিক বেশি গুরুত্বপূর্ণ। Policy অনুপস্থিত থাকলে কোনো কিছু অনুমোদিত হয় না, এবং কোনো rule-এ ত্রুটি থাকলে সেটি deny rule হোক বা allow rule—দুই ক্ষেত্রেই ফল blocking হয়। তাই policy-তে ভুল হলে bot আটকে যাবে; bot আপনার account-গুলোতে অবাধে কাজ করবে না। এই layer bot কী করে তা নিয়ন্ত্রণ করে, bot কী পড়ে তা নয়। তাই agent-কে লক্ষ্য করে নির্দেশনা বহনকারী page একটি আলাদা সমস্যা। এটি সেই একই prompt injection surface, যার মুখোমুখি আপনি হন যখন নিজের SearXNG instance থেকে পাওয়া ফলাফল agent-কে দেন।

Audit trail PostgreSQL-এ থাকে, তাই restart-এর পরও এটি সংরক্ষিত থাকে। Control handover computer.help_requested, computer.control_taken এবং computer.control_released হিসেবে রেকর্ড হয়। এর মাধ্যমে বোঝা যায় bot কখন মানুষের কাছে অনুরোধ করেছে এবং মানুষ কখন আবার control ফিরিয়ে দিয়েছে। Secrets-এর ক্ষেত্রে মান নয়, শুধু character count রেকর্ড করা হয়। File operation-এর ক্ষেত্রে path এবং size রেকর্ড করা হয়, contents নয়। Browser ছাড়াই একই control boundary চাইলে approval-এর মাধ্যমে AI agent action নিয়ন্ত্রণ করা এই সীমিত ক্ষেত্রটি ব্যাখ্যা করে।

একটি bot-এর RAM ও disk খরচ

প্রকল্পটি arm64-এ একটি Bot-এর জন্য পরিমাপ করা তথ্য প্রকাশ করে। OpenBot যে sizing সংখ্যা প্রকাশ করে, সেগুলোই একমাত্র উপলভ্য সংখ্যা। এগুলো একটি architecture-এ একটি bot-এর বর্ণনা দেয়। তাই এগুলোকে 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-এর জন্য peak memory 0.55 GB মাপা হয়েছে। নথিভুক্ত minimum হলো 2 GB এবং recommendation হলো 4 GB। Measurement এবং minimum-এর পার্থক্যটি load-এর সময় Chromium-এর memory বৃদ্ধির জন্য রাখা অতিরিক্ত সুযোগ। কারণ browser-এর memory ব্যবহার idle অবস্থায় process-এর ব্যবহারের ওপর নয়, খোলা page-এর ওপর নির্ভর করে। Idle CPU প্রায় শূন্যের কাছাকাছি। পরিমাপ করা সর্বোচ্চ range-এ এটি core-এর 0.06 অংশ ব্যবহার করেছে। তাই আপনি মূলত CPU কিনছেন না। Disk-এর প্রয়োজন বেশি। শুধু image-এর আকার 5.3 GB। Recommended volume হলো 10 GB। Image এত বড় কারণ Chromium-এর পাশাপাশি এতে Playwright-এর Firefox এবং WebKit binary-ও থাকে।

একসঙ্গে কয়েকটি bot চালালে মোট খরচ কত হবে, এই তথ্য থেকে তা জানা যায় না। প্রকল্পটিও এর কোনো সংখ্যা প্রকাশ করে না। Documented minimum হলো এমন একটি সংখ্যা, যা প্রকল্পটি প্রকাশ করার মতো উপযোগী মনে করে। এটি load-এর সময় কেউ পর্যবেক্ষণ করেছে এমন বাস্তব সংখ্যা নয়। এই কারণেই PhotoPrism এবং Immich-এর মধ্যে নির্বাচন তাদের published সংখ্যার বদলে measured RAM floor-এর ওপর নির্ভর করে। নিজের পরিবেশে পরিমাপ করুন। একটি bot চালু করুন, খোলা page-সহ একটি বাস্তব কাজ দিন, এবং কাজ চলার সময় container monitor করুন।

docker stats --no-stream
free -m

Bot-এর container-এর জন্য MEM USAGE column-এর মানকে per-bot figure হিসেবে নিন। এর সঙ্গে gateway এবং PostgreSQL-এর খরচ যোগ করুন। তারপর একই সময়ে চলবে বলে ধরে নেওয়া bot-এর সংখ্যা দিয়ে per-bot figure গুণ করুন। একটি idle bot-এর ক্ষেত্রেও browser process চালু থাকে। তাই multiplier সেই bot-গুলোর ক্ষেত্রে প্রযোজ্য, যেগুলো চালু আছে; শুধু busy bot-এর ক্ষেত্রে নয়। একই arithmetic coding agent-এর জন্য VPS-এ RAM ও CPU sizing-এ ব্যবহার করা হয়েছে। এর browser অংশ VPS-এ agent-এর জন্য headless browser চালানো-তে ব্যাখ্যা করা হয়েছে।

ছোট plan-এর ক্ষেত্রে Chromium-এর একটি বিষয় গুরুত্বপূর্ণ। OpenBot Chromium চালু করে --disable-dev-shm-usage দিয়ে। তাই browser /dev/shm-এর বদলে /tmp-এ লেখে। ছোট /dev/shm-সহ host-এ যে crash হয়, এটি তা এড়ায়। তবে এতে চাপ root filesystem-এর ওপর পড়ে। Recommended disk image-এর চেয়ে বড় হওয়ার এটি আরও একটি কারণ।

VPS-এ OpenBot কীভাবে নিজে হোস্ট করবেন?

আপনার Docker, Bun 1.3 বা নতুন সংস্করণ, একটি CopilotKit Intelligence project এবং একটি model API key প্রয়োজন। Development docs-এ সিস্টেমে lsof, python3 এবং curl থাকাও প্রত্যাশিত। main-এর পরিবর্তে একটি tagged release clone করুন, কারণ alpha project-এ main কোনো সতর্কতা ছাড়াই পরিবর্তিত হতে পারে।

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

Intelligence project provision করুন। এই তিনটি command আপনার environment file-এ runtime key এবং license token লিখবে।

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

সংরক্ষিত credential encrypt করার জন্য key তৈরি করুন এবং output-টি .env-এ KEY_ENCRYPTION_KEY হিসেবে রাখুন। একই file-এ আপনার OPENAI_API_KEY যোগ করুন, অথবা matching key-সহ BOT_PROVIDER-কে anthropic বা google হিসেবে সেট করুন।

openssl rand -base64 32

এরপর install এবং start করুন।

bun install
bash scripts/start.sh

scripts/start.sh Docker service চালু করে, database migration চালায়, server ও app start করে এবং এগুলোর health পরীক্ষা করে। কাজ শেষ হলে app port 3010-এ এবং API port 3001-এ সাড়া দেবে। Script port conflict জানায় এবং একই ধরনের আগে থেকে চলমান service বন্ধ করে না, তাই এটি দুবার চালানো নিরাপদ।

কোনো কিছু বাইরে থেকে accessible করার আগে server থেকেই পরীক্ষা করুন।

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

প্রথম command-এর 200 মানে app request গ্রহণ করছে। দ্বিতীয় command-টি দেখায় ওই port-গুলো কোন address-এ bind করা আছে; VPS-এ এটিই গুরুত্বপূর্ণ ফলাফল। 127.0.0.1:3001 লেখা একটি line শুধু server-এর অভ্যন্তরীণ ব্যবহারের জন্য। 0.0.0.0:3001 লেখা একটি line-এর অর্থ হলো server-এ network route থাকা যে কেউ সেখানে পৌঁছাতে পারবে।

একটি একক container image

Deployment documentation-এ app, API এবং Chromium-সহ একটি একক image-ও দেওয়া হয়, যা port 3001-এ service দেয়।

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 container-এর ভেতরে PostgreSQL চালায় এবং startup-এর সময় migration প্রয়োগ করে। Named volume redeploy-এর পরেও audit history সংরক্ষণ করে। এটি না থাকলে প্রতিটি rebuild সেই history মুছে ফেলে। আপনি যদি DATABASE_URL-কে একটি managed database-এর দিকে নির্দেশ করেন, তাহলে সেখানে vector extension enable করতে হবে। RDS, Cloud SQL এবং Azure Database-এর মতো managed service-গুলো extension সমর্থন করে, কিন্তু কোনোটি নিজে থেকে এটি enable করে না। তাই নতুন managed database-এর বিরুদ্ধে migration ব্যর্থ হয়, কারণ vector column type তখনও তৈরি থাকে না।

Database external হলে release step হিসেবে migration চালান।

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

এই image ইচ্ছাকৃতভাবে browser port publish করে না। এতে supervisor-ও নেই, কারণ supervisor-এর Docker socket প্রয়োজন, যা serverless platform-গুলো দেয় না। Supervisor না থাকলে প্রতিটি bot একই browser এবং একই login set ব্যবহার করে। ফলে সেই isolation থাকে না, যার জন্য প্রতিটি bot-এর আলাদা container চালানো যুক্তিযুক্ত ছিল। প্রতি bot-এর জন্য আলাদা login দরকার হলে COMPUTER_SUPERVISOR_URL এবং SUPERVISOR_TOKEN set করে compose stack চালান, এমন একটি host-এ যেখানে এই trade-off গ্রহণযোগ্য। Docker socket-এর সঙ্গে যোগাযোগ করতে পারে এমন process একটি privileged container চালু করতে পারে। তাই বাস্তবে সেটি host-এর root। এই কারণে OpenBot-কে আলাদা একটি machine-এ রাখা উচিত, যেমন coding agent-দের জন্য disposable VM ব্যবহার করা।

ল্যাপটপের জন্য OPENBOT_SINGLE_USER সেটিং

.env.example-এর সঙ্গে OPENBOT_SINGLE_USER=true থাকে। এই সেটিং প্রতিটি অনুরোধকে একজন administrator হিসেবে গ্রহণ করে এবং sign-in সম্পূর্ণভাবে এড়িয়ে যায়। ল্যাপটপে এটি সুবিধাজনক, কারণ port-এ পৌঁছাতে পারে এমন একমাত্র client আপনি। VPS-এ এর অর্থ হলো, port 3010-এ প্রথম যে ব্যক্তি পৌঁছাবে, সে এমন একটি system-এর administrator হয়ে যাবে যেখানে encrypted credentials সংরক্ষিত থাকে এবং আপনার account-গুলোতে আগে থেকেই sign in করা browser নিয়ন্ত্রিত হয়।

এটি চালানোর দুটি নিরাপদ পদ্ধতি আছে। OPENBOT_SINGLE_USER=true চালু রাখুন, প্রতিটি port 127.0.0.1-এ bind করুন, এবং শুধু SSH tunnel বা private network interface-এর মাধ্যমে app-এ পৌঁছান।

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

আপনার নিজের browser-এ app-টি তখন http://localhost:3010-এ থাকবে। এটি secure context হিসেবে গণ্য হয়। তাই sign-in cookie এবং live screen-এর প্রয়োজনীয় browser feature—দুটিই কাজ করবে। অন্য পদ্ধতি হলো single-user mode বন্ধ করে একটি প্রকৃত identity provider configure করা। Google, Microsoft Entra, Okta, SAML এবং OIDC সমর্থিত। যেকোনো provider-এর জন্যও 32 বা তার বেশি character-এর BETTER_AUTH_SECRET, OAuth callback-এর জন্য public API base URL হিসেবে নির্ধারিত BETTER_AUTH_URL, INITIAL_ADMIN_EMAILS এবং TRUSTED_ORIGINS প্রয়োজন। Provider credential সম্পূর্ণ হতে হবে। কারণ provider আংশিকভাবে configure করা থাকলে startup বন্ধ হয়ে যায়; open access-এ fallback করে না। Account যোগ করার কারণ যদি হয় যে দলের প্রত্যেকে নিজের browser-এর বদলে নিজের agent চান, তাহলে OneCLI শুরু থেকেই এই কাঠামোকে কেন্দ্র করে তৈরি, যেখানে প্রত্যেক ব্যক্তির জন্য একটি sandboxed agent থাকে এবং model key একটি gateway-তে রাখা হয়।

App-টি যদি কোনো public name-এ পৌঁছানো যায়, তাহলে এর সামনে TLS (transport layer security) ব্যবহার করুন। localhost ছাড়া অন্য যেকোনো ক্ষেত্রে plain http://-এর মাধ্যমে পরিবেশিত page secure context নয়। তাই Secure হিসেবে চিহ্নিত cookie সংরক্ষিত হয় না, এবং sign-in ব্যর্থ হয় এমনভাবে, যা OpenBot-এর bug বলে মনে হতে পারে।

নিম্নস্তরের port-এ firewall প্রয়োগ করুন

OpenBot-এর নিজস্ব security note অনুযায়ী, নিম্নস্তরের service endpoint-গুলো token দিয়ে সুরক্ষিত। এগুলো private রাখতে হবে। Gateway এড়িয়ে যাওয়ার জন্য এগুলো ব্যবহার করা যাবে না। Token হলো দ্বিতীয় স্তরের সুরক্ষা। প্রথম স্তর হলো port-এ কোনোভাবেই পৌঁছানো না যায়।

Agent-computer 4100 port-এ listen করে এবং COMPUTER_TOKEN প্রয়োজন। Bot endpoint-গুলো 4200 এবং 4201 port-এ listen করে। Supervisor host-এ 4500 এবং তার container-এর ভিতরে 4300 port-এ listen করে। PostgreSQL 5432 port-এ listen করে। এগুলোর কোনোটি public interface-এ থাকা উচিত নয়। Single-user deployment-এ app এবং API-ও public interface-এ থাকা উচিত নয়।

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 ইনস্টল করে। ফলে traffic FORWARD path-এ প্রক্রিয়াকৃত হয় এবং ufw-এর default deny নিয়ন্ত্রণ করা INPUT chain-এর মধ্য দিয়ে যায় না। ufw status এখনও Status: active দেখালেও port খোলা থাকে। Mapping-এর মধ্যেই published port-কে loopback-এ bind করুন, যেমন -p 127.0.0.1:3001:3001, অথবা compose file-এ host address নির্ধারণ করুন। ss -ltnp দিয়ে যাচাই করুন, ufw status দিয়ে নয়। এই সমস্যা OpenBot-নির্দিষ্ট নয়। তাই এই মেশিনে publish করা অন্য প্রতিটি container-এর ক্ষেত্রেও একই পরীক্ষা চালান, যার মধ্যে 90s-এর video store হিসেবে পুনর্নির্মিত একটি Jellyfin library পরিবেশন করা container-ও রয়েছে।

OpenBot একটি offline stack নয়

Deployment পরিকল্পনা করার আগে এটি পরিষ্কারভাবে উল্লেখ করুন। OpenBot একটি CopilotKit Intelligence project-এর ওপর নির্ভর করে। এই project আপনার server-এর বাইরে durable thread এবং conversation memory সংরক্ষণ করে। Startup-এর সময় server INTELLIGENCE_API_URL, INTELLIGENCE_GATEWAY_WS_URL, INTELLIGENCE_API_KEY এবং COPILOTKIT_LICENSE_TOKEN যাচাই করে। চারটিই একসঙ্গে উপস্থিত না থাকলে startup ব্যর্থ হয়। August 2026 অনুযায়ী একটি free plan available আছে। Intelligence নিজেও self-host করা যায়। তাই quickstart-এ দেখানো পদ্ধতির চেয়ে বেশি কাজ করে সম্পূর্ণ local deployment করা সম্ভব।

Model হলো দ্বিতীয় external dependency। কোনো model box-এর মধ্যে bundled থাকে না। BOT_PROVIDER, openai, anthropic অথবা google গ্রহণ করে। OPENAI_BASE_URL OpenAI path-কে যেকোনো compatible endpoint-এ নির্দেশ করে। নিজের hardware-এ token রাখার জন্য VPS-এ Ollama চালিয়ে LLM self-host করা এই পদ্ধতিতে ব্যবহার করা যায়। Browser control-এর জন্য model-এর ওপর উল্লেখযোগ্য কাজের চাপ পড়ে। তাই কোনো local model-এর ওপর নির্ভর করার আগে একটি বাস্তব task-এ সেটি পরীক্ষা করুন।

এখন একটি replica চালান

gateway server process-এর memory-তে page snapshot cache করে। দুটি replica থাকলে একটি process-এর নেওয়া snapshot অন্য process দেখতে পায় না। ফলে element-not-found error-এর কারণে কাজগুলো মাঝে মাঝে ব্যর্থ হয় এবং কারণটি এলোমেলো মনে হয়। Deployment documentation-এ স্পষ্টভাবে বলা আছে: একটি মাত্র replica চালান এবং আপনার platform-এর maximum instance count 1-এ নির্দিষ্ট করে দিন। Snapshot caching database-এ স্থানান্তরিত হলে এই সীমা তুলে নেওয়া যাবে। ততদিন OpenBot scale করতে হলে অতিরিক্ত server যোগ করবেন না; বিদ্যমান server-এর capacity বাড়ান। Bot-গুলোর isolation per-bot container থেকেই আসে। একইভাবে self-hosted agent sandbox একটি agent-এর ভুল অন্য agent-গুলোর ওপর প্রভাব ফেলতে বাধা দেয়।

ব্যর্থতার ধরন এবং যে লক্ষণগুলো দেখবেন

.env পূরণ করার পর startup সঙ্গে সঙ্গে বন্ধ হয়ে যায়। Server কোনো কিছু পরিবেশন করার আগে configuration যাচাই করে। অসম্পূর্ণ Intelligence block, অনুপস্থিত KEY_ENCRYPTION_KEY, অথবা client ID থাকলেও secret না থাকা কোনো OAuth provider—প্রতিটি ক্ষেত্রেই startup নীরবে সীমিত ক্ষমতায় চলার বদলে বন্ধ হয়ে যায়। প্রথম error পড়ুন, ওই একটি field ঠিক করুন, তারপর আবার start করুন।

Managed database-এ migration ব্যর্থ হয়। vector extension ডিফল্টভাবে enabled থাকে না। তাই migration এমন একটি column type ব্যবহার করে, যেটি PostgreSQL চেনে না। superuser হিসেবে connect করুন, CREATE EXTENSION vector; চালান, তারপর migration ধাপটি আবার চালান।

App load হয়, কিন্তু sign-in স্থায়ী হয় না। আপনি public address-এ plain http:// ব্যবহার করছেন। এটি secure context নয়, তাই Secure cookie বাতিল হয়ে যায়। সামনে TLS বসান, অথবা SSH tunnel ব্যবহার করুন, যাতে browser localhost দেখতে পায়।

যে login-গুলো আলাদা থাকবে বলে আশা করেছিলেন, bot-গুলো সেগুলো ভাগ করে ব্যবহার করে। Supervisor চলছে না। তাই প্রতি bot-এর জন্য আলাদা computer নেই এবং সব bot shared browser ব্যবহার করছে। COMPUTER_SUPERVISOR_URL সেট করা আছে কি না এবং supervisor Docker socket-এ পৌঁছাতে পারে কি না নিশ্চিত করুন।

একটি bot থেমে সাহায্য চায়। এটাই নকশা অনুযায়ী কাজ করার লক্ষণ। Audit trail-এ computer.help_requested রেকর্ড হয়, আপনি live screen-এ নিয়ন্ত্রণ নেন, এবং handover উভয় পাশে রেকর্ড হয়।

FAQ

VPS deployment-এর জন্য OPENBOT_SINGLE_USER চালু রাখা কি নিরাপদ?

শুধু তখনই, যখন gateway Internet থেকে পৌঁছানো যায় না। OPENBOT_SINGLE_USER=true কোনো sign-in ছাড়াই প্রতিটি request-কে একজন administrator হিসেবে গ্রহণ করে। তাই port খুলতে পারে এমন যে কেউ deployment, সংরক্ষিত credential এবং sign-in করা browser-এর নিয়ন্ত্রণ পেয়ে যায়। প্রতিটি port 127.0.0.1-এ bind করা থাকলে এবং 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 bot-এর কত RAM প্রয়োজন?

একটি Bot-এর জন্য project-এর প্রকাশিত হিসাব arm64-এ সর্বোচ্চ memory 0.55 GB দেখায়। নথিভুক্ত minimum হলো 2 GB এবং recommended মান 4 GB। একসঙ্গে একাধিক bot চালানোর প্রকাশিত হিসাব নেই, কারণ প্রতিটি bot নিজস্ব Chromium ধরে রাখে। বাস্তব কোনো task-এ একটি bot চালান। docker stats-এ ওই container-এর memory দেখুন। gateway ও database-এর memory যোগ করুন। এরপর একই সময়ে চলবে এমন bot-এর সংখ্যা দিয়ে গুণ করুন।

OpenBot self-host করতে কি CopilotKit account প্রয়োজন?

হ্যাঁ। durable thread ও memory-এর জন্য OpenBot একটি CopilotKit Intelligence project-এর ওপর নির্ভর করে। Intelligence API URL, gateway WebSocket URL, API key এবং license token সেট না করা থাকলে server start হতে অস্বীকার করে। August 2026 অনুযায়ী একটি free plan আছে। Intelligence self-host করা যায়। তাই অতিরিক্ত কাজ করে hosted dependency বাদ দেওয়া সম্ভব। আপনাকে নিজের model API key-ও দিতে হবে, কারণ OpenBot-এর সঙ্গে কোনো model ship করে না।

প্রতিটি bot একটি browser ব্যবহার করে কেন? তারা একটি browser ভাগ করে ব্যবহার করে না কেন?

কারণ browser profile একটি identity। Shared browser হলে cookie ও session-ও shared হয়। তাই একটি bot কোনো account-এ sign in করলে প্রতিটি bot সেই account-এ sign in করা থাকে। Per-bot container প্রতিটি coworker-কে নিজস্ব profile ও নিজস্ব login দেয়। এর বিনিময়ে memory বেশি লাগে। Sizing-এ প্রতি bot-এর জন্য একটি Chromium-ই সবচেয়ে বড় একক উপাদান।

Firewall-এ কোন OpenBot port খোলা রাখা উচিত?

নিচের স্তরের কোনো port-ই নয়। 4100-এ agent-computer, 4200 ও 4201-এ bot endpoint, 4500-এ supervisor এবং 5432-এ PostgreSQL—সবই private থাকবে। Project এগুলো token দিয়ে সুরক্ষিত রাখে এবং তবুও এগুলো unreachable রাখার নির্দেশ দেয়। শুধু মানুষের খোলার প্রয়োজন আছে এমন port publish করুন। মনে রাখুন, -p 3001:3001 দিয়ে publish করা container port ufw-এর default-deny rule থাকলেও পৌঁছানো যায়। কারণ Docker-এর DNAT rule ওই traffic-কে FORWARD path-এ পাঠায়, INPUT path-এ নয়।