โดย Matt Connor 2026-08-07 · อัปเดตเมื่อ 2026-08-28

วิธีติดตั้ง Octop บน VPS ด้วย Docker Compose

เรียนรู้วิธีติดตั้ง Octop เพื่อใช้งาน AI แบบหลายผู้ใช้บน VPS ของคุณเอง แนะนำให้ใช้ Docker Compose ระบุเวอร์ชันแทนการใช้สคริปต์ curl เพื่อความปลอดภัย พร้อมตั้งค่า TLS และระบบแยกบัญชี

Octop คืออะไร และเหตุใดคุณจึงควรโฮสต์ใช้งานเอง

Octop คือผู้ช่วย AI สำหรับใช้งานในครัวเรือนหรือทีมขนาดเล็กที่คุณสามารถโฮสต์ได้ด้วยตนเอง เหตุผลที่ควรเลือกโฮสต์ Octop แทนการใช้เพียงหน้าจอแชททั่วไปคือ Octop สามารถแยกผู้ใช้งานออกจากกันได้ ในขณะที่ Open WebUI ให้เพียงอินเทอร์เฟซเบราว์เซอร์สำหรับใช้งานโมเดล แต่ Octop เพิ่มระบบบัญชีผู้ใช้ที่มีบทบาทผู้ดูแลระบบ พื้นที่ทำงานส่วนตัว และชุดข้อมูลประจำตัวสำหรับผู้ใช้แต่ละคน รวมถึงคลังของเอเจนต์เฉพาะทางที่ผู้ใช้สามารถสลับใช้งานได้ตามงานที่ทำ นี่คือความแตกต่างที่ช่วยให้ VPS หนึ่งเครื่องสามารถรองรับผู้ใช้งานได้ถึง 5 คนแทนที่จะเป็นเพียงคนเดียว

โปรเจกต์นี้อยู่ที่ github.com/TencentCloud/Octop โดยเป็นกระบวนการเดียวที่ทำหน้าที่ให้บริการเว็บแดชบอร์ด, อินเทอร์เฟซบรรทัดคำสั่ง, ช่องทางแชท (Feishu, DingTalk, QQ, Discord, WeCom) และงานที่ตั้งเวลาไว้ ทั้งหมดนี้ทำงานบนฐานข้อมูล SQLite เพียงชุดเดียวภายใต้ ~/.octop/ เนื้อหาทั้งหมดด้านล่างนี้เขียนขึ้นโดยอ้างอิงจาก tag v0.9.19 ซึ่งเผยแพร่เมื่อวันที่ 5 สิงหาคม 2026 หากคุณยังตัดสินใจเลือกแพลตฟอร์มไม่ได้ การเปรียบเทียบทางเลือกของ Open WebUI ที่คุณสามารถรันบน VPS ได้ จะช่วยให้คุณเห็นภาพรวมที่กว้างขึ้น

สิ่งหนึ่งที่ควรทำความเข้าใจให้ชัดเจนก่อนที่คุณจะใช้เวลาดำเนินการคือ Octop เป็นซอฟต์แวร์เวอร์ชันก่อน 1.0 ที่เผยแพร่จากองค์กร GitHub ของผู้ผลิต โดยมีดาวอยู่ที่ประมาณ 900 ดวง ณ เดือนสิงหาคม 2026 ซอฟต์แวร์มีการเปลี่ยนแปลงอย่างรวดเร็วตามที่ระบุไว้ในหมายเลขเวอร์ชัน และไม่มีสิ่งใดในที่นี้ที่เป็นการรับประกันถึงเส้นทางการอัปเกรดที่เสถียร โปรดล็อกเวอร์ชันด้วย tag อ่านบันทึกการเปลี่ยนแปลง และสำรองข้อมูลไว้อย่างสม่ำเสมอ

สิ่งที่ต้องเตรียมก่อนเริ่มต้น

VPS ที่รัน Ubuntu 24.04 พร้อมติดตั้ง Docker Engine และปลั๊กอิน Compose หากคุณยังไม่คุ้นเคยกับ Compose ให้เริ่มต้นที่ พื้นฐาน Docker Compose สำหรับ VPS
git เนื่องจากคุณจะต้องดึงข้อมูลจาก release tag แทนการดึง image โดยตรง
ชื่อโดเมนที่ชี้มายัง VPS เนื่องจากคุณต้องการใช้ TLS (transport layer security) ครอบหน้าบริการนี้
โมเดล backend ที่รองรับ OpenAI API เช่น Ollama ที่รันในเครื่อง, self-hosted gateway หรือคีย์แบบชำระเงิน

ตัว Octop เองมีขนาดเบา โดยเป็นกระบวนการ Python และไฟล์ SQLite ส่วนภาระงานหลักจะอยู่ที่โมเดล backend ดังนั้นหากคุณวางแผนจะรันโมเดลบนเครื่องเดียวกัน ให้เลือกขนาดเครื่องที่เหมาะสมกับความต้องการของโมเดลนั้นๆ

เหตุผลที่เราไม่แนะนำให้ติดตั้งผ่าน curl

README เริ่มต้นด้วยคำสั่งติดตั้งบรรทัดเดียว:

curl -fsSL https://finnie-1258344699.cos.ap-guangzhou.myqcloud.com/octop/install.sh | bash

เราไม่แนะนำให้ใช้วิธีนี้บนเซิร์ฟเวอร์ที่คุณให้ความสำคัญ ด้วยเหตุผลที่ชัดเจนประการหนึ่งคือ สคริปต์ดังกล่าวไม่ได้อยู่ใน repository โดยถูกให้บริการผ่าน Tencent Cloud Object Storage bucket ซึ่งไม่มีสิ่งใดที่ถูกครอบคลุมโดย git tag หรือ commit ทำให้คุณไม่สามารถเปรียบเทียบความแตกต่าง (diff) ของสคริปต์วันนี้กับสัปดาห์ที่แล้วได้ และไม่มีประวัติที่อธิบายการเปลี่ยนแปลงใดๆ bucket ดังกล่าวสามารถส่งไฟล์ที่แตกต่างออกไปในวันพรุ่งนี้โดยที่ไม่มีส่วนใดในโปรเจกต์บันทึกไว้ การส่งผลลัพธ์เข้าสู่ bash โดยตรงยังหมายความว่าเครื่องจะรันสคริปต์ก่อนที่คุณจะได้อ่านแม้แต่บรรทัดเดียว

ตัวติดตั้งยังเขียนไฟล์ลงบนโฮสต์โดยตรงแทนที่จะเป็น container โดยใช้ uv เพื่อดึง Python 3.12 และสร้างสภาพแวดล้อมที่ package manager ของคุณไม่รู้จัก ทำให้การลบออกในภายหลังต้องทำด้วยตนเอง

มีทางเลือกที่ดีกว่าสองทาง คือการดึงสคริปต์มา อ่านก่อน แล้วค่อยรัน ซึ่งใช้เวลาเพียงสามสิบวินาที: curl -fsSL <url> -o install.sh ตามด้วย less install.sh และ bash install.sh หรือใช้ Docker ซึ่งเป็นเนื้อหาในส่วนที่เหลือของคู่มือนี้ แพ็กเกจบน PyPI (pip install octop) อย่างน้อยก็เป็น artifact ที่มีการระบุเวอร์ชัน ซึ่งคุณสามารถล็อกไว้กับ release ที่ต้องการได้

การติดตั้ง Octop ด้วย Docker Compose โดยล็อกเวอร์ชันไว้ที่ v0.9.19

ณ เดือนสิงหาคม 2026 ยังไม่มีอิมเมจที่เผยแพร่ให้ดึงมาใช้งานได้ ไฟล์ Compose ที่ให้มาจะทำการ build อิมเมจจาก repository โดยตรง ดังนั้นการล็อกเวอร์ชันจึงหมายถึงการ checkout ไปยัง git tag ที่ต้องการ นี่เป็นขั้นตอนที่เพิ่มขึ้นมามากกว่าโปรเจกต์ self-hosted ส่วนใหญ่ เนื่องจากบริการอย่าง พื้นที่ทำงาน AFFiNE แบบ self-hosted จะล็อกเวอร์ชันไว้ที่ tag ของอิมเมจที่เผยแพร่แล้วและไม่ต้อง build อะไรบน VPS ของคุณเลย ขั้นตอนการ clone, checkout และ build ด้านล่างนี้เป็นขั้นตอนเดียวกับที่ คู่มือการติดตั้ง openGym แนะนำไว้ ดังนั้นหากคุณเคยตั้งค่าโปรเจกต์นั้นมาแล้ว คุณจะคุ้นเคยกับรูปแบบนี้ดี

git clone https://github.com/TencentCloud/Octop.git
cd Octop
git checkout v0.9.19

นี่คือบริการที่ไฟล์กำหนดไว้ โดยตัดส่วนที่ไม่เกี่ยวข้องออกไป:

services:
  octop:
    build:
      context: ..
      dockerfile: docker/Dockerfile
    image: octop:latest
    container_name: octop
    restart: unless-stopped
    ports:
      - "${OCTOP_PORT:-8088}:${OCTOP_PORT:-8088}"
    volumes:
      - ${OCTOP_DATA:-~/.octop}:/data/.octop
    environment:
      - HOME=/data
      - OCTOP_BIND_HOST=0.0.0.0
      - OCTOP_PORT=${OCTOP_PORT:-8088}
      - OCTOP_DEFAULT_PASSWORD=${OCTOP_DEFAULT_PASSWORD:-octop}
      - OCTOP_ADMIN_USERNAME=${OCTOP_ADMIN_USERNAME:-admin}
      - OPENAI_API_KEY=${OPENAI_API_KEY:-}

สังเกตบล็อก build: ค่า image: octop:latest คือชื่อที่อิมเมจที่คุณ build เองจะได้รับ ไม่ใช่การอ้างอิงจาก registry ดังนั้น latest ในที่นี้จึงหมายถึงสิ่งที่คุณเพิ่งคอมไพล์ล่าสุด ให้กำหนด path ของข้อมูลไว้ในตำแหน่งที่ชัดเจนแทนการปล่อยให้เป็นค่าเริ่มต้น และตั้งรหัสผ่านสำหรับบัญชีผู้ดูแลระบบให้เรียบร้อยก่อนการเริ่มระบบครั้งแรก โดยใส่ไว้ใน docker/.env:

OCTOP_PORT=8088
OCTOP_ADMIN_USERNAME=admin
OCTOP_DEFAULT_PASSWORD=<a long random password>
OCTOP_DATA=/srv/octop-data

มีกับดักจุดหนึ่งที่สำคัญกว่าส่วนอื่นของไฟล์ Compose จะอ่านค่า docker/.env เพื่อนำไปแทนที่ตัวแปร ${...} ในไฟล์ YAML เท่านั้น คีย์ที่คุณเพิ่มลงในไฟล์นั้นจะ ไม่ ถูกส่งเข้าไปในคอนเทนเนอร์หากไม่ได้ระบุไว้ภายใต้ environment: ในไฟล์ Compose การเพิ่ม OCTOP_ACCESS_TOKEN_TTL ลงใน .env เพียงอย่างเดียวจะไม่ส่งผลใดๆ ทั้งสิ้นโดยไม่มีการแจ้งเตือน อีกทางเลือกหนึ่งคือการเขียนคีย์เดียวกันลงใน ~/.octop/env ภายในไดเรกทอรีข้อมูลที่ mount ไว้ ซึ่ง Octop จะโหลดค่าเหล่านี้เมื่อเริ่มทำงาน คู่มือเกี่ยวกับไฟล์ env และ secrets ใน Docker Compose ได้อธิบายเหตุผลว่าทำไมกลไกทั้งสองนี้จึงไม่เหมือนกัน

ทำการ build และเริ่มการทำงาน:

docker compose -f docker/docker-compose.yml up -d --build
docker compose -f docker/docker-compose.yml ps
curl http://127.0.0.1:8088/api/health

อินสแตนซ์ที่ทำงานปกติจะตอบกลับ health check ด้วย {"status":"ok","version":"..."} หากพบสถานะอื่น ให้ตรวจสอบ docker compose -f docker/docker-compose.yml logs -f octop ก่อนที่จะเปิดใช้งานผ่านเบราว์เซอร์

จากนั้นให้ตั้งชื่ออิมเมจที่คุณเพิ่ง build เพื่อให้สื่อความหมาย เพราะการสั่ง --build ครั้งถัดไปจะเขียนทับ octop:latest และคุณจะไม่สามารถแยกแยะความแตกต่างระหว่างสองเวอร์ชันได้:

docker image tag octop:latest octop:0.9.19

การเริ่มระบบครั้งแรกจะรัน octop init และเขียนข้อมูลประจำตัวเริ่มต้นลงใน data volume:

docker exec -it octop cat /data/.octop/credential.txt

ค่าเริ่มต้นคือ admin / octop ซึ่งจะถูกนำไปใช้ เฉพาะในการเริ่มระบบครั้งแรกเท่านั้น นี่คือกลไกเบื้องหลังคำถามที่พบบ่อย: การเปลี่ยน OCTOP_DEFAULT_PASSWORD หลังจากที่คอนเทนเนอร์เริ่มทำงานไปแล้วจะไม่ส่งผลใดๆ เพราะบัญชีผู้ใช้งานถูกสร้างขึ้นไปแล้ว ให้เปลี่ยนรหัสผ่านผ่านหน้า dashboard แทน

ห้ามเปิดพอร์ต 8088 สู่สาธารณะ

บรรทัด ports: ด้านบนเป็นการผูกบริการเข้ากับทุกอินเทอร์เฟซบน VPS ทันทีที่คอนเทนเนอร์เริ่มทำงาน แดชบอร์ดจะปรากฏบนอินเทอร์เน็ตสาธารณะในรูปแบบข้อความธรรมดา (cleartext) พร้อมรหัสผ่านเริ่มต้น ค่าเริ่มต้น OCTOP_BIND_HOST ของ Octop คือ 127.0.0.1 แต่ไฟล์ Compose ได้เขียนทับเป็น 0.0.0.0 เนื่องจากกระบวนการต้องรับทราฟฟิกจากภายนอกเนมสเปซเครือข่ายของตัวเอง การเขียนทับนั้นถูกต้องแล้ว แต่ส่วนที่ทำให้คุณเสี่ยงคือการประกาศพอร์ต (published port)

ให้แก้ไขบรรทัด ports: ใน docker/docker-compose.yml เพื่อให้การแมปพอร์ตฟังเฉพาะบน loopback เท่านั้น:

    ports:
      - "127.0.0.1:${OCTOP_PORT:-8088}:${OCTOP_PORT:-8088}"

อย่าพยายามแก้ไขปัญหานี้ด้วยไฟล์ override แบบธรรมดา เนื่องจาก Compose จะนำรายการ ports จากหลายไฟล์มาต่อกันแทนที่จะแทนที่รายการเดิม ส่งผลให้คุณเปิดพอร์ตทั้งสองรายการและรายการที่สองจะล้มเหลวเพราะไม่สามารถผูกพอร์ตได้ หากคุณต้องการคงไฟล์ต้นฉบับไว้โดยไม่แก้ไข ให้ใช้แท็ก !override บนลำดับรายการ ซึ่งเป็นวิธีมาตรฐานที่ระบุไว้ในเอกสารสำหรับการแทนที่ข้อมูลแทนการต่อท้าย คำอธิบายวิธีการรวมไฟล์หลายไฟล์ของ Compose ครอบคลุมกฎการรวมไฟล์ส่วนที่เหลือทั้งหมด

การผูกบริการไว้กับ loopback ยังช่วยแก้ปัญหาที่คุณอาจพบกับไฟร์วอลล์ได้อีกด้วย Docker จะเขียนกฎการเปิดพอร์ตลงในตาราง nat ก่อนที่ ufw จะจัดการ ทำให้ ufw deny 8088 ไม่สามารถหยุดพอร์ตของคอนเทนเนอร์ที่ถูกเปิดไว้ได้ พอร์ตที่ผูกไว้กับ 127.0.0.1 จะไม่มีทางเข้าถึงได้จากภายนอกไม่ว่า ufw จะตั้งค่าไว้อย่างไรก็ตาม นี่จึงเป็นวิธีแก้ไขที่ถูกต้องที่สุดแทนที่จะใช้วิธีอื่นที่เป็นเพียงทางเลือกสำรอง

วาง TLS ไว้ด้านหน้าด้วย reverse proxy

Caddy เป็นวิธีที่สั้นที่สุด เนื่องจากโปรแกรมจะร้องขอ certificate ผ่าน ACME (automatic certificate management environment) ด้วยตัวเอง และทำ proxy ให้ WebSockets ได้โดยไม่ต้องตั้งค่าเพิ่มเติม:

octop.example.com {
    reverse_proxy 127.0.0.1:8088
}

nginx ต้องการการดูแลมากกว่า เนื่องจาก Octop สตรีมแชทผ่าน WebSocket:

server {
    listen 443 ssl;
    server_name octop.example.com;

    ssl_certificate     /etc/letsencrypt/live/octop.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/octop.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8088;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_buffering off;
        proxy_read_timeout 3600s;
    }
}

ทุกบรรทัดในนั้นมีหน้าที่เฉพาะ แชททำงานผ่าน WS /agents/{id}/chat/ws ดังนั้นหากไม่มี proxy_http_version 1.1 และ header สำหรับ upgrade สองบรรทัดนั้น nginx จะตอบกลับความพยายามในการ upgrade ด้วย 400 Bad Request ส่งผลให้ dashboard โหลดได้ตามปกติ แต่ทุกข้อความที่คุณส่งจะค้างตลอดไปโดยไม่มีข้อความแสดงข้อผิดพลาดบนหน้าเว็บ proxy_buffering off มีความสำคัญเนื่องจาก endpoint สำหรับ resume ของ human-in-the-loop จะส่งค่ากลับเป็น text/event-stream และ SSE (server-sent events) ที่ถูกกักไว้ใน proxy buffer จะถูกส่งออกมาเป็นก้อนเดียวในตอนท้ายแทนที่จะเป็นการสตรีมแบบต่อเนื่อง proxy_read_timeout ครอบคลุมการทำงานของเครื่องมือที่ใช้เวลานาน เนื่องจากค่าเริ่มต้นที่ 60 วินาทีจะตัดการทำงานของ agent กลางคันและบันทึก log เป็น upstream timed out (110: Connection timed out)

การทำงานของ JWT auth เมื่ออยู่หลังพร็อกซี

Octop ใช้ bearer token ในการยืนยันตัวตน ไม่ใช่คุกกี้ POST /api/auth/login จะส่งคืน {access_token, role, user, ...} และการเรียกใช้งานในภายหลังจะแนบ Authorization: Bearer <access_token> ไปด้วย สำหรับ reverse proxy แล้ว นี่เป็นข้อดีเพราะไม่มีเรื่องของโดเมนคุกกี้ ไม่มี flag Secure และไม่มีกฎ SameSite ที่ต้องกังวล ดังนั้นเซสชันที่ทำงานได้บน http://127.0.0.1:8088 จึงทำงานได้เหมือนกันบน https://octop.example.com

มีผลลัพธ์สองประการที่ควรทราบก่อนเริ่มใช้งานจริงกับผู้ใช้:

WebSocket จะแนบ token มาใน URL endpoint คือ WS /agents/{id}/chat/ws?token=<jwt> เนื่องจาก JavaScript บนเบราว์เซอร์ไม่สามารถกำหนด Authorization header ในระหว่างการทำ WebSocket handshake ได้ แม้ว่า TLS จะช่วยป้องกัน token ในระหว่างการรับส่งข้อมูล แต่ไม่ได้ป้องกันการบันทึกใน log ของคุณ โดยปกติแล้ว nginx จะบันทึกบรรทัดคำขอทั้งหมดรวมถึง query string ลงใน access_log ดังนั้น token ของผู้ใช้จริงจะถูกบันทึกเป็นข้อความธรรมดาบนเซิร์ฟเวอร์ คุณควรบันทึกเฉพาะ path โดยตัด argument ออก $uri คือ path ที่ถูกปรับรูปแบบให้เป็นมาตรฐานโดยตัด query string ออกแล้ว ให้ใส่ค่านี้ไว้ในบล็อก http และอ้างอิงจากเซิร์ฟเวอร์:

log_format octop_noargs '$remote_addr [$time_local] '
                        '"$request_method $uri $server_protocol" '
                        '$status $body_bytes_sent';
access_log /var/log/nginx/octop.log octop_noargs;

ไม่มีการ logout แยกรายเซสชัน OCTOP_ACCESS_TOKEN_TTL มีค่าเริ่มต้นเป็น 86400 ดังนั้น token จะยังคงใช้งานได้เป็นเวลา 24 ชั่วโมงหลังจากเข้าสู่ระบบ วิธีเดียวที่ระบุไว้ในเอกสารเพื่อยกเลิกการใช้งานคือ octop admin rotate-jwt-secret ซึ่งจะเป็นการหมุนเวียน (rotate) คีย์การลงนามที่เก็บไว้ที่ ~/.octop/secrets/jwt_secret และทำให้ token ทั้งหมดที่มีอยู่ใช้งานไม่ได้ทันทีสำหรับทุกคน ดังนั้นเมื่อมีคนออกจากทีม ลำดับขั้นตอนคือ: ลบผู้ใช้ออก, หมุนเวียน secret, แล้วแจ้งให้ผู้ใช้ที่เหลือเข้าสู่ระบบใหม่ หากวิธีนี้ดูยุ่งยากเกินไป ให้ลดระยะเวลาการใช้งานลง โดยอย่าลืมเพิ่มตัวแปรลงในรายการ environment: และ .env:

OCTOP_ACCESS_TOKEN_TTL=28800

ระบบมีการจัดการการโจมตีแบบ brute force โดย OCTOP_LOGIN_MAX_ATTEMPTS มีค่าเริ่มต้นที่ 5 ครั้ง และ OCTOP_LOGIN_LOCKOUT_SECONDS มีค่าเริ่มต้นที่ 900 วินาที ดังนั้นผู้ใช้ที่ถูกล็อกจะไม่เห็นหน้าจอที่พัง แต่จะเป็นการรอคอยเป็นเวลาสิบห้านาทีแทน Octop มีระบบจัดเก็บผู้ใช้ของตนเองและยังไม่มีการรองรับ OIDC อย่างเป็นทางการในเวอร์ชัน v0.9.19 ดังนั้นหากคุณต้องการระบบ single sign-on จริงๆ คุณควรวาง authenticating proxy ไว้ด้านหน้า ซึ่งเป็นหน้าที่ของ เซิร์ฟเวอร์ Authentik ที่โฮสต์เอง

การกำหนด Octop ให้เชื่อมต่อกับโมเดลแบ็กเอนด์

ผู้ให้บริการจะถูกกำหนดค่าแยกตามเอเจนต์ในแดชบอร์ด และ octop provider list จะแสดงสิ่งที่ตั้งค่าไว้ Octop มาพร้อมกับค่าเริ่มต้นสำหรับ API ที่รองรับมาตรฐาน OpenAI, DashScope (Qwen) และ Ollama โดยข้อมูลรับรองจะถูกจัดเก็บไว้ในตาราง providers ของฐานข้อมูล SQLite ของคุณเอง การเลือกผู้ให้บริการจะส่งผลต่อค่าใช้จ่ายและข้อมูลที่ถูกส่งออกไปภายนอกเซิร์ฟเวอร์

โมเดลภายในเครื่องด้วย Ollama ข้อมูลจะไม่ถูกส่งออกจากเซิร์ฟเวอร์ และคุณจะจ่ายด้วยทรัพยากร RAM แทนการจ่ายเป็นโทเค็น รายละเอียดการเชื่อมต่อที่มักทำให้เกิดปัญหาคือ คอนเทนเนอร์ไม่สามารถเข้าถึง Ollama ของโฮสต์ที่ 127.0.0.1:11434 ได้ เนื่องจากที่อยู่ดังกล่าวคือ loopback ของตัวคอนเทนเนอร์เอง ให้เพิ่ม host gateway เข้าไปในบริการดังนี้:

    extra_hosts:
      - "host.docker.internal:host-gateway"

จากนั้นตั้งค่า base URL ของผู้ให้บริการเป็น http://host.docker.internal:11434/v1 ซึ่งเป็น path ที่รองรับมาตรฐาน OpenAI ของ Ollama และใส่สตริงใดก็ได้ที่ไม่ว่างเปล่าลงในช่อง API key เนื่องจาก Ollama จะไม่ตรวจสอบค่านี้ แต่ไคลเอนต์ OpenAI จะปฏิเสธการส่งหากช่องว่างเปล่า นอกจากนี้ Ollama จะต้องฟังการเชื่อมต่อที่นอกเหนือจาก loopback เพื่อให้ทำงานได้ ซึ่งหมายถึงการตั้งค่า OLLAMA_HOST=0.0.0.0:11434 ใน unit ของ systemd นี่คือส่วนที่มีความเสี่ยง เนื่องจาก Ollama ไม่มีการตรวจสอบสิทธิ์ ดังนั้นการเปิดพอร์ต 11434 บน IP สาธารณะจะทำให้ใครก็ตามที่สแกนพอร์ตสามารถใช้งานโมเดลเซิร์ฟเวอร์ของคุณได้ฟรี ควรอนุญาตเฉพาะช่วง IP ภายในของ Docker คือ sudo ufw allow from 172.16.0.0/12 to any port 11434 proto tcp และปฏิเสธการเชื่อมต่อจากที่อื่น การรัน Ollama บน VPS ครอบคลุมเรื่องการเลือกขนาดโมเดล และ การเปรียบเทียบระหว่าง Ollama และ vLLM จะอธิบายว่าเมื่อใดที่ Ollama อาจไม่ใช่เซิร์ฟเวอร์ที่เหมาะสมอีกต่อไป

คำเตือนเพิ่มเติมสำหรับโมเดลภายในเครื่อง เนื่องจากอาจดูเหมือนเป็นบั๊กใน Octop แต่จริงๆ แล้วไม่ใช่ เอเจนต์ทำงานโดยการเรียกใช้เครื่องมือ (tools) ซึ่ง system prompt รวมกับคำจำกัดความของเครื่องมือและประวัติการสนทนาจะทำให้ prompt มีขนาดใหญ่ Ollama ให้บริการโมเดลด้วย context window เริ่มต้นที่ค่อนข้างจำกัด ดังนั้นส่วนต้นของ prompt ซึ่งเป็นที่อยู่ของคำจำกัดความเครื่องมือจึงอาจหลุดออกจาก window ไป ส่งผลให้โมเดลหยุดเรียกใช้เครื่องมือหรือสร้างเครื่องมือที่ไม่มีอยู่จริงขึ้นมา ให้เพิ่มค่า num_ctx เป็น 16k หรือ 32k และเลือกโมเดลที่มีความสามารถในการเรียกใช้ฟังก์ชัน (function calling) ได้ดี หากคำตอบหยุดกลางคันจะเป็นปัญหาคนละกรณีกันและเกี่ยวข้องกับการตั้งค่า num_predict ดังนั้นหากคำตอบถูกตัดทอน ควร ตรวจสอบว่ามีการตั้งค่า num_predict ไว้ที่ใดและ done_reason ระบุไว้อย่างไร ก่อนที่จะสรุปว่าเป็นความผิดของเอเจนต์ หากคุณต้องการเริ่มต้นจากโมเดลเฉพาะแทนที่จะเป็นรายการตัวเลือก Nemotron 3.5 Lightning เป็นตัวเลือกที่น่าสนใจ โดยบทความดังกล่าวจะระบุ tag ที่ต้องดึงมาใช้งาน, ปริมาณ RAM ที่ต้องการ และข้อมูลว่าการรันด้วย CPU เพียงอย่างเดียวจะเพียงพอหรือไม่

เกตเวย์แบบ self-hosted การติดตั้ง LiteLLM gateway แบบ self-hosted ไว้ระหว่าง Octop กับบริการอื่นๆ จะช่วยให้คุณมี base URL เดียว, คีย์แยกตามผู้ใช้, การจำกัดค่าใช้จ่าย และบันทึกการทำงาน (log) รวมศูนย์ นอกจากนี้คุณยังสามารถสลับโมเดลที่อยู่เบื้องหลังได้โดยไม่ต้องแก้ไขการตั้งค่าใดๆ ใน Octop

API แบบชำระเงิน ให้คุณภาพดีที่สุดโดยมีข้อแลกเปลี่ยนที่ชัดเจนคือ เนื้อหาการสนทนาจะถูกส่งออกจากเซิร์ฟเวอร์ของคุณไปยังผู้ให้บริการ ซึ่งขัดกับวัตถุประสงค์หลักของการทำ self-hosting โดยให้ใส่คีย์ลงใน docker/.env ในรูปแบบ OPENAI_API_KEY ซึ่งไฟล์ Compose ได้ตั้งค่าให้ส่งผ่านข้อมูลนี้ไว้แล้ว

ไม่ว่าคุณจะเลือกวิธีใด ไฟล์ Compose ยังรองรับ OCTOP_LANGFUSE_ENABLED, LANGFUSE_PUBLIC_KEY, LANGFUSE_SECRET_KEY และ LANGFUSE_BASE_URL เพื่อให้คุณสามารถส่งข้อมูลการติดตาม (traces) ไปยัง อินสแตนซ์ Langfuse ของคุณเอง และดูว่าเอเจนต์กำลังทำงานอะไรอยู่จริง แทนที่จะคาดเดาจากหน้าต่างแชทเพียงอย่างเดียว

ผู้ใช้ บทบาท และไลบรารีเอเจนต์ที่ใช้ร่วมกัน

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

โปรดใช้เครื่องมือด้วยความระมัดระวัง Octop มีฟีเจอร์การอนุมัติเครื่องมือและระบบป้องกันคำสั่ง shell ซึ่งเป็นฟีเจอร์ที่มีอยู่จริง แต่เอเจนต์ที่รันคำสั่ง shell จะรันอยู่ภายในคอนเทนเนอร์ของ Octop โดยมีการ mount ข้อมูลของคุณไว้ ระบบป้องกันจะช่วยลดความเสี่ยงจากคำสั่งที่ไม่ได้ตั้งใจ แต่ไม่ใช่ขอบเขตของ sandbox ดังนั้นควรเปิดฟีเจอร์การอนุมัติเครื่องมือไว้สำหรับทุกคนที่คุณไม่ต้องการให้เข้าถึง shell โดยตรง หากคุณกำลังเปรียบเทียบระบบนี้กับตัวเลือกอื่น บทสรุปของ AI agent แบบ self-hosted จะเปรียบเทียบวิธีการจัดการในส่วนนี้ของแต่ละระบบไว้ให้แล้ว

การอัปเกรดโปรเจกต์ที่มีรอบการออกรุ่นรวดเร็ว

ChartDays between Octop releases, v0.9.16 to v0.9.19 (repository tags, 7 August 2026)

version

days_since_previous_release

v0.9.16

v0.9.17

v0.9.18

v0.9.19

The data behind this chart

[
  {
    "version": "v0.9.16",
    "days_since_previous_release": 2
  },
  {
    "version": "v0.9.17",
    "days_since_previous_release": 3
  },
  {
    "version": "v0.9.18",
    "days_since_previous_release": 1
  },
  {
    "version": "v0.9.19",
    "days_since_previous_release": 3
  }
]

นี่คือวันที่ของแท็กจาก repository ซึ่งนับถึงวันที่ 7 สิงหาคม 2026 มีการออกรุ่นที่ติดแท็กจำนวน 4 รุ่นภายในเวลาเก้าวัน โดยมีช่วงห่างสั้นที่สุดเพียง 1 วัน และรุ่น v0.9.19 ก็มาถึงหลังจากแท็กก่อนหน้าเพียง 3 วัน รอบการออกรุ่นเช่นนี้เป็นสัญญาณที่ดีของตัวโปรเจกต์ แต่เป็นเหตุผลที่ไม่ดีนักในการรัน latest โปรดอ่านการเปลี่ยนแปลงก่อนที่คุณจะนำไปใช้งาน:

cd Octop
git fetch --tags
git tag --sort=-creatordate | head
NEW_TAG=$(git tag --sort=-creatordate | head -1)
git log --oneline "v0.9.19..$NEW_TAG"

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

docker compose -f docker/docker-compose.yml stop
sudo tar czf octop-backup-$(date +%F).tgz -C /srv octop-data
docker compose -f docker/docker-compose.yml start

จากนั้นให้ checkout ไปยังแท็กใหม่และ build ใหม่ด้วย docker compose -f docker/docker-compose.yml up -d --build หากเกิดข้อผิดพลาด การ checkout กลับไปยังแท็กเดิมและ build ใหม่จะทำให้ได้โค้ดเดิมกลับมา แต่มีเพียงไฟล์ tarball เท่านั้นที่จะกู้คืนฐานข้อมูลกลับมาได้

ไฟล์ tarball นั้นเก็บ octop.db, config.json, JWT signing secret และ credential.txt เอาไว้ ดังนั้นมันจึงมีความสำคัญเทียบเท่ากับตัวเซิร์ฟเวอร์เอง ควรตั้งค่าสิทธิ์เป็น 600 และเก็บสำเนาไว้นอกเครื่อง สำหรับการติดตั้งขนาดใหญ่ โปรเจกต์ยังมี docker/docker-compose.postgres.yml ซึ่งรัน PostgreSQL ร่วมกับ pgvector แทนการใช้ SQLite

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

Health check ไม่ตอบสนอง curl http://127.0.0.1:8088/api/health ค้างหรือปฏิเสธการเชื่อมต่อ โปรดอ่าน docker compose -f docker/docker-compose.yml logs -f octop คอนเทนเนอร์ที่หยุดทำงานระหว่างการเริ่มต้นครั้งแรกมักเกิดจากไม่สามารถเขียนข้อมูลลงในไดเรกทอรีได้ ให้ตรวจสอบสิทธิ์ความเป็นเจ้าของของพาธที่คุณกำหนดไว้ใน OCTOP_DATA

หน้า Dashboard โหลดได้แต่แชทค้าง ไม่มีการแสดงข้อผิดพลาดบนหน้าเว็บและไม่มีการตอบกลับใดๆ ให้เปิด Browser Console แล้วตรวจสอบการเชื่อมต่อที่ล้มเหลวไปยัง wss://octop.example.com/agents/.../chat/ws แสดงว่า Proxy ไม่ได้ส่งต่อการเชื่อมต่อแบบ Upgrade ให้เพิ่ม proxy_http_version 1.1 และส่วนหัว Upgrade กับ Connection

ข้อความตอบกลับปรากฏขึ้นพร้อมกันทั้งหมดหลังจากผ่านไปหลายวินาที ระบบ Streaming ทำงานอยู่แต่มีการทำ Buffering เกิดขึ้น ให้ตั้งค่า proxy_buffering off

bind: address already in use มีบางอย่างใช้งานพอร์ต 8088 อยู่แล้ว ให้ใช้ sudo ss -tlnp | grep 8088 เพื่อระบุว่าคือโปรเซสใด นี่เป็นข้อผิดพลาดที่จะเกิดขึ้นเช่นกันหากคุณเพิ่มรายการ ports ซ้ำเป็นรายการที่สองในไฟล์ Override แทนที่จะแก้ไขไฟล์ต้นฉบับ

รหัสผ่านที่ถูกต้องถูกปฏิเสธ การป้อนรหัสผ่านผิด 5 ครั้งจะทำให้ระบบล็อกเป็นเวลา 900 วินาที ให้รอจนกว่าเวลาจะหมดแทนการติดตั้งใหม่

รหัสผ่านใหม่ใน .env ไม่มีผล ข้อมูลประจำตัวเหล่านั้นจะมีผลเฉพาะในการเริ่มต้นระบบครั้งแรกเท่านั้น ให้เปลี่ยนรหัสผ่านผ่านทาง Dashboard แทน

Agent ตอบกลับแต่ไม่ยอมรันเครื่องมือ (Tool) มักเกิดจากปัญหาของโมเดลในเครื่อง: หน้าต่าง Context มีขนาดเล็กเกินไปสำหรับคำจำกัดความของเครื่องมือ หรือโมเดลไม่มีประสิทธิภาพในการเรียกใช้ฟังก์ชัน (Function calling) ให้เพิ่มค่า num_ctx และลองใช้โมเดลที่ออกแบบมาเพื่อการใช้งานเครื่องมือโดยเฉพาะ

FAQ

Octop เป็นตัวแทนของ Open WebUI หรือไม่?

เป็นเพียงในกรณีที่คุณต้องการฟีเจอร์ที่เพิ่มเข้ามาเท่านั้น Open WebUI เป็นอินเทอร์เฟซแชทสำหรับโมเดลซึ่งทำงานได้ดีสำหรับผู้ใช้คนเดียวหรือในครัวเรือนที่ไว้ใจกันได้ Octop เพิ่มระบบบัญชีที่มีบทบาทผู้ดูแลระบบ (admin), พื้นที่ทำงานและข้อมูลประจำตัวแยกตามผู้ใช้ และคลังเอเจนท์เฉพาะทางที่สลับใช้งานได้ ทำให้หลายคนสามารถใช้เซิร์ฟเวอร์เดียวกันได้โดยไม่ปะปนประวัติการใช้งาน หากบัญชีเดียวเพียงพอสำหรับคุณ Open WebUI เป็นตัวเลือกที่เรียบง่ายและมีความเสถียรมากกว่ามาก

ทำไมฉันไม่ควรใช้สคริปต์ติดตั้ง curl ของ Octop?

สคริปต์ดังกล่าวถูกให้บริการผ่าน Tencent Cloud Object Storage แทนที่จะมาจาก repository โดยตรง จึงไม่มี git tag หรือ commit ใดๆ รองรับ คุณไม่สามารถตรวจสอบได้ว่าสคริปต์ทำงานอย่างไรในวันนี้เมื่อเทียบกับสัปดาห์ที่แล้ว และการส่งสคริปต์ผ่านไปป์เข้า bash จะทำให้สคริปต์ทำงานทันทีโดยที่คุณยังไม่ได้อ่าน นอกจากนี้สคริปต์ยังติดตั้งลงบนโฮสต์โดยใช้สภาพแวดล้อม Python 3.12 ของตัวเอง ซึ่งอยู่นอกเหนือการจัดการของ package manager ของคุณ ให้ดาวน์โหลดและอ่านสคริปต์ก่อน หรือเลือกติดตั้งด้วย Docker Compose จาก tag ที่ตรวจสอบแล้วแทน

Octop สามารถใช้โมเดลในเครื่องแทน API แบบเสียค่าใช้จ่ายได้หรือไม่?

ได้ Octop รองรับ API ที่เข้ากันได้กับ OpenAI และมีค่าเริ่มต้นสำหรับ Ollama มาให้ ดังนั้นการชี้ไปที่ http://host.docker.internal:11434/v1 จะใช้งานได้เมื่อคุณเพิ่ม extra_hosts: ["host.docker.internal:host-gateway"] เข้าไปในคอนเทนเนอร์และตั้งค่า OLLAMA_HOST=0.0.0.0:11434 บนโฮสต์ ให้ตั้งค่า Firewall ที่พอร์ต 11434 ให้รับเฉพาะช่วง IP ของ Docker เนื่องจาก Ollama ไม่มีระบบยืนยันตัวตนในตัว คุณควรเพิ่มค่า num_ctx ของ Ollama เป็น 16k หรือสูงกว่า เนื่องจาก prompt ของเอเจนท์ที่มีการกำหนดเครื่องมือ (tool definitions) จะทำให้ context window เริ่มต้นเต็ม และโมเดลจะหยุดเรียกใช้เครื่องมือเหล่านั้น

ฉันจำเป็นต้องใช้ reverse proxy หรือสามารถเปิดพอร์ต 8088 ได้เลย?

คุณจำเป็นต้องใช้ proxy ไฟล์ Compose ที่มากับ Octop จะเปิดพอร์ต 8088 บนทุกอินเทอร์เฟซโดยไม่มี TLS ทำให้รหัสผ่านและ bearer token ถูกส่งผ่านอินเทอร์เน็ตในรูปแบบข้อความธรรมดา ให้เปลี่ยนพอร์ตที่เปิดใช้งานเป็น 127.0.0.1:8088:8088 และวาง Caddy หรือ nginx ไว้ด้านหน้าพร้อมใบรับรอง หากใช้ nginx ให้ส่งต่อ WebSocket upgrade headers และตั้งค่า proxy_buffering off มิฉะนั้นหน้าเว็บจะโหลดขึ้นมาได้แต่การแชทจะไม่ตอบสนอง

Octop พร้อมสำหรับการใช้งานในระดับ production หรือยัง?

ซอฟต์แวร์นี้ยังอยู่ในสถานะก่อน 1.0 และมีการออก release ใหม่หลายครั้งต่อสัปดาห์ ณ เดือนสิงหาคม 2026 ดังนั้นให้ถือว่าเป็นซอฟต์แวร์ที่น่าสนใจแต่ยังไม่นิ่ง ซึ่งสามารถใช้งานได้สำหรับครอบครัวหรือทีมงานภายในขนาดเล็ก หากคุณล็อกเวอร์ชันด้วย tag ที่แน่นอน อ่าน commit log ก่อนการอัปเกรดทุกครั้ง และสำรองข้อมูล volume ก่อนการ rebuild ทุกครั้ง อย่ารันบน latest และอย่าเพิ่งนำข้อมูลลูกค้าไปใส่ในระบบนี้

#octop#self-hosting #ai-assistant #docker-compose #ollama