VPS-এ OpenBot AI coworker নিজে হোস্ট করার গাইড

নিজে হোস্ট করা OpenBot AI coworker-এ যা পাবেন

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

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

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

প্রতিটি action-এর সিদ্ধান্ত gateway কীভাবে নেয়

3001 port-এর API server-ই bot-এর computer-এ যাওয়ার একমাত্র পথ। Browser action চালানোর আগে gateway page snapshot থেকে target নির্ধারণ করে, context-এর বিরুদ্ধে CEL (common expression language) policy rule মূল্যায়ন করে, সিদ্ধান্তটি audit row-তে লেখে, এবং তারপরই container-কে কল করে। এরপর execution ব্যর্থ হলে এটি দ্বিতীয় একটি row লেখে। Documentation-এ boundary-টি স্পষ্টভাবে বলা আছে: computer policy নির্ধারণ করে না; server gateway-ই action boundary।

Policy-তে deny-by-default ব্যবহৃত হয়, এবং allow rule-এর আগে deny rule মূল্যায়ন করা হয়। Rule syntax-এর চেয়ে ব্যর্থতার দিক বেশি গুরুত্বপূর্ণ। Policy না থাকলে কোনো কিছু অনুমোদিত হয় না। কোনো rule-এ সমস্যা হলে সেটি deny rule হোক বা allow rule, ফল blocking-এর দিকে যায়। তাই policy-তে ভুল হলে bot আপনার account-গুলোতে অবাধে কাজ করার বদলে আটকে যাবে।

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

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

প্রকল্পটি arm64-এ একটি Bot-এর পরিমাপ করা তথ্য প্রকাশ করে। OpenBot যে sizing সংখ্যা প্রকাশ করে, এগুলোই সেগুলোর একমাত্র সেট। এগুলো একটি architecture-এ একটি bot-এর বর্ণনা দেয়। তাই এগুলোকে capacity plan নয়, প্রাথমিক হিসাব হিসেবে ব্যবহার করুন।

[
  {
    "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। পরিমাপ করা মান এবং minimum-এর পার্থক্যটি load-এর সময় Chromium-এর memory বৃদ্ধির জন্য রাখা headroom। কারণ browser idle অবস্থায় process যত memory ব্যবহার করে, খোলা page-এর ওপর তার memory ব্যবহার ততটাই নির্ভর করে। Idle CPU প্রায় শূন্যের কাছাকাছি। পরিমাপ করা সর্বোচ্চ সীমায় এটি core-এর 0.06 ব্যবহার করে। তাই আপনি মূলত CPU কিনছেন না। Disk-ই গুরুত্বপূর্ণ। শুধু image-এর আকার 5.3 GB, যেখানে recommended volume হলো 10 GB। Image এত বড় হওয়ার কারণ হলো Chromium-এর পাশাপাশি এতে Playwright-এর Firefox এবং WebKit binary-ও থাকে।

এগুলো থেকে একসঙ্গে একাধিক bot চালানোর খরচ জানা যায় না। প্রকল্পও এর কোনো সংখ্যা প্রকাশ করে না। নিজের পরিবেশে পরিমাপ করুন। একটি bot চালু করুন, খোলা page-সহ একটি বাস্তব কাজ দিন, এবং কাজ চলার সময় container monitor করুন।

docker stats --no-stream
free -m

Bot-এর container-এর জন্য MEM USAGE column-এর মান নিন। এর সঙ্গে gateway এবং PostgreSQL-এর ব্যবহার যোগ করুন। এরপর একই সময়ে চলবে বলে প্রত্যাশিত bot-এর সংখ্যা দিয়ে প্রতি-bot মান গুণ করুন। Idle bot-ও একটি browser process ধরে রাখে। তাই এই multiplier বিদ্যমান bot-এর ক্ষেত্রে প্রযোজ্য, শুধু ব্যস্ত bot-এর ক্ষেত্রে নয়। এই হিসাব 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 কীভাবে নিজে host করবেন?

আপনার Docker, Bun 1.3 বা পরবর্তী সংস্করণ, একটি CopilotKit Intelligence project এবং একটি model API key প্রয়োজন। Development docs-এ সার্ভারে lsof, python3 এবং curl থাকাও প্রত্যাশিত। main-এর পরিবর্তে tag করা 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 runtime key এবং license token আপনার environment file-এ লিখবে।

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-এ response দেয়। Script port conflict জানায় এবং একই configuration-এর আগে থেকে চলমান 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 serve করছে। দ্বিতীয় 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 থাকা একটি single 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 সেট ব্যবহার করে। এতে সেই 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 কেন laptop-এর জন্য একটি setting

.env.example-এর সঙ্গে OPENBOT_SINGLE_USER=true থাকে। এই setting প্রতিটি request-কে একজন administrator হিসেবে গ্রহণ করে এবং sign-in সম্পূর্ণভাবে এড়িয়ে যায়। laptop-এ এটি সুবিধাজনক, কারণ port-এ পৌঁছাতে পারে এমন একমাত্র client হলেন আপনি। VPS-এ এর অর্থ হল, port 3010-এ প্রথম যে ব্যক্তি পৌঁছাবে, সে এমন একটি system-এর administrator হয়ে যাবে যেখানে encrypted credential সংরক্ষিত আছে এবং আপনার 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

তখন app আপনার নিজের browser-এ 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 সম্পূর্ণ হতে হবে। কারণ আংশিকভাবে configure করা provider startup বন্ধ করে দেয়; open access-এ fallback করে না।

যদি app কোনো public name-এ reachable হয়, তার সামনে 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 bypass করতে ব্যবহার করা যাবে না। 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-এ থাকা উচিত নয়। একক-ব্যবহারকারীর 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 নির্ধারণ করুন। ufw status দিয়ে নয়, ss -ltnp দিয়ে যাচাই করুন।

OpenBot অফলাইন stack নয়

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

Model হলো দ্বিতীয় external dependency। OpenBot-এর সঙ্গে কোনো model অন্তর্ভুক্ত নেই। BOT_PROVIDER, openai, anthropic অথবা google গ্রহণ করে। OPENAI_BASE_URL OpenAI path-কে যেকোনো compatible endpoint-এ নির্দেশ করে। আপনার token নিজের hardware-এ রাখতে চাইলে 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 সহ action-গুলো অনিয়মিতভাবে ব্যর্থ হয় এবং কারণটি random বলে মনে হয়। Deployment documentation-এ স্পষ্টভাবে বলা আছে: একটি replica চালান এবং আপনার platform-এর maximum instance count 1-এ সীমাবদ্ধ রাখুন। Snapshot caching database-এ স্থানান্তরিত হলে এই সীমা আর থাকবে না। ততদিন OpenBot scale করতে server-এর capacity বাড়ান, নতুন server যোগ করবেন না। Bot-গুলোর মধ্যে isolation per-bot container থেকেই আসে। একইভাবে self-hosted agent sandbox একটি agent-এর ভুলকে অন্য agent-গুলোর কাছ থেকে আলাদা রাখে।

ব্যর্থতার ধরন এবং আপনি যা দেখতে পাবেন

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

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

অ্যাপ লোড হয়, কিন্তু 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 এবং আপনার signed-in browser-এর নিয়ন্ত্রণ পেয়ে যায়। সব port 127.0.0.1-এ bind করা থাকলে এবং আপনি SSH tunnel বা private network interface-এর মাধ্যমে app-এ পৌঁছালে এটি গ্রহণযোগ্য। Public interface-এ এটি বন্ধ করুন এবং BETTER_AUTH_SECRET, BETTER_AUTH_URL, INITIAL_ADMIN_EMAILS ও TRUSTED_ORIGINS-এর সঙ্গে Google, Microsoft Entra, Okta বা OIDC configure করুন।

একটি OpenBot bot-এর কত RAM প্রয়োজন?

একটি arm64 Bot-এর জন্য প্রকল্পের প্রকাশিত হিসাব অনুযায়ী peak 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 সরবরাহ করা হয় না।

প্রতিটি 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 বেশি লাগে, কারণ প্রতিটি bot-এর জন্য একটি Chromium sizing-এর সবচেয়ে বড় একক উপাদান।

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

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