OpenBot VPS 自行代管：AI 協作者與記憶體需求

自行代管 OpenBot AI 協作者後可獲得的內容

您可以在自行控制的硬體上執行一台 gateway server，並為每個 bot 執行一個 container，藉此自行代管 OpenBot AI 協作者。每個 bot container 都包含自己的 Chromium 瀏覽器與 workspace volume，並使用可在工作階段之間保留狀態的瀏覽器 profile。bot 在電腦、檔案、MCP (model context protocol) server 或 UI 元件上執行的每個動作，都會經過該 gateway。gateway 會先依據 policy 檢查動作，執行後再記錄。如果您還不熟悉 gateway 所包裝的 agent loop，從頭學習 AI agent 的分階段流程會先帶您自行撰寫一個簡易版本，再讓 bot 使用瀏覽器與您的登入資訊。

OpenBot 由 CopilotKit 以 MIT 授權條款發布，位於 github.com/CopilotKit/openbot。第一個標記版本 v0.0.1 於 17 August 2026 發布。截至 20 October 2026，最新版本為 v0.2.0，於 12 October 2026 發布；該專案仍將自身描述為 alpha，並處於積極開發階段。請將它視為設計完整但仍處於早期階段的專案。

這種架構最有趣的部分，也是成本最高的部分。每個 agent 都需要一個瀏覽器，這是多數人規劃時最容易忽略的記憶體成本。因此，本指南會先進行容量規劃，再開始安裝。

閘道如何決定每項操作

3001 埠上的 API 伺服器是通往機器人電腦、受治理的路徑。該電腦也會提供受 token 保護的低階服務端點。專案要求將這些端點保持私有，絕不可用來繞過閘道。因此，只有在這些端點無法連線時，閘道才是唯一入口。瀏覽器操作執行前，閘道會從頁面快照解析目標，根據內容評估 CEL（common expression language）政策規則，寫入包含決策的稽核資料列，然後才呼叫容器。若執行在此之後失敗，閘道會再寫入第二筆資料列。文件清楚說明這個界線：電腦不負責決定政策，伺服器閘道才是操作界線。這種區分在 OpenBot 之外有一個名稱，因為迴圈、工具定義、權限檢查與工作階段狀態共同構成 包覆模型的 harness，而這個閘道就是其中的權限部分。

政策評估採取預設拒絕，且會先評估 deny 規則，再評估 allow 規則。失敗時的處理方向比規則語法更重要。缺少政策或政策為空時，不允許任何操作；規則損壞時也會朝阻擋方向處理，不論該規則是 deny 規則還是 allow 規則。因此，政策中的錯誤只會讓機器人卡住，不會讓機器人不受限制地操作你的帳號。OpenBot 隨附的政策則不同。其啟動預設值為 deny: []，並搭配 allow: ["true"]，在 AGENT_COMPUTER_POLICY 或已儲存的管理員政策取代它之前，會允許所有操作。因此，讓機器人接觸任何實際環境前，請先自行撰寫政策。這一層控制機器人的操作內容，不控制它讀取的內容。因此，帶有針對代理程式指示的頁面仍是另一個問題；這與 將自有 SearXNG 執行個體的結果交給代理程式 時所面對的 prompt injection 攻擊面相同。

稽核軌跡儲存在 PostgreSQL，因此重新啟動後仍會保留。控制權交接會記錄為 computer.help_requested、computer.control_taken 和 computer.control_released。你可以藉此查看機器人要求人工介入，以及人工將控制權交還的情況。secret 只會記錄字元數，絕不記錄其值。檔案讀取、寫入與列出操作會顯示在 Activity 分頁中；已儲存的檔案會顯示其路徑與大小，絕不顯示內容。該畫面狀態保存在瀏覽器中，不是稽核記錄。若你想在沒有瀏覽器的情況下，採用相同的控制界線，透過核准機制控管 AI 代理程式操作 說明了這個較狹義的使用情境。

單一 Bot 的 RAM 與磁碟需求

專案公布了 arm64 上單一 Bot 的實測數據。這些是部署文件列出的容量規劃數字，描述的是單一架構上的單一 Bot，因此應視為起始值，而不是容量配置方案。

[
  {
    "label": "Measured, one Bot",
    "memory_gb": 0.55,
    "disk_gb": 1.4,
    "vcpu": 0.06
  },
  {
    "label": "Documented minimum",
    "memory_gb": 2,
    "disk_gb": 4,
    "vcpu": 1
  },
  {
    "label": "Documented recommended",
    "memory_gb": 4,
    "disk_gb": 8,
    "vcpu": 2
  }
]

單一 Bot 的記憶體峰值實測為 0.55 GB，文件列出的最低需求為 2 GB，建議值則為 4 GB。實測值與最低需求之間的差距，是預留給 Chromium 在負載下成長的空間，因為瀏覽器的記憶體用量取決於目前開啟的頁面，而不是閒置時的程序用量。文件指出，同時多開每個頁面約需增加 100 到 200 MB。閒置 CPU 用量幾乎為零，實測範圍最高約為核心的 0.06，因此 CPU 並不是主要需求。映像檔大小為 1.4 GB，建議的 volume 大小為 8 GB，差額是預留給 /workspace 的空間，Bot 會在其中保存檔案。映像檔只包含 Chromium 系列的瀏覽器，不包含 Playwright 的 Firefox 與 WebKit。

這些數據無法告訴你同時執行多個 Bot 的需求，而專案也沒有公布相關數字。文件列出的最低需求，是專案認為適合公布的數字，不是有人在負載下實測的數字。因此，在 PhotoPrism 與 Immich 之間選擇時，應以實測的 RAM 下限為依據，而不是公布值。請自行測量。啟動一個 Bot，讓它執行包含已開啟頁面的實際工作，並在執行期間監控容器。

docker stats --no-stream
free -m

將 Bot 容器的 MEM USAGE 欄位作為單一 Bot 的需求值，再加上 gateway 與 PostgreSQL 的需求，最後將單一 Bot 的需求值乘以預計同時存在的 Bot 數量。閒置中的 Bot 仍會保留瀏覽器程序，因此乘數應套用到所有存在的 Bot，而不只是正在處理工作的 Bot。計算方式與為 coding agent VPS 規劃 RAM 與 CPU相同；瀏覽器部分則請參閱在 VPS 上為 agents 執行 headless browser。

有一項 Chromium 細節會影響小型方案。OpenBot 使用 --disable-dev-shm-usage 啟動 Chromium，因此瀏覽器會將資料寫入 /tmp，而不是 /dev/shm。這可避免主機的 /dev/shm 較小時發生當機，但會將壓力轉移到 root filesystem，因此建議的磁碟空間會大於映像檔大小。

如何在 VPS 上自架 OpenBot？

你需要 Docker、Bun 1.3 或更新版本、CopilotKit Intelligence 專案，以及模型 API key。開發文件也要求主機上有 lsof、openssl 和 curl，並需要 Node 提供的 npx 來佈建 Intelligence。請複製標記版本，而不要使用 main，因為 alpha 專案中的 main 可能在未預警的情況下變更。如果你已經執行 v0.1.x 安裝，切換前請先閱讀 v0.2.0 release notes：升級會將已儲存的 Composio connections 複製到新資料表，之後回復到 v0.1.2 會隱藏升級後連線的任何帳戶。

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

佈建 Intelligence 專案。前兩個指令會讓你登入並選取專案。接著，輔助腳本會佈建該專案的 runtime key，建立或重用其 openbot Learning container，並將這兩項設定寫入環境檔案。

npx --yes copilotkit@latest login
npx --yes copilotkit@latest project select
bun scripts/setup-learning.ts

產生用於加密已儲存憑證的 key，並將輸出寫入 .env 的 KEY_ENCRYPTION_KEY。在同一個檔案中加入你的 OPENAI_API_KEY。概念驗證 Bot 使用 OpenAI。對於 LangGraph Bot，你可以將 BOT_PROVIDER 設為 anthropic 或 google，並加入相符的 key。

openssl rand -base64 32

接著啟動服務。

bash scripts/start.sh

scripts/start.sh 會啟動 Docker services、執行資料庫 migrations、啟動 server、routine worker 和 app，並檢查其健康狀態。完成後，app 會在 port 3010 回應，API 會在 port 3001 回應。此腳本會回報 port conflicts，並讓已在執行且相符的 service 繼續運作，因此重複執行也安全。

在公開任何服務前，先從伺服器本機檢查。

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，表示 app 正在提供服務。第二個指令會顯示這些埠繫結到哪些位址；在 VPS 上，這才是需要確認的結果。顯示 127.0.0.1:3001 的列只對主機本身開放。顯示 0.0.0.0:3001 的列表示任何能將網路流量路由到該伺服器的使用者都能連線。

單一容器映像

部署文件也提供包含應用程式、API 與 Chromium 的單一映像，服務監聽 3001 埠。該映像以 ghcr.io/copilotkit/openbot 搭配版本標籤發布，也可以從你的 clone 建置。

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 openbot

EMBEDDED_POSTGRES=on 會在容器內執行 PostgreSQL，並在啟動時套用 migration。具名 volume 可在重新部署後保留稽核歷程；沒有它，每次重新建置都會捨棄該歷程。請將它掛載到上層目錄 /var/lib/postgresql，不要直接掛載到資料目錄。文件警告，掛載資料目錄可能導致 cluster 未初始化，接著應用程式會回應 502。若改用代管資料庫並將 DATABASE_URL 指向該資料庫，則必須在其中啟用 vector extension。RDS、Cloud SQL 與 Azure Database 等代管服務支援此 extension，但都不會代你啟用。migration 也要求執行 migration 的 role 擁有該 extension；若 extension 是由其他 role 建立，執行會因 must be owner of extension vector 而停止。

使用外部資料庫時，請將 migration 作為 release 步驟執行。

docker run --rm --env-file .env --entrypoint sh openbot \
  -c "cd /app/server && bun scripts/migrate.ts"

請使用 scripts/migrate.ts，不要使用 drizzle-kit migrate，因為 drizzle-kit CLI 是 development dependency，不會包含在 production image 中。請保留 --entrypoint sh，否則 API 會在 migration 執行前啟動。

該映像刻意不發布瀏覽器埠。此外也不包含 supervisor，因為 supervisor 需要 Docker socket，而 serverless 平台不提供該 socket。沒有 supervisor 時，所有 bot 會共用同一個瀏覽器，也就是同一組登入資訊，因此失去以每個 bot 使用獨立容器的隔離效果。若你需要讓每個 bot 使用不同的登入資訊，請在可接受此取捨的主機上，設定 COMPUTER_SUPERVISOR_URL 與 SUPERVISOR_TOKEN 後執行 compose stack。能與 Docker socket 通訊的程序可以啟動具備特權的容器，因此實際上等同於取得主機上的 root 權限。基於這項風險，最好讓 OpenBot 使用專用主機，原則上與 為 coding agents 提供可銷毀的 VM 相同。

為什麼 OPENBOT_SINGLE_USER 是筆記型電腦設定

.env.example 隨附 OPENBOT_SINGLE_USER=true。此設定會將每個請求視為同一名固定管理員，完全略過登入。在筆記型電腦上，這是便利功能，因為只有你能連線到該埠。在 VPS 上，任何能連線到 3010 埠的人都會成為該管理員，而系統中還儲存著加密的認證資料，並能操作已登入你帳戶的瀏覽器。

伺服器現在會阻擋部分這類情況。如果已設定 OPENBOT_SINGLE_USER=true，且公開路由了 OPENBOT_PUBLIC_URL、OPENBOT_APP_URL 或 TRUSTED_ORIGINS 項目，伺服器會拒絕啟動並指出該位址。私有位址則會觸發警告。這項檢查讀取的是設定中的 URL，不是 Docker 發布連接埠所使用的介面。因此，即使連接埠已對網際網路開放，預設的 localhost 值仍會通過檢查。繫結設定仍由你負責。

有兩種正確的執行方式。保留 OPENBOT_SINGLE_USER=true，將每個連接埠繫結至 127.0.0.1，並且只透過 SSH tunnel 或私有網路介面存取應用程式。

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

此時，應用程式位於你自己瀏覽器中的 http://localhost:3010。這會被視為安全內容，因此登入 cookie 及即時畫面所需的瀏覽器功能都能正常運作。另一種方式是關閉單一使用者模式，並設定正式的身分識別提供者。支援 Google、Microsoft Entra、Okta、SAML 和 OIDC。任何提供者也需要長度至少為 32 個字元的 BETTER_AUTH_SECRET、設為 OAuth callback 公開 API base URL 的 BETTER_AUTH_URL、INITIAL_ADMIN_EMAILS 及 TRUSTED_ORIGINS。提供者認證資料必須完整，因為設定不完整的提供者會停止啟動，而不會退回開放存取。如果你新增帳戶的原因，是團隊中的每個人都需要自己的 agent，而不是自己的瀏覽器，OneCLI 從一開始就是針對這種架構設計，每人使用一個隔離的 agent，模型金鑰則集中由單一 gateway 持有。

如果應用程式可透過公開名稱連線，請在前方部署 TLS（傳輸層安全性）。除了 localhost 之外，使用純 http:// 提供的頁面都不是安全內容，因此標記為 Secure 的 cookie 不會被儲存，登入也會失敗，造成看似 OpenBot 程式錯誤的結果。

封鎖較低層的連接埠

OpenBot 的安全性說明指出，較低層的服務端點受到 token 保護，應維持私有，不應用來繞過 gateway。Token 是第二層防護。第一層防護是讓連接埠完全無法連線。

agent-computer 監聽 4100，並要求 COMPUTER_TOKEN。bot 端點監聽 4200 和 4201，agent harness 監聽 4202。supervisor 在主機上監聽 4500，在其容器內監聽 4300，而 compose 檔案會將它繫結至 127.0.0.1:4500。PostgreSQL 監聽 5432。這些服務都不應繫結至公開介面；在單一使用者部署中，app 和 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，該連接埠依然保持開放。應直接在對映中將發布的連接埠繫結至 loopback，例如 -p 127.0.0.1:3001:3001，或在 compose 檔案中設定主機位址。請使用 ss -ltnp 驗證，不要使用 ufw status。這個陷阱並非 OpenBot 專有，因此也應對主機上其他已發布的每個容器執行相同檢查，包括任何提供 重建為 90 年代錄影帶店的 Jellyfin 媒體庫 的容器。

OpenBot 不是離線堆疊

請在規劃部署前先確認這點。OpenBot 依賴 CopilotKit Intelligence 專案，該專案會在您的伺服器之外保存持久化執行緒與對話記憶。伺服器啟動時會驗證 INTELLIGENCE_API_URL、INTELLIGENCE_GATEWAY_WS_URL 和 INTELLIGENCE_API_KEY。這 3 項會一起檢查，任一項缺少時，伺服器都會拒絕啟動。COPILOTKIT_LICENSE_TOKEN 為選用設定，只有使用自有授權的自架 Intelligence 時才會用到。自 2026 年 10 月起提供免費方案，但由於 v0.1.0，除非部署使用付費 Intelligence 方案，否則 OpenBot 會顯示自架提示。Intelligence 本身也可自架，因此可以實現完全在本機執行的部署，但需要的工作比快速入門文件所示的更多。本機 Intelligence 會將金鑰寫入 CPK_INTELLIGENCE_API_KEY，而 OpenBot 只會讀取 INTELLIGENCE_API_KEY，因此請將該值複製過去。

模型是第 2 個外部相依項目。系統不會在套件中附帶模型。BOT_PROVIDER 可為 LangGraph Bot 接受 openai、anthropic 或 google，而 OPENAI_BASE_URL 會將 OpenAI 路徑指向任何相容的端點。如果希望 token 留在自己的硬體上，可使用 在 VPS 上執行 Ollama 以自架 LLM。瀏覽器控制對模型的要求很高，因此在決定使用本機模型前，請先讓它執行實際工作進行測試。

擴展至 1 個以上的複本

Gateway 會根據頁面快照解析元素參照。現在，這些快照儲存在 PostgreSQL 中，因此第二個複本可以處理第一個複本建立的快照。官方 Helm chart 預設執行 2 個 API 複本，並將複本必須保留的所有資料存放在 PostgreSQL 中。

此外，官方 Helm chart 會停用內嵌瀏覽器，且在複本數超過 1 個時拒絕安裝內嵌瀏覽器。若 API pod 內執行瀏覽器，該瀏覽器會保存 1 個 bot 的登入狀態；擴展 API 後，這些登入狀態也會隨之增加。

需要特別留意單一映像檔的情況，因為每個複本都包含自己的瀏覽器。因此，bot 的登入狀態會保留在實際處理請求的複本上。在單一 VPS 上，每個 bot 的瀏覽器仍會執行於同一台主機，因此應透過升級主機規模來擴展。

bot 之間的隔離仍由各 bot 專用的容器提供，方式與 自架 agent 沙箱 相同，可避免某個 agent 的錯誤影響其他 agent。

失敗情況與可觀察到的現象

填入 .env 後，啟動程序立即結束。 伺服器會先驗證設定，之後才開始提供服務。以下任一情況都會停止啟動，不會靜默降級：不完整的 Intelligence 區塊、缺少 KEY_ENCRYPTION_KEY、OAuth 提供者只有 client ID 而沒有 secret，或在公開 URL 下同時啟用單一使用者模式。先讀取第一個錯誤，修正該欄位後再次啟動。

受管控的資料庫上移轉失敗。 可能有兩個原因。vector 擴充功能可能尚未啟用，且執行移轉的角色無法建立該擴充功能，因此移轉遇到 PostgreSQL 不認得的資料欄位型別。或者，該擴充功能是由其他角色建立，導致移轉因 must be owner of extension vector 而停止。請使用執行移轉的角色建立擴充功能，然後重新執行移轉步驟。

應用程式載入成功，但登入狀態不會保留。 你在公開位址上透過純 http:// 提供服務。這不是安全內容環境，因此瀏覽器會捨棄 Secure cookie。在前方設定 TLS，或使用 SSH tunnel，讓瀏覽器看到 localhost。

Bot 共用原本預期應彼此分開的登入狀態。 supervisor 未執行，因此沒有每個 Bot 專用的電腦，所有 Bot 都使用共用瀏覽器。確認已設定 COMPUTER_SUPERVISOR_URL，並確認 supervisor 能夠連線至 Docker socket。

Bot 停止並要求協助。 這代表設計正常運作。稽核軌跡會記錄 computer.help_requested，你可在即時畫面接管操作，交接也會在雙方留下記錄。

FAQ

將 OPENBOT_SINGLE_USER 留在 VPS 部署中是否安全？

只有在 gateway 無法從網際網路連線時才安全。OPENBOT_SINGLE_USER=true 會將每個請求都視為同一名固定 administrator，且不要求登入，因此任何能開啟該埠的人都能控制整個部署、其中儲存的憑證，以及已登入的瀏覽器。此模式會在設定的公開 URL 或 trusted origin 可公開路由時拒絕啟動，但該檢查無法判斷連接埠實際如何對外發布。若所有連接埠都綁定至 127.0.0.1，並透過 SSH tunnel 或私有網路介面存取應用程式，則可接受使用此模式。若服務位於公開介面，請關閉此模式，並搭配 Google、Microsoft Entra、Okta 或 OIDC 設定 BETTER_AUTH_SECRET、BETTER_AUTH_URL、INITIAL_ADMIN_EMAILS 與 TRUSTED_ORIGINS。

一個 OpenBot bot 需要多少 RAM？

專案針對單一 Bot 公布的數據顯示，在 arm64 上的峰值記憶體使用量為 0.55 GB；文件記載的最低需求為 2 GB，建議配置為 4 GB。專案未公布同時執行多個 bot 的數據，因為每個 bot 都會使用各自的 Chromium。請讓一個 bot 執行實際工作，在 docker stats 中查看該容器的記憶體使用量，再加上 gateway 與資料庫的需求，最後乘以預期同時存在的 bot 數量。

自行代管 OpenBot 是否需要 CopilotKit 帳戶？

需要。OpenBot 依賴 CopilotKit Intelligence project 來保存持久化 threads 與記憶體；除非已設定 Intelligence API URL、gateway WebSocket URL 和 API key，否則伺服器會拒絕啟動。截至 October 2026，CopilotKit 提供免費方案；Intelligence 也能自行代管，因此投入額外工作後可以移除代管服務相依性。你也必須提供自己的 model API key，因為 OpenBot 不會隨附任何模型。

為什麼每個 bot 都有自己的瀏覽器，而不是共用一個？

因為瀏覽器 profile 就是身分。共用瀏覽器代表共用 cookies 和 sessions，因此一個 bot 登入某個帳戶後，所有 bot 都會以該帳戶登入。每個 bot 使用獨立的 container，能讓每位 coworker 擁有自己的 profile 和登入資訊。代價是記憶體用量增加，因為每個 bot 的 Chromium 是 sizing 中最大的單一項目。

哪些 OpenBot 連接埠應在防火牆上開放？

底層連接埠都不應開放。4100 上的 agent-computer、4200 和 4201 上的 bot endpoints、4202 上的 agent harness、4500 上的 supervisor，以及 5432 上的 PostgreSQL 都應維持私有。專案以 tokens 保護這些服務，並要求你無論如何都不要讓它們可連線。只發布人員需要開啟的服務，並注意：使用 -p 3001:3001 發布的 container port，不論 ufw 的 default-deny 規則為何都可以連線，因為 Docker 的 DNAT 規則會將該流量放入 FORWARD 路徑，而不是 INPUT。