OpenBot AI 코워커 VPS 직접 호스팅 및 메모리 최적화 가이드

OpenBot AI 코워커를 직접 호스팅할 때 얻는 것

OpenBot AI 코워커를 직접 호스팅하려면 제어 가능한 하드웨어에서 게이트웨이 서버 1대와 봇당 컨테이너 1개를 실행해야 합니다. 각 봇 컨테이너는 자체 Chromium 브라우저와 작업 공간 볼륨을 가지며, 세션 간에 유지되는 브라우저 프로필을 사용합니다. 봇이 컴퓨터, 파일, MCP(model context protocol) 서버 또는 UI 구성 요소에서 수행하는 모든 작업은 게이트웨이를 거칩니다. 게이트웨이는 작업 실행 전 정책을 확인하고 실행 후 기록을 남깁니다. 게이트웨이가 감싸고 있는 에이전트 루프가 아직 생소하다면, AI 에이전트 기초부터 학습하기의 단계별 경로를 따라 봇에게 브라우저와 로그인 정보를 맡기기 전에 직접 작은 루프를 작성해 보십시오.

OpenBot은 CopilotKit이 MIT 라이선스로 github.com/CopilotKit/openbot에 공개했습니다. 첫 번째 태그된 릴리스인 v0.0.1은 2026년 8월 17일에 발표되었으며, 프로젝트는 현재 알파 단계로 활발히 개발 중입니다. 초기 단계의 거친 부분이 있는 진지한 설계로 간주하십시오.

이 아키텍처의 흥미로운 부분은 비용이 많이 드는 부분이기도 합니다. 에이전트마다 브라우저를 할당하는 것은 많은 사람이 간과하는 메모리 비용이므로, 설치 전에 규모 산정이 선행되어야 합니다.

게이트웨이가 모든 동작을 결정하는 방식

포트 3001에서 실행되는 API 서버는 봇의 컴퓨터로 향하는 유일한 경로입니다. 브라우저 동작이 실행되기 전에 게이트웨이는 페이지 스냅샷에서 대상을 확인하고, 컨텍스트에 대해 CEL(Common Expression Language) 정책 규칙을 평가하며, 결정 사항을 담은 감사 행을 기록한 뒤에야 컨테이너를 호출합니다. 그 이후 실행에 실패하면 두 번째 행을 기록합니다. 문서는 이 경계를 명확히 명시합니다. 컴퓨터는 정책을 결정하지 않으며, 서버 게이트웨이가 동작의 경계가 됩니다. 이 분리 구조는 OpenBot 외부에서도 통용되는 개념입니다. 루프, 도구 정의, 권한 검사, 세션 상태가 모두 모델을 감싸는 하네스를 구성하며, 이 게이트웨이는 그중 권한 제어의 절반을 담당합니다.

정책은 기본적으로 거부(deny-by-default) 원칙을 따르며, 거부 규칙은 허용 규칙보다 먼저 평가됩니다. 규칙 구문보다 실패 방향이 더 중요합니다. 정책이 없으면 아무것도 허용되지 않으며, 규칙이 잘못되면 거부 규칙이든 허용 규칙이든 상관없이 차단되는 방향으로 실패합니다. 따라서 정책에 실수가 있더라도 봇이 계정에 무단으로 접근하는 대신 봇이 멈추는 결과가 발생합니다. 이 계층은 봇이 무엇을 읽는지가 아니라 무엇을 수행하는지를 제어합니다. 따라서 에이전트를 겨냥한 지시 사항이 포함된 페이지는 별개의 문제로 남으며, 이는 직접 운영하는 SearXNG 인스턴스의 결과를 에이전트에게 전달할 때 직면하는 프롬프트 인젝션 공격 표면과 동일합니다.

감사 기록은 PostgreSQL에 저장되므로 재시작 후에도 유지됩니다. 제어권 이양은 computer.help_requested, computer.control_taken, computer.control_released로 기록됩니다. 이를 통해 봇이 인간의 개입을 요청하는 과정과 인간이 제어권을 다시 넘겨주는 과정을 확인할 수 있습니다. 비밀 정보는 값이 아닌 문자 수로 기록됩니다. 파일 작업은 경로와 크기만 기록하며 내용은 기록하지 않습니다. 브라우저 없이 동일한 제어 경계를 원한다면, 승인 절차를 통해 AI 에이전트 동작을 제어하는 방법에서 더 좁은 범위의 사례를 다룹니다.

봇 하나당 필요한 RAM과 디스크 용량

이 프로젝트는 arm64 환경에서 단일 Bot에 대한 측정치를 공개합니다. 이는 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 GB로 측정되었으며, 문서화된 최소 사양은 2 GB, 권장 사양은 4 GB입니다. 측정치와 최소 사양 사이의 간극은 부하 발생 시 Chromium이 확장될 여유 공간입니다. 브라우저의 메모리 사용량은 유휴 상태가 아닌, 열려 있는 페이지에 따라 변하기 때문입니다. 유휴 상태의 CPU 사용량은 측정 범위 최상단에서 코어의 0.06 수준으로 거의 0에 가깝습니다. 즉, CPU는 자원 확보의 핵심이 아닙니다. 핵심은 디스크입니다. 이미지 크기만 5.3 GB이며 권장 볼륨은 10 GB입니다. 이미지 크기가 큰 이유는 Chromium 외에도 Playwright의 Firefox 및 WebKit 바이너리를 함께 포함하고 있기 때문입니다.

이 수치들만으로는 여러 봇을 동시에 운영할 때의 비용을 알 수 없으며, 프로젝트 측에서도 이에 대한 수치를 제공하지 않습니다. 문서화된 최소 사양은 부하 상태에서 검증된 수치라기보다 프로젝트 측에서 제시하기에 무난한 수치입니다. 이것이 바로 PhotoPrism과 Immich 사이에서 선택하기가 공식 발표된 RAM 사양이 아닌 실제 측정된 RAM 하한선을 기준으로 결정되는 이유입니다. 직접 측정하십시오. 봇 하나를 실행하고 실제 페이지를 여는 작업을 수행한 뒤, 작업 중인 컨테이너를 모니터링하십시오.

docker stats --no-stream
free -m

봇 컨테이너의 MEM USAGE 열을 봇 하나당 수치로 잡고, 여기에 게이트웨이와 PostgreSQL 사용량을 더한 뒤, 동시에 운영할 봇의 수만큼 곱하십시오. 유휴 상태의 봇도 브라우저 프로세스를 유지하므로, 이 배수는 작업 중인 봇뿐만 아니라 존재하는 모든 봇에 적용됩니다. 이 계산 방식은 코딩 에이전트 VPS를 위한 RAM 및 CPU 사이징에서 사용하는 방식과 동일하며, 브라우저 관련 내용은 VPS에서 에이전트를 위한 헤드리스 브라우저 실행하기에서 다룹니다.

Chromium의 한 가지 세부 사항이 소규모 플랜에 영향을 미칩니다. OpenBot은 --disable-dev-shm-usage 옵션으로 Chromium을 실행하므로, 브라우저는 /dev/shm 대신 /tmp에 데이터를 씁니다. 이는 /dev/shm가 작은 호스트에서 발생하는 충돌을 방지하며, 부하를 루트 파일시스템으로 분산시킵니다. 권장 디스크 용량이 이미지 크기보다 큰 또 다른 이유가 바로 이것입니다.

VPS에서 OpenBot을 직접 호스팅하는 방법

Docker, Bun 1.3 이상, CopilotKit Intelligence 프로젝트, 그리고 모델 API 키가 필요합니다. 개발 문서에서는 서버에 lsof, python3, curl가 설치되어 있을 것을 전제로 합니다. main는 알파 프로젝트에서 예고 없이 변경될 수 있으므로, main 대신 태그가 지정된 릴리스를 복제하십시오.

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을 실행하며 시작 시 마이그레이션을 적용합니다. 명명된 볼륨(named volume)은 재배포 시에도 감사 기록을 유지하며, 이 볼륨이 없으면 재빌드할 때마다 해당 기록이 삭제됩니다. 만약 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)도 포함하지 않는데, 이는 슈퍼바이저가 Docker 소켓을 필요로 하지만 서버리스 플랫폼은 이를 제공하지 않기 때문입니다. 슈퍼바이저가 없으면 모든 봇이 하나의 브라우저를 공유하게 되어 로그인 정보도 공유하게 되며, 이는 봇별 컨테이너를 운영하는 핵심 이유인 격리성을 제거합니다. 봇별로 개별 로그인이 필요한 경우, 해당 위험을 감수할 수 있는 호스트에서 COMPUTER_SUPERVISOR_URL와 SUPERVISOR_TOKEN을 설정하여 compose 스택을 실행하십시오. Docker 소켓에 접근할 수 있는 프로세스는 권한이 부여된 컨테이너를 시작할 수 있으므로, 사실상 호스트의 root 권한을 갖는 것과 같습니다. 이러한 이유로 코딩 에이전트에게 일회용 VM 제공하기와 같은 맥락에서 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로 나타나며, 이는 보안 컨텍스트로 간주됩니다. 따라서 로그인 쿠키와 라이브 화면에 필요한 브라우저 기능이 모두 정상적으로 작동합니다. 다른 방법은 싱글 유저 모드를 끄고 실제 ID 공급자(Identity Provider)를 설정하는 것입니다. Google, Microsoft Entra, Okta, SAML 및 OIDC를 지원합니다. 어떤 공급자를 사용하든 32자 이상의 BETTER_AUTH_SECRET, OAuth 콜백을 위한 공용 API 기본 URL로 설정된 BETTER_AUTH_URL, INITIAL_ADMIN_EMAILS, 그리고 TRUSTED_ORIGINS가 필요합니다. 공급자 설정이 불완전하면 오픈 액세스로 전환되는 대신 시작 단계에서 중단되므로, 자격 증명을 모두 정확히 입력해야 합니다. 팀원 각자가 브라우저가 아닌 자신만의 에이전트를 원해서 계정을 추가하는 경우라면, OneCLI는 처음부터 그러한 구조로 설계되었습니다. 이 방식은 사람마다 샌드박스 처리된 에이전트를 하나씩 할당하고 모델 키는 단일 게이트웨이에서 관리합니다.

앱을 공용 도메인으로 접근할 수 있게 하려면 앞에 TLS(transport layer security)를 배치하십시오. localhost를 제외한 환경에서 일반 http://으로 제공되는 페이지는 보안 컨텍스트가 아닙니다. 따라서 Secure로 표시된 쿠키가 저장되지 않으며, OpenBot의 버그처럼 보이는 로그인 실패 현상이 발생합니다.

하위 레벨 포트 방화벽 설정

OpenBot의 보안 공지에 따르면 하위 레벨 서비스 엔드포인트는 토큰으로 보호되며, 이를 비공개로 유지하고 게이트웨이를 우회하는 용도로 사용해서는 안 됩니다. 토큰은 두 번째 보호 수단입니다. 첫 번째 보호 수단은 포트에 아예 접근할 수 없도록 만드는 것입니다.

에이전트 컴퓨터는 4100 포트에서 대기하며 COMPUTER_TOKEN를 요구합니다. 봇 엔드포인트는 4200 및 4201 포트에서 대기합니다. 슈퍼바이저는 호스트의 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 경로에서 처리되며, ufw의 기본 거부 정책이 적용되는 INPUT 체인을 전혀 거치지 않게 됩니다. ufw status이 여전히 Status: active을 출력하더라도 포트는 열려 있는 상태로 유지됩니다. 게시된 포트를 -p 127.0.0.1:3001:3001과 같이 루프백 주소에 바인딩하거나, compose 파일에서 호스트 주소를 설정하십시오. ufw status이 아닌 ss -ltnp를 사용하여 확인하십시오. 이 함정은 OpenBot에만 국한된 것이 아니므로, 90년대 비디오 가게 스타일로 재구성된 Jellyfin 라이브러리를 서비스하는 것을 포함하여 서버에 게시된 모든 컨테이너에 대해 동일한 점검을 수행하십시오.

OpenBot은 오프라인 스택이 아닙니다

배포를 계획하기 전에 이 점을 명시하십시오. OpenBot은 영구적인 스레드와 대화 메모리를 서버 외부에서 유지하는 CopilotKit Intelligence 프로젝트에 의존합니다. 서버는 시작 시 INTELLIGENCE_API_URL, INTELLIGENCE_GATEWAY_WS_URL, INTELLIGENCE_API_KEY 및 COPILOTKIT_LICENSE_TOKEN를 검증하며, 이 네 가지가 모두 존재하지 않으면 시작에 실패합니다. 2026년 8월 기준으로 무료 플랜을 사용할 수 있으며, Intelligence 자체도 자체 호스팅이 가능하므로 퀵스타트 가이드보다 더 많은 작업을 수행하면 완전히 로컬 환경에 배포할 수 있습니다.

모델은 두 번째 외부 의존성입니다. 기본적으로 포함된 것은 없습니다. BOT_PROVIDER는 openai, anthropic 또는 google을 허용하며, OPENAI_BASE_URL는 OpenAI 경로를 호환되는 모든 엔드포인트로 지정합니다. 토큰을 자신의 하드웨어에서 처리하고 싶다면 VPS에서 Ollama를 실행하여 LLM 자체 호스팅하기를 활용할 수 있습니다. 브라우저 제어는 모델에 많은 부하를 요구하므로, 로컬 모델을 도입하기 전에 실제 작업에서 먼저 테스트하십시오.

현재는 복제본을 하나만 실행하십시오

게이트웨이는 서버 프로세스 메모리에 페이지 스냅샷을 캐싱합니다. 복제본이 2개일 경우 한 프로세스가 생성한 스냅샷을 다른 프로세스에서 볼 수 없으므로, element-not-found 오류가 무작위로 발생하며 작업이 간헐적으로 실패합니다. 배포 문서에는 복제본을 하나만 실행하고 플랫폼의 최대 인스턴스 수를 1로 고정하라고 명시되어 있습니다. 이 제한은 스냅샷 캐싱이 데이터베이스로 이전되면 해제됩니다. 그전까지는 서버를 추가하는 방식이 아니라 서버의 사양을 높이는 방식으로 OpenBot을 확장해야 합니다. 봇 간의 격리는 self-hosted agent sandboxes가 한 에이전트의 오류가 다른 에이전트에 영향을 주지 않도록 하는 것과 동일한 방식으로, 봇별 컨테이너를 통해 이루어집니다.

실패 유형 및 확인 사항

.env을(를) 입력한 직후 시작 프로세스가 즉시 종료됩니다. 서버는 서비스를 제공하기 전에 설정을 검증합니다. Intelligence 블록이 불완전하거나, KEY_ENCRYPTION_KEY이(가) 누락되었거나, 클라이언트 ID는 있지만 비밀 키가 없는 OAuth 제공자가 설정된 경우, 서버는 조용히 성능을 저하시키는 대신 시작을 중단합니다. 첫 번째 오류 메시지를 읽고 해당 필드를 수정한 뒤 다시 시작하십시오.

관리형 데이터베이스에서 마이그레이션이 실패합니다. vector 확장 기능이 기본적으로 활성화되어 있지 않아, 마이그레이션 과정에서 PostgreSQL이 인식하지 못하는 열 유형이 발생합니다. 슈퍼유저 권한으로 접속하여 CREATE EXTENSION vector;을(를) 실행한 다음, 마이그레이션 단계를 다시 수행하십시오.

애플리케이션은 로드되지만 로그인이 유지되지 않습니다. 공개 주소에서 일반 http://을(를) 통해 서비스를 제공하고 있습니다. 이는 보안 컨텍스트가 아니므로 Secure 쿠키가 폐기됩니다. 프록시 앞에 TLS를 적용하거나, 브라우저가 localhost을(를) 인식할 수 있도록 SSH 터널을 사용하십시오.

봇들이 별도로 분리되어야 할 로그인을 공유합니다. 슈퍼바이저가 실행되고 있지 않아 봇별 컴퓨터 환경이 생성되지 않으며, 모든 봇이 공유 브라우저를 사용합니다. COMPUTER_SUPERVISOR_URL이(가) 설정되어 있는지, 그리고 슈퍼바이저가 Docker 소켓에 접근할 수 있는지 확인하십시오.

봇이 멈추고 도움을 요청합니다. 이는 설계된 대로 작동하는 것입니다. 감사 추적(audit trail)에 computer.help_requested이(가) 기록되며, 사용자가 라이브 화면에서 제어권을 가져오면 양쪽 모두에 인계 기록이 남습니다.

FAQ

VPS 배포 시 OPENBOT_SINGLE_USER를 켜두어도 안전합니까?

인터넷에서 게이트웨이에 접근할 수 없는 경우에만 안전합니다. 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 GB이며, 문서화된 최소 사양은 2 GB, 권장 사양은 4 GB입니다. 각 봇은 독립적인 Chromium 인스턴스를 유지하므로 여러 봇을 동시에 실행할 때의 수치는 별도로 공개되어 있지 않습니다. 실제 작업에서 봇 하나를 실행한 뒤 docker stats에서 해당 컨테이너의 메모리 사용량을 확인하고, 게이트웨이와 데이터베이스 사용량을 더한 다음, 동시에 운영할 봇의 수만큼 곱하여 계산하십시오.

OpenBot을 자체 호스팅하려면 CopilotKit 계정이 필요합니까?

네, 필요합니다. OpenBot은 지속적인 스레드와 메모리를 위해 CopilotKit Intelligence 프로젝트에 의존하며, Intelligence API URL, 게이트웨이 WebSocket URL, API 키, 라이선스 토큰이 모두 설정되지 않으면 서버가 시작되지 않습니다. 2026년 8월 기준으로 무료 플랜을 이용할 수 있으며, Intelligence는 자체 호스팅도 가능하므로 추가 작업을 통해 호스팅된 의존성을 제거할 수 있습니다. 또한 OpenBot에는 기본 제공되는 모델이 없으므로 직접 모델 API 키를 제공해야 합니다.

왜 봇들이 브라우저를 공유하지 않고 각자 하나씩 사용합니까?

브라우저 프로필이 곧 신원이기 때문입니다. 브라우저를 공유하면 쿠키와 세션도 공유되므로, 한 봇이 특정 계정에 로그인하면 모든 봇이 해당 계정에 로그인된 상태가 됩니다. 봇별로 컨테이너를 분리하면 각 작업자에게 고유한 프로필과 로그인 정보를 부여할 수 있습니다. 그 대가는 메모리 사용량이며, 봇당 하나씩 할당되는 Chromium이 전체 크기 산정에서 가장 큰 비중을 차지합니다.

방화벽에서 어떤 OpenBot 포트를 열어야 합니까?

하위 레벨 포트는 모두 열지 마십시오. 4100번의 에이전트 컴퓨터, 4200번과 4201번의 봇 엔드포인트, 4500번의 슈퍼바이저, 5432번의 PostgreSQL은 모두 비공개로 유지해야 합니다. 프로젝트는 토큰을 통해 이들을 보호하며, 애초에 외부에서 접근할 수 없도록 유지할 것을 권장합니다. 사람이 직접 열어야 하는 포트만 공개하십시오. -p 3001:3001으로 게시된 컨테이너 포트는 ufw의 기본 거부 규칙과 관계없이 접근 가능하다는 점을 명심하십시오. Docker의 DNAT 규칙이 해당 트래픽을 INPUT이 아닌 FORWARD 경로로 처리하기 때문입니다.