วิธีติดตั้ง OpenBot AI coworkers บน VPS ด้วยตัวเอง

สิ่งที่คุณจะได้รับเมื่อโฮสต์ OpenBot AI coworkers ด้วยตนเอง

คุณสามารถโฮสต์ OpenBot AI coworkers ด้วยตนเองได้โดยการรัน gateway server หนึ่งเครื่องควบคู่ไปกับ container หนึ่งตัวต่อบอทหนึ่งตัวบนฮาร์ดแวร์ที่คุณควบคุมเอง บอทแต่ละ container จะมาพร้อมกับ Chromium browser และ workspace volume ของตนเอง โดยมี browser profile ที่คงอยู่ระหว่างการใช้งานแต่ละเซสชัน ทุกการกระทำที่บอทดำเนินการบนคอมพิวเตอร์, ไฟล์, MCP (model context protocol) server หรือ UI component จะต้องผ่าน gateway ดังกล่าว ซึ่งจะทำหน้าที่ตรวจสอบการกระทำนั้นเทียบกับนโยบายก่อนที่จะดำเนินการจริงและบันทึกผลลัพธ์หลังจากนั้น หากคุณยังไม่คุ้นเคยกับ agent loop ที่ gateway นี้ครอบไว้ เส้นทางการเรียนรู้ใน การเรียนรู้ AI agents ตั้งแต่เริ่มต้น จะช่วยให้คุณลองเขียน agent ขนาดเล็กด้วยตนเองก่อนที่จะมอบ browser และข้อมูลการเข้าสู่ระบบให้กับบอท

OpenBot ถูกเผยแพร่โดย CopilotKit ภายใต้สัญญาอนุญาต MIT ที่ github.com/CopilotKit/openbot โดย release แรกที่มีการติดแท็กคือ v0.0.1 ซึ่งเผยแพร่เมื่อวันที่ 17 สิงหาคม 2026 และโครงการนี้ระบุสถานะว่าเป็น alpha ซึ่งอยู่ระหว่างการพัฒนาอย่างต่อเนื่อง โปรดถือว่านี่เป็นการออกแบบที่จริงจังแต่ยังคงมีข้อจำกัดในระยะเริ่มต้น

ส่วนที่น่าสนใจของสถาปัตยกรรมนี้คือส่วนที่สิ้นเปลืองทรัพยากรมากที่สุด การใช้ browser สำหรับ agent แต่ละตัวเป็นต้นทุนด้านหน่วยความจำที่คนส่วนใหญ่มักลืมวางแผน ดังนั้นการประเมินขนาดของระบบจึงต้องทำก่อนการติดตั้งในขั้นตอนต่อไป

วิธีการที่เกตเวย์ตัดสินใจในทุกการกระทำ

API server บนพอร์ต 3001 เป็นเส้นทางเดียวที่เข้าถึงคอมพิวเตอร์ของบอท ก่อนที่การกระทำของเบราว์เซอร์จะเริ่มทำงาน เกตเวย์จะระบุเป้าหมายจากภาพรวมของหน้าเว็บ ประเมินกฎนโยบาย CEL (common expression language) เทียบกับบริบท เขียนแถวบันทึกการตรวจสอบ (audit row) ที่ระบุการตัดสินใจ และหลังจากนั้นจึงเรียกใช้งานคอนเทนเนอร์ หากการดำเนินการล้มเหลวหลังจากขั้นตอนดังกล่าว ระบบจะเขียนแถวบันทึกที่สอง เอกสารระบุขอบเขตไว้อย่างชัดเจนว่า: คอมพิวเตอร์ไม่ได้เป็นผู้ตัดสินใจนโยบาย แต่เกตเวย์ของเซิร์ฟเวอร์คือขอบเขตของการกระทำ การแบ่งส่วนนี้มีชื่อเรียกภายนอก OpenBot เนื่องจากลูป, นิยามของเครื่องมือ, การตรวจสอบสิทธิ์ และสถานะของเซสชันจะรวมอยู่ด้วยกันใน ส่วนควบคุมที่ห่อหุ้มโมเดลไว้ และเกตเวย์นี้คือส่วนที่ทำหน้าที่จัดการสิทธิ์

นโยบายเริ่มต้นคือการปฏิเสธ (deny-by-default) และกฎการปฏิเสธจะถูกประเมินก่อนกฎการอนุญาต ทิศทางของความล้มเหลวมีความสำคัญมากกว่าไวยากรณ์ของกฎ นโยบายที่ขาดหายไปจะไม่อนุญาตให้ทำสิ่งใด และกฎที่ผิดพลาดจะส่งผลให้เกิดการบล็อกไม่ว่าจะเป็นกฎการปฏิเสธหรือกฎการอนุญาต ดังนั้นความผิดพลาดในนโยบายของคุณจะส่งผลให้บอทติดขัดแทนที่จะเป็นบอทที่หลุดออกไปควบคุมบัญชีของคุณ เลเยอร์นี้ควบคุมสิ่งที่บอททำไม่ใช่สิ่งที่บอทอ่าน ดังนั้นหน้าเว็บที่มีคำสั่งมุ่งเป้าไปที่เอเจนต์จึงยังคงเป็นปัญหาแยกต่างหาก ซึ่งเป็นพื้นผิวการโจมตีแบบ prompt injection เดียวกันกับที่คุณต้องเผชิญเมื่อคุณ ส่งผลลัพธ์จากอินสแตนซ์ SearXNG ของคุณเองให้กับเอเจนต์

บันทึกการตรวจสอบ (audit trail) จะถูกจัดเก็บไว้ใน PostgreSQL ดังนั้นข้อมูลจึงยังคงอยู่หลังจากการรีสตาร์ท การส่งมอบการควบคุมจะถูกบันทึกเป็น computer.help_requested, computer.control_taken และ computer.control_released ซึ่งเป็นวิธีที่คุณจะเห็นบอทร้องขอความช่วยเหลือจากมนุษย์และวิธีที่คุณเห็นมนุษย์ส่งมอบการควบคุมกลับคืน ข้อมูลลับจะถูกบันทึกเป็นจำนวนตัวอักษร ไม่ใช่ค่าของข้อมูล การดำเนินการเกี่ยวกับไฟล์จะบันทึกเฉพาะพาธและขนาด ไม่ใช่เนื้อหาภายใน หากคุณต้องการขอบเขตการควบคุมเดียวกันโดยไม่มีเบราว์เซอร์อยู่เบื้องหลัง การจำกัดการกระทำของ AI agent ด้วยการอนุมัติ จะครอบคลุมกรณีที่เฉพาะเจาะจงกว่านั้น

ต้นทุน RAM และ Disk ของ Bot หนึ่งตัว

โครงการได้เผยแพร่ตัวเลขการวัดผลสำหรับ Bot หนึ่งตัวบนสถาปัตยกรรม arm64 นี่เป็นตัวเลขการประเมินขนาดเพียงชุดเดียวที่ OpenBot จัดเตรียมไว้ให้ ซึ่งอธิบายถึง Bot หนึ่งตัวบนสถาปัตยกรรมเดียว ดังนั้นให้ถือว่าเป็นจุดเริ่มต้นมากกว่าจะเป็นแผนการรองรับโหลดจริง

[
  {
    "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 ต่อหนึ่ง Bot ในขณะที่ขั้นต่ำที่ระบุไว้คือ 2 GB และคำแนะนำคือ 4 GB ช่องว่างระหว่างค่าที่วัดได้กับค่าขั้นต่ำคือพื้นที่สำหรับ Chromium ในการขยายตัวเมื่อมีโหลด เนื่องจากหน่วยความจำที่เบราว์เซอร์ใช้จะแปรผันตามจำนวนหน้าเว็บที่เปิด ไม่ใช่สถานะของ process ขณะหยุดนิ่ง การใช้งาน CPU ขณะ idle แทบจะเป็นศูนย์ โดยอยู่ที่ 0.06 ของหนึ่งคอร์ในช่วงสูงสุดที่วัดได้ ดังนั้นสิ่งที่คุณต้องคำนึงถึงไม่ใช่ CPU แต่เป็น Disk ตัว image เพียงอย่างเดียวมีขนาด 5.3 GB เทียบกับขนาด volume ที่แนะนำคือ 10 GB ซึ่งมีขนาดใหญ่เพราะมีการรวม binary ของ Firefox และ WebKit ของ Playwright มาให้พร้อมกับ Chromium

ข้อมูลเหล่านี้ไม่ได้บอกต้นทุนเมื่อรัน Bot หลายตัวพร้อมกัน และโครงการก็ไม่ได้เผยแพร่ตัวเลขในส่วนนี้ ค่าขั้นต่ำที่ระบุไว้เป็นตัวเลขที่โครงการมั่นใจที่จะเผยแพร่มากกว่าจะเป็นค่าที่ผ่านการเฝ้าสังเกตภายใต้โหลดจริง ซึ่งเป็นเหตุผลว่าทำไม การเลือกระหว่าง PhotoPrism และ Immich จึงขึ้นอยู่กับค่า RAM ขั้นต่ำที่วัดได้จริงมากกว่าค่าที่ประกาศไว้ คุณควรวัดผลด้วยตนเอง เริ่มรัน Bot หนึ่งตัว มอบหมายงานจริงที่ต้องเปิดหน้าเว็บ และเฝ้าสังเกต container ขณะทำงาน

docker stats --no-stream
free -m

ให้ใช้ค่าในคอลัมน์ MEM USAGE สำหรับ container ของ Bot เป็นตัวเลขต่อหนึ่งหน่วย จากนั้นบวกด้วย gateway และ PostgreSQL แล้วจึงคูณตัวเลขต่อหนึ่งหน่วยด้วยจำนวน Bot ที่คุณคาดว่าจะรันพร้อมกัน Bot ที่ idle ก็ยังคงถือครอง process ของเบราว์เซอร์อยู่ ดังนั้นตัวคูณจึงใช้กับ Bot ทุกตัวที่มีอยู่ ไม่ใช่แค่ Bot ที่กำลังทำงานอยู่ การคำนวณนี้เป็นวิธีเดียวกับที่ใช้ใน การประเมิน RAM และ CPU สำหรับ VPS ของ coding agent และส่วนที่เกี่ยวกับเบราว์เซอร์ได้ครอบคลุมไว้ใน การรัน headless browser สำหรับ agent บน VPS

รายละเอียดของ Chromium หนึ่งอย่างมีผลต่อแผนการใช้งานขนาดเล็ก OpenBot เปิดใช้งาน Chromium ด้วย --disable-dev-shm-usage ดังนั้นเบราว์เซอร์จะเขียนข้อมูลลงใน /tmp แทนที่จะเป็น /dev/shm วิธีนี้ช่วยหลีกเลี่ยงปัญหา crash ที่มักเกิดขึ้นบนโฮสต์ที่มี /dev/shm ขนาดเล็ก และเป็นการย้ายภาระไปไว้ที่ root filesystem ของคุณ ซึ่งเป็นอีกเหตุผลหนึ่งที่ขนาด disk ที่แนะนำจึงใหญ่กว่าขนาดของ image

วิธีการ self-host OpenBot บน VPS

คุณจำเป็นต้องมี Docker, Bun 1.3 หรือใหม่กว่า, โปรเจกต์ CopilotKit Intelligence และ API key ของโมเดล เอกสารสำหรับการพัฒนาต้องการให้มี lsof, python3 และ curl อยู่บนเครื่องด้วย ให้ทำการ clone เวอร์ชันที่ระบุ tag ไว้แทนการใช้ main เพราะ main ในโปรเจกต์ระดับ alpha มักมีการเปลี่ยนแปลงโดยไม่มีการแจ้งเตือน

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

เตรียมโปรเจกต์ Intelligence คำสั่ง 3 คำสั่งนี้จะเขียน runtime key และ license token ลงในไฟล์ environment ของคุณ

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

สร้าง key สำหรับเข้ารหัสข้อมูลประจำตัวที่จัดเก็บไว้ แล้วนำผลลัพธ์ไปใส่ใน .env ในชื่อ KEY_ENCRYPTION_KEY เพิ่ม OPENAI_API_KEY ของคุณลงในไฟล์เดียวกัน หรือตั้งค่า BOT_PROVIDER ให้เป็น anthropic หรือ google พร้อมกับ key ที่ตรงกัน

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 จากคำสั่งแรกหมายความว่าแอปพลิเคชันกำลังให้บริการอยู่ คำสั่งที่สองจะแสดงว่าพอร์ตเหล่านั้นผูกอยู่กับ address ใด ซึ่งเป็นคำตอบที่สำคัญบน 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 เมื่อเริ่มต้นระบบ การใช้ named volume จะช่วยเก็บประวัติการตรวจสอบ (audit history) ไว้ได้แม้จะมีการ redeploy หากไม่มี volume นี้ การ rebuild ทุกครั้งจะทำให้ประวัติเหล่านั้นสูญหาย หากคุณชี้ DATABASE_URL ไปยังฐานข้อมูลแบบ managed แทน คุณจะต้องเปิดใช้งานส่วนขยาย vector บนฐานข้อมูลนั้นด้วย บริการแบบ managed เช่น 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"

อิมเมจดังกล่าวตั้งใจที่จะไม่เปิดพอร์ตของเบราว์เซอร์ไว้ และยังตัดส่วนของ supervisor ออกไป เนื่องจาก supervisor จำเป็นต้องเข้าถึง Docker socket ซึ่งแพลตฟอร์มแบบ serverless ไม่ได้เตรียมไว้ให้ หากไม่มี supervisor บอททุกตัวจะใช้เบราว์เซอร์ร่วมกันและใช้ชุดข้อมูลการเข้าสู่ระบบเดียวกัน ซึ่งจะทำลายการแยกส่วน (isolation) ที่ทำให้การรันคอนเทนเนอร์แยกต่อบอทมีความคุ้มค่า หากเหตุผลที่คุณมาที่นี่คือต้องการแยกการเข้าสู่ระบบสำหรับบอทแต่ละตัว ให้รัน compose stack โดยตั้งค่า COMPUTER_SUPERVISOR_URL และ SUPERVISOR_TOKEN บนโฮสต์ที่คุณยอมรับความเสี่ยงได้ กระบวนการที่สามารถสื่อสารกับ Docker socket ได้นั้นสามารถเริ่มคอนเทนเนอร์ที่มีสิทธิ์สูงได้ ซึ่งในทางปฏิบัติถือเป็นสิทธิ์ root บนโฮสต์ นี่เป็นเหตุผลที่ดีในการรัน OpenBot บนเครื่องของตัวเอง เช่นเดียวกับแนวคิดเรื่อง การให้ coding agent ใช้ VM แบบชั่วคราว

เหตุผลที่ OPENBOT_SINGLE_USER เป็นการตั้งค่าสำหรับแล็ปท็อป

.env.example มาพร้อมกับ OPENBOT_SINGLE_USER=true การตั้งค่านี้จะยอมรับทุกคำขอในฐานะผู้ดูแลระบบเพียงคนเดียวและข้ามขั้นตอนการลงชื่อเข้าใช้ไปโดยสิ้นเชิง บนแล็ปท็อปถือเป็นความสะดวกสบาย เพราะไคลเอนต์เดียวที่เข้าถึงพอร์ตนี้ได้คือตัวคุณเอง แต่บน VPS หมายความว่าคนแรกที่เข้าถึงพอร์ต 3010 จะกลายเป็นผู้ดูแลระบบของระบบที่จัดเก็บข้อมูลรับรองที่เข้ารหัสไว้ และควบคุมเบราว์เซอร์ที่ลงชื่อเข้าใช้บัญชีของคุณไว้แล้ว

มีวิธีที่ถูกต้องในการใช้งานอยู่สองวิธี วิธีแรกคือคงค่า 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 ในเบราว์เซอร์ของคุณเอง ซึ่งถือเป็นบริบทที่ปลอดภัย ดังนั้นคุกกี้สำหรับการลงชื่อเข้าใช้และฟีเจอร์ของเบราว์เซอร์ที่หน้าจอสดจำเป็นต้องใช้จึงทำงานได้ตามปกติ อีกวิธีหนึ่งคือการปิดโหมดผู้ใช้คนเดียวและกำหนดค่าผู้ให้บริการยืนยันตัวตนจริง โดยรองรับ Google, Microsoft Entra, Okta, SAML และ OIDC ผู้ให้บริการทุกรายยังจำเป็นต้องมี BETTER_AUTH_SECRET ที่มีความยาว 32 อักขระขึ้นไป, BETTER_AUTH_URL ที่ตั้งค่าเป็น URL ฐานของ API สาธารณะสำหรับ OAuth callbacks, INITIAL_ADMIN_EMAILS และ TRUSTED_ORIGINS ข้อมูลรับรองของผู้ให้บริการต้องครบถ้วน เพราะหากกำหนดค่าผู้ให้บริการไม่สมบูรณ์ ระบบจะหยุดการทำงานแทนที่จะเปลี่ยนกลับไปเป็นการเข้าถึงแบบเปิด หากเหตุผลที่คุณเพิ่มบัญชีเป็นเพราะสมาชิกแต่ละคนในทีมต้องการเอเจนต์ของตนเองแทนที่จะเป็นเบราว์เซอร์ของตนเอง OneCLI ถูกสร้างขึ้นโดยยึดรูปแบบนั้นตั้งแต่ต้น โดยมีเอเจนต์แบบ sandboxed หนึ่งตัวต่อหนึ่งคน และเก็บคีย์ของโมเดลไว้ในเกตเวย์เดียว

หากแอปสามารถเข้าถึงได้ผ่านชื่อสาธารณะ ให้ติดตั้ง TLS (transport layer security) ไว้ด้านหน้า หน้าเว็บที่ให้บริการผ่าน http:// ธรรมดาบนโฮสต์อื่นที่ไม่ใช่ localhost จะไม่ถือเป็นบริบทที่ปลอดภัย ดังนั้นคุกกี้ที่ทำเครื่องหมาย Secure จะไม่ถูกจัดเก็บ และการลงชื่อเข้าใช้จะล้มเหลวในลักษณะที่ดูเหมือนเป็นบั๊กใน OpenBot

การจำกัดการเข้าถึงพอร์ตระดับต่ำด้วยไฟร์วอลล์

บันทึกความปลอดภัยของ OpenBot ระบุว่า endpoint ของบริการระดับต่ำได้รับการป้องกันด้วยโทเค็น คุณควรเก็บข้อมูลเหล่านี้ไว้เป็นความลับและไม่ควรใช้เพื่อข้ามผ่านเกตเวย์ โทเค็นเป็นเพียงการป้องกันชั้นที่สอง ส่วนการป้องกันชั้นแรกคือการทำให้พอร์ตไม่สามารถเข้าถึงได้เลยจากภายนอก

คอมพิวเตอร์ตัวแทน (agent-computer) ฟังการเชื่อมต่อที่พอร์ต 4100 และต้องการ COMPUTER_TOKEN ส่วน endpoint ของบอทฟังที่พอร์ต 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 ที่กฎการปฏิเสธการเชื่อมต่อเริ่มต้นของ ufw ควบคุมอยู่ พอร์ตจะยังคงเปิดอยู่แม้ว่า ufw status จะยังคงแสดงผลเป็น Status: active ก็ตาม คุณควรผูกพอร์ตที่เผยแพร่ไว้กับ loopback ในการแมปพอร์ตโดยตรง เช่น -p 127.0.0.1:3001:3001 หรือกำหนดที่อยู่โฮสต์ในไฟล์ compose ของคุณ ให้ตรวจสอบผลลัพธ์ด้วย ss -ltnp แทนการใช้ ufw status กับดักนี้ไม่ได้จำกัดอยู่แค่ OpenBot ดังนั้นคุณควรตรวจสอบคอนเทนเนอร์อื่นทั้งหมดที่คุณเผยแพร่ไว้บนเครื่อง รวมถึงบริการที่ทำหน้าที่ คลังสื่อ Jellyfin ที่ถูกปรับแต่งให้เหมือนร้านวิดีโอในยุค 90 ด้วยเช่นกัน

OpenBot ไม่ใช่ stack แบบออฟไลน์

โปรดระบุเงื่อนไขนี้ก่อนที่คุณจะวางแผนการติดตั้งใช้งาน OpenBot จำเป็นต้องพึ่งพาโปรเจกต์ CopilotKit Intelligence ซึ่งทำหน้าที่เก็บรักษาเธรดและประวัติการสนทนาไว้นอกเซิร์ฟเวอร์ของคุณ เซิร์ฟเวอร์จะตรวจสอบ INTELLIGENCE_API_URL, INTELLIGENCE_GATEWAY_WS_URL, INTELLIGENCE_API_KEY และ COPILOTKIT_LICENSE_TOKEN ในระหว่างการเริ่มระบบ และทั้งสี่ค่านี้จะต้องมีอยู่ครบถ้วน มิฉะนั้นการเริ่มระบบจะล้มเหลว ปัจจุบันมีแผนบริการฟรีให้ใช้งาน ณ เดือนสิงหาคม 2026 และตัว Intelligence เองก็สามารถ self-host ได้ ดังนั้นการติดตั้งแบบ local ทั้งหมดจึงเป็นไปได้ แต่ต้องใช้ความพยายามมากกว่าที่ระบุไว้ในคู่มือเริ่มต้นใช้งานฉบับย่อ

โมเดลเป็น dependency ภายนอกรายการที่สอง โดยไม่มีสิ่งใดถูกติดตั้งมาพร้อมกับตัวซอฟต์แวร์ BOT_PROVIDER รองรับ openai, anthropic หรือ google และ OPENAI_BASE_URL จะชี้เส้นทางของ OpenAI ไปยัง endpoint ใดก็ตามที่รองรับ ซึ่งเป็นจุดที่ การรัน Ollama บน VPS เพื่อ self-host LLM เข้ามามีบทบาทหากคุณต้องการให้ token ประมวลผลอยู่บนฮาร์ดแวร์ของคุณเอง การควบคุมเบราว์เซอร์ต้องใช้ทรัพยากรจากโมเดลค่อนข้างสูง ดังนั้นควรทดสอบโมเดลแบบ local กับงานจริงก่อนตัดสินใจใช้งานจริง

เรียกใช้งานเพียง 1 replica ในขณะนี้

Gateway จะแคชภาพรวมของหน้าเว็บไว้ในหน่วยความจำของกระบวนการทำงานบนเซิร์ฟเวอร์ หากมี 2 replicas ภาพรวมที่ถูกบันทึกโดยกระบวนการหนึ่งจะไม่ปรากฏให้อีกกระบวนการหนึ่งเห็น ส่งผลให้การทำงานล้มเหลวเป็นระยะด้วยข้อผิดพลาด element-not-found ซึ่งดูเหมือนเกิดขึ้นแบบสุ่ม เอกสารการติดตั้งระบุไว้อย่างชัดเจนว่าให้เรียกใช้งานเพียง 1 replica และจำกัดจำนวน instance สูงสุดของแพลตฟอร์มไว้ที่ 1 ข้อจำกัดนี้จะสิ้นสุดลงเมื่อการแคชภาพรวมถูกย้ายไปไว้ในฐานข้อมูล จนกว่าจะถึงเวลานั้น ให้ขยายขนาด OpenBot โดยการเพิ่มทรัพยากรของเครื่องแทนการเพิ่มจำนวนเครื่อง การแยกส่วนระหว่างบอทแต่ละตัวยังคงทำผ่าน container ของบอทแต่ละตัว เช่นเดียวกับที่ self-hosted agent sandboxes ป้องกันไม่ให้ข้อผิดพลาดของ agent ตัวหนึ่งส่งผลกระทบต่อตัวอื่น

รูปแบบความล้มเหลวและสิ่งที่คุณจะพบ

แอปพลิเคชันหยุดทำงานทันทีหลังจากที่คุณกรอก .env เซิร์ฟเวอร์จะตรวจสอบความถูกต้องของค่าคอนฟิกูเรชันก่อนเริ่มให้บริการ หากบล็อก Intelligence ไม่สมบูรณ์, ขาด KEY_ENCRYPTION_KEY หรือผู้ให้บริการ OAuth มี client ID แต่ไม่มี secret จะทำให้การเริ่มต้นระบบหยุดลงแทนที่จะทำงานต่อแบบลดประสิทธิภาพ ให้ตรวจสอบข้อผิดพลาดแรกที่ปรากฏ แก้ไขฟิลด์นั้น แล้วเริ่มการทำงานใหม่อีกครั้ง

การทำ Migration ล้มเหลวบนฐานข้อมูลที่มีการจัดการ ส่วนขยาย vector ไม่ได้ถูกเปิดใช้งานโดยค่าเริ่มต้น ทำให้การ migration พยายามใช้ชนิดข้อมูลคอลัมน์ที่ PostgreSQL ไม่รู้จัก ให้เชื่อมต่อในฐานะ superuser รันคำสั่ง CREATE EXTENSION vector; แล้วจึงรันขั้นตอนการ migration ใหม่อีกครั้ง

แอปพลิเคชันโหลดได้แต่การลงชื่อเข้าใช้ไม่คงอยู่ คุณกำลังให้บริการผ่าน http:// แบบปกติบนที่อยู่สาธารณะ ซึ่งไม่ใช่บริบทที่ปลอดภัย ทำให้คุกกี้ Secure ถูกปฏิเสธ ให้ติดตั้ง TLS ไว้ด้านหน้า หรือใช้ SSH tunnel เพื่อให้เบราว์เซอร์มองเห็นเป็น localhost

บอทใช้การลงชื่อเข้าใช้ร่วมกันในส่วนที่คุณคาดว่าจะแยกจากกัน supervisor ไม่ได้ทำงานอยู่ จึงไม่มีคอมพิวเตอร์แยกสำหรับบอทแต่ละตัว และบอททุกตัวจึงใช้เบราว์เซอร์ร่วมกัน ให้ยืนยันว่ามีการตั้งค่า COMPUTER_SUPERVISOR_URL ไว้แล้ว และ supervisor สามารถเข้าถึง Docker socket ได้

บอทหยุดทำงานและขอความช่วยเหลือ นี่คือการทำงานตามการออกแบบ ระบบตรวจสอบจะบันทึก computer.help_requested ไว้ คุณสามารถเข้าควบคุมผ่านหน้าจอสด และการส่งมอบงานจะถูกบันทึกไว้ทั้งสองฝั่ง

FAQ

การเปิดใช้งาน OPENBOT_SINGLE_USER บน VPS ปลอดภัยหรือไม่?

ปลอดภัยเฉพาะในกรณีที่ gateway ไม่สามารถเข้าถึงได้จากอินเทอร์เน็ตเท่านั้น OPENBOT_SINGLE_USER=true จะยอมรับทุกคำขอในฐานะผู้ดูแลระบบโดยไม่ต้องลงชื่อเข้าใช้ ดังนั้นใครก็ตามที่สามารถเปิดพอร์ตนี้ได้จะถือสิทธิ์ควบคุมการติดตั้ง ข้อมูลประจำตัวที่จัดเก็บไว้ และเบราว์เซอร์ที่ลงชื่อเข้าใช้ไว้ทั้งหมด การใช้งานนี้จะยอมรับได้ก็ต่อเมื่อทุกพอร์ตถูกผูกไว้กับ 127.0.0.1 และคุณเข้าถึงแอปผ่าน SSH tunnel หรืออินเทอร์เฟซเครือข่ายส่วนตัวเท่านั้น หากใช้งานบนอินเทอร์เฟซสาธารณะ ให้ปิดการตั้งค่านี้และกำหนดค่า Google, Microsoft Entra, Okta หรือ OIDC ร่วมกับ BETTER_AUTH_SECRET, BETTER_AUTH_URL, INITIAL_ADMIN_EMAILS และ TRUSTED_ORIGINS

OpenBot หนึ่งตัวใช้ RAM เท่าไร?

ตัวเลขที่โครงการเผยแพร่สำหรับ Bot หนึ่งตัวบน arm64 ระบุว่ามีการใช้หน่วยความจำสูงสุดที่ 0.55 GB โดยมี 2 GB เป็นค่าขั้นต่ำตามเอกสาร และแนะนำที่ 4 GB ทั้งนี้ไม่มีตัวเลขเผยแพร่สำหรับการรัน Bot หลายตัวพร้อมกัน เนื่องจากแต่ละตัวจะใช้ Chromium แยกกัน ให้ลองรัน Bot หนึ่งตัวในงานจริง อ่านค่าหน่วยความจำของคอนเทนเนอร์นั้นใน docker stats รวมค่าของ gateway และฐานข้อมูลเข้าด้วยกัน จากนั้นคูณด้วยจำนวน Bot ที่คุณคาดว่าจะรันพร้อมกัน

ฉันจำเป็นต้องมีบัญชี CopilotKit เพื่อ self-host OpenBot หรือไม่?

จำเป็น OpenBot ต้องพึ่งพาโครงการ CopilotKit Intelligence สำหรับการจัดการ thread และหน่วยความจำที่คงทน และเซิร์ฟเวอร์จะไม่เริ่มทำงานหากไม่ได้ตั้งค่า Intelligence API URL, gateway WebSocket URL, API key และ license token ทั้งหมด โดยมีแผนบริการฟรี ณ เดือนสิงหาคม 2026 และ Intelligence สามารถ self-host ได้ ดังนั้นการพึ่งพาบริการโฮสต์จึงสามารถตัดออกได้หากดำเนินการเพิ่มเติม นอกจากนี้คุณต้องจัดเตรียม API key ของโมเดลด้วยตนเอง เนื่องจากไม่มีโมเดลใดมาพร้อมกับ OpenBot

ทำไม Bot แต่ละตัวถึงต้องใช้เบราว์เซอร์แยกกัน แทนที่จะใช้ร่วมกัน?

เนื่องจากโปรไฟล์เบราว์เซอร์คือตัวตน การใช้เบราว์เซอร์ร่วมกันหมายถึงการใช้คุกกี้และเซสชันร่วมกัน ดังนั้นหาก Bot ตัวหนึ่งลงชื่อเข้าใช้บัญชีใดไว้ Bot ทุกตัวก็จะลงชื่อเข้าใช้บัญชีนั้นด้วย การใช้คอนเทนเนอร์แยกต่อ Bot จะทำให้เพื่อนร่วมงานแต่ละตัวมีโปรไฟล์และข้อมูลการลงชื่อเข้าใช้เป็นของตนเอง ต้นทุนที่ต้องแลกคือหน่วยความจำ เนื่องจาก Chromium ต่อ Bot เป็นรายการที่ใช้ทรัพยากรมากที่สุดในการคำนวณขนาดระบบ

พอร์ตใดของ OpenBot ที่ควรเปิดบนไฟร์วอลล์?

ไม่ควรเปิดพอร์ตระดับล่างใดๆ เลย ทั้ง agent-computer บน 4100, bot endpoints บน 4200 และ 4201, supervisor บน 4500 และ PostgreSQL บน 5432 ควรเป็นส่วนตัวทั้งหมด โครงการมีการป้องกันด้วย token และขอให้คุณเก็บพอร์ตเหล่านี้ไว้ในสถานะที่ไม่สามารถเข้าถึงได้จากภายนอก ให้เปิดเผยเฉพาะสิ่งที่จำเป็นต้องใช้งานจริง และโปรดจำไว้ว่าพอร์ตคอนเทนเนอร์ที่เปิดด้วย -p 3001:3001 จะสามารถเข้าถึงได้เสมอโดยไม่สนใจกฎ default-deny ของ ufw เนื่องจากกฎ DNAT ของ Docker จะนำ traffic นั้นเข้าสู่เส้นทาง FORWARD แทนที่จะเป็น INPUT