SSD Nodes Learn Hosting plans →
คู่มือ Matt Connorโดย Matt Connor · อัปเดตเมื่อ 2026-08-28

วิธีติดตั้ง KiroCrew บน VPS ให้รันต่อเนื่องตลอด 24 ชั่วโมง

เรียนรู้วิธีติดตั้ง KiroCrew บน VPS ด้วย Docker และ systemd เพื่อให้เอเจนต์ทำงานได้ตลอดเวลา พร้อมวิธีจัดการหน่วยความจำ การสำรองข้อมูล และการย้อนกลับเวอร์ชันเมื่อเกิดข้อผิดพลาด

เหตุใดจึงควรโฮสต์ KiroCrew บน VPS แทนที่จะเป็นแล็ปท็อป

การโฮสต์ KiroCrew ด้วยตนเองจะคุ้มค่าก็ต่อเมื่อรันบนเครื่องที่ไม่เคยปิดการทำงาน ดังนั้น VPS จึงเป็นที่ที่เหมาะสมสำหรับมันมากกว่าแล็ปท็อป KiroCrew จะเก็บประวัติเซสชัน, หน่วยความจำเชิงความหมาย (semantic memory), งานที่ตั้งเวลาไว้ และคิวการอนุมัติไว้บนดิสก์ และจะโหลดข้อมูลทั้งหมดนี้ใหม่เมื่อกระบวนการทำงานเริ่มต้นขึ้นใหม่ ข้อมูลเหล่านี้จะไม่มีประโยชน์เลยหากกระบวนการไม่ได้ทำงานในช่วงเวลา 03:00 น. ซึ่งเป็นเวลาที่งานที่ตั้งไว้ต้องทำงาน และแล็ปท็อปที่ปิดฝาอยู่ก็ไม่สามารถรันกระบวนการดังกล่าวได้

KiroCrew เป็นพื้นที่ทำงานสำหรับเอเจนต์แบบโอเพนซอร์สจากทีม Kiro ซึ่งได้รับอนุญาตภายใต้สัญญาอนุญาต Apache 2.0 โดยมีการปล่อยเวอร์ชันสาธารณะครั้งแรกในช่วงต้นเดือนสิงหาคม 2026 กระบวนการหนึ่งที่เรียกว่า gateway จะเป็นผู้ดูแลสถานะและให้บริการแดชบอร์ดบนเว็บผ่านพอร์ต 5476 คุณสามารถเข้าถึง gateway ดังกล่าวได้จากแดชบอร์ด, จาก kirocrew CLI หรือจากช่องทางแชท เช่น Slack ตัว gateway เป็นเพียงสิ่งเดียวที่คุณต้องโฮสต์ด้วยตนเอง ดังนั้นคู่มือนี้จึงเน้นไปที่การทำให้มันทำงานได้อย่างต่อเนื่อง, การป้องกันไม่ให้เข้าถึงได้จากอินเทอร์เน็ตสาธารณะ และการรู้วิธีการกู้คืนระบบหลังจากอัปเกรดแล้วเกิดปัญหา

มีสองสิ่งที่ควรทราบก่อนเริ่มต้น KiroCrew ขับเคลื่อน kiro-cli ซึ่งจำเป็นต้องลงชื่อเข้าใช้ด้วยบัญชี Kiro เพียงครั้งเดียว และการประมวลผลของเอเจนต์ (agent inference) จะถูกเรียกเก็บเงินตามแผนของ Kiro ดังนั้น ณ เดือนสิงหาคม 2026 ระบบนี้จึงไม่ใช่การตั้งค่าแบบออฟไลน์ นอกจากนี้โปรเจกต์นี้ยังมีอายุเพียงไม่กี่สัปดาห์เท่านั้น ให้สันนิษฐานไว้ก่อนว่าคุณอาจจำเป็นต้องย้อนกลับเวอร์ชันในบางช่วงเวลา ดังนั้นควรติดตั้งในรูปแบบที่เอื้อต่อการดำเนินการดังกล่าว หากคุณยังไม่เคยรันเอเจนต์บนเซิร์ฟเวอร์มาก่อน การรันเอเจนต์สำหรับเขียนโค้ดบน VPS จะครอบคลุมกฎพื้นฐานที่คู่มือนี้ใช้เป็นฐาน หากคุณยังใหม่กับฝั่งเอเจนต์มากกว่าฝั่งเซิร์ฟเวอร์ การ เรียนรู้ว่าลูปของเอเจนต์, เครื่องมือ และหน่วยความจำของมันคืออะไร ก่อน จะช่วยให้คุณเข้าใจตัวเลือกต่างๆ ด้านล่างนี้ในฐานะการตัดสินใจเชิงเทคนิค แทนที่จะเป็นเพียงคำสั่งที่ต้องทำตามโดยไม่เข้าใจเหตุผล

สิ่งที่ KiroCrew ต้องการและตำแหน่งที่เก็บสถานะของระบบ

การติดตั้งแบบ native ต้องการ Python 3.10 หรือใหม่กว่า (โครงการแนะนำเวอร์ชัน 3.12), Node.js 18 หรือใหม่กว่าหากคุณต้องการ build dashboard จาก source และ kiro-cli ซึ่งการเปิดใช้งานครั้งแรกจะทำการติดตั้งและลงชื่อเข้าใช้ให้คุณโดยอัตโนมัติ การติดตั้งแบบ container ไม่จำเป็นต้องมีสิ่งเหล่านี้บน host สิ่งที่จำเป็นมีเพียง Docker เท่านั้น ซึ่งเป็นเหตุผลหลักที่ควรเลือกใช้วิธีนี้

สถานะของระบบจะถูกเก็บไว้ใน ~/.kiro/crew และตัวแปรสภาพแวดล้อม KIROCREW_HOME สามารถใช้เพื่อย้ายตำแหน่งจัดเก็บไปยังที่อื่นได้ โดยสิ่งที่อยู่ภายในประกอบด้วย:

  • config.json: การตั้งค่า gateway และข้อมูลรับรองสำหรับช่องทางแชท
  • .env: ข้อมูลลับ (secrets)
  • workspace/memory/: การตั้งค่าส่วนบุคคล, บันทึกโครงการ และประวัติการแชท
  • memory.db และ memory_index.db: ดัชนีแบบ semantic และแบบ full-text
  • models/: โมเดล embedding ซึ่งจะถูกดาวน์โหลดในการรันครั้งแรก
  • gateway.log และ security_events.jsonl: log ของ runtime และ log ของเหตุการณ์ด้านความปลอดภัย

ไดเรกทอรีดังกล่าวคือตัวการติดตั้งทั้งหมด หากคุณคัดลอกไปยัง VPS เครื่องใหม่ คุณก็จะเป็นการย้าย agent ของคุณไปที่นั่น ซึ่งเป็นเหตุผลว่าทำไมส่วนการสำรองข้อมูลด้านล่างจึงมีความสำคัญมากกว่าส่วนการติดตั้ง

ควรวางแผนเรื่องพื้นที่ดิสก์มากกว่า RAM ตัว gateway เป็นกระบวนการของ Python ส่วนสิ่งที่ทำให้เครื่องทำงานหนักจริงๆ คือสิ่งที่ agent รัน เช่น การ build หรือการรันชุดทดสอบ ไดเรกทอรีสถานะจะขยายขนาดขึ้นตามประวัติการแชท และโมเดล embedding จะถูกดาวน์โหลดในการเริ่มทำงานครั้งแรก ดังนั้นควรวัดขนาดด้วย du -sh ~/.kiro/crew บนเครื่องของคุณเองหลังจากผ่านไปสองสามสัปดาห์ แทนที่จะเชื่อตัวเลขที่เผยแพร่ในช่วงเดือนแรกของโครงการ ซึ่งต่างจาก runtime ที่ให้ worker แต่ละตัวมี container และ browser ของตัวเอง ซึ่งในกรณีของ การ self-host AI coworkers ของ OpenBot การคำนวณขนาดจะเป็นเรื่องของ RAM ก่อนที่จะเป็นเรื่องของดิสก์

คุณควรเลือกใช้เส้นทางการติดตั้งแบบใดจากทั้ง 3 รูปแบบ

โครงการนี้เผยแพร่ซอฟต์แวร์ออกมา 3 รูปแบบ ตัวติดตั้งแบบบรรทัดเดียวจะดึงไฟล์ wheel มาและนำ kirocrew ไปไว้ใน PATH ของคุณ:

curl -fsSL https://download.crew.kiro.dev/cli.sh | sh

ตัวติดตั้งนี้รองรับการระบุ flag ของช่องทาง (channel) และเวอร์ชัน (version):

curl -fsSL https://download.crew.kiro.dev/cli.sh | sh -s -- --channel insider
curl -fsSL https://download.crew.kiro.dev/cli.sh | sh -s -- --version 0.1.3

อิมเมจคอนเทนเนอร์ถูกเผยแพร่ไว้ที่ ghcr.io/kirodotdev/kirocrew สำหรับ linux/amd64 และ linux/arm64 ในทุกแท็ก ส่วนการ build จากซอร์สโค้ดคือ git clone รวมกับ make build ซึ่งมีไว้สำหรับผู้ที่ต้องการแก้ไขโค้ด ไม่ใช่สำหรับผู้ที่ต้องการใช้งานทั่วไป

แนะนำให้ใช้คอนเทนเนอร์ การติดตั้งแบบ native จะนำแพ็กเกจ Python, Node และ kiro-cli ไปวางไว้บนโฮสต์เดียวกับที่รันบริการอื่นๆ ของคุณ ดังนั้นหากการอัปเกรดเกิดข้อผิดพลาด คุณจะต้องมานั่งแก้ไขด้วยตนเอง แต่คอนเทนเนอร์จะเก็บรันไทม์ไว้ในอิมเมจเดียวและเก็บสถานะไว้ใน volume เดียว ซึ่งทำให้การย้อนกลับ (rollback) ทำได้เพียงแค่เปลี่ยนแท็กแล้วรีสตาร์ทเท่านั้น

กำหนดเวอร์ชันอิมเมจด้วย release tag แทนการใช้ stable

ตัวอย่างของโปรเจกต์เองใช้ tag stable:

docker run -d --name kirocrew \
  -p 127.0.0.1:5476:5476 \
  -v kirocrew-home:/home/kirocrew \
  ghcr.io/kirodotdev/kirocrew:stable

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

เขียน /opt/kirocrew/compose.yaml:

services:
  kirocrew:
    image: ghcr.io/kirodotdev/kirocrew:0.1.3
    container_name: kirocrew
    restart: unless-stopped
    ports:
      - "127.0.0.1:5476:5476"
    volumes:
      - kirocrew-home:/home/kirocrew

volumes:
  kirocrew-home:

เริ่มการทำงาน จากนั้นตรวจสอบ health endpoint ที่อิมเมจใช้สำหรับ HEALTHCHECK ของตัวมันเอง:

cd /opt/kirocrew
docker compose up -d
docker compose ps
curl -s http://127.0.0.1:5476/api/health

docker compose ps ควรรายงานสถานะคอนเทนเนอร์ว่า healthy ภายในเวลาประมาณหนึ่งนาที และ /api/health จะตอบกลับโดยไม่ต้องใช้ token (เช่นเดียวกับ /api/live และ /api/ready ซึ่งเป็นเหตุผลที่ทำให้สามารถใช้เป็น probe ได้) หากสถานะยังคงเป็น starting ให้อ่าน docker logs kirocrew ก่อนที่จะแก้ไขใดๆ การรันครั้งแรกจะมีการดาวน์โหลด embedding model ดังนั้นหากการเชื่อมต่อช้า อาจทำให้การเริ่มทำงานครั้งแรกใช้เวลานาน

การรักษาให้ระบบทำงานต่อเนื่องด้วย systemd

restart: unless-stopped จะนำคอนเทนเนอร์กลับมาทำงานใหม่หลังจากเกิดการขัดข้องหรือหลังจากรีบูตเครื่อง ตราบใดที่ Docker เริ่มทำงานตอนบูตเครื่อง ไฟล์ unit จะทำให้ dependency เหล่านี้ชัดเจนและช่วยให้คุณใช้คำสั่งเดียวเพื่อหยุด stack ทั้งหมดก่อนทำการสำรองข้อมูล การเริ่ม Docker Compose stack ตอนบูตเครื่อง ได้ครอบคลุมรูปแบบทั่วไปไว้แล้ว นี่คือรูปแบบของ KiroCrew ใน /etc/systemd/system/kirocrew.service:

[Unit]
Description=KiroCrew gateway
Requires=docker.service
After=docker.service

[Service]
Type=oneshot
RemainAfterExit=yes
WorkingDirectory=/opt/kirocrew
ExecStart=/usr/bin/docker compose up -d
ExecStop=/usr/bin/docker compose down
TimeoutStartSec=0

[Install]
WantedBy=multi-user.target
sudo systemctl daemon-reload
sudo systemctl enable --now kirocrew
systemctl status kirocrew

systemctl status kirocrew ควรมีค่าเป็น active (exited) ซึ่งเป็นผลลัพธ์ที่ถูกต้องสำหรับ unit นี้ การใช้ Type=oneshot ร่วมกับ RemainAfterExit=yes นั้นถูกต้องแล้ว เนื่องจาก docker compose up -d จะคืนค่าทันทีที่คอนเทนเนอร์เริ่มทำงาน systemd จึงติดตามสถานะว่า stack ทำงานอยู่ ไม่ใช่ติดตาม process ที่ทำงานเบื้องหน้า หากคุณเขียน Type=simple แทน systemd จะเห็นว่าคำสั่งจบการทำงานทันที และทำเครื่องหมายว่า service นั้นตายแล้ว จากนั้นจะยอมแพ้หรือวนลูปการรีสตาร์ทขึ้นอยู่กับการตั้งค่า Restart= ของคุณ สำหรับการติดตั้งแบบ native ตัวโปรเจกต์จะมีไฟล์เทียบเท่ามาให้คือ kirocrew service install ซึ่งจะเขียน /etc/systemd/system/kirocrew.service และรัน gateway ในฐานะผู้ใช้ของคุณ ห้ามรันทั้งสอง unit พร้อมกัน หัวข้อนี้ในเวอร์ชันที่กว้างขึ้นอยู่ใน systemd services และ timers บน VPS unit ที่ไม่สามารถกลับมาทำงานได้จะเงียบสนิทเว้นแต่คุณจะตั้งค่าให้มันแจ้งเตือน ดังนั้นให้เพิ่มตัวจัดการ OnFailure= ที่ ส่งการแจ้งเตือนไปยังเซิร์ฟเวอร์ ntfy ของคุณเอง แล้วคุณจะทราบว่า gateway ล่มผ่านทางโทรศัพท์ของคุณ แทนที่จะทราบจากงานที่ตั้งเวลาไว้ซึ่งไม่เคยทำงานเลย

การรันครั้งแรก: ลงชื่อเข้าใช้และรับ dashboard token

คอนเทนเนอร์จะเริ่มการทำงานของ gateway แต่ agent runtime ยังไม่ได้ลงชื่อเข้าใช้ ให้ดำเนินการลงชื่อเข้าใช้ภายในคอนเทนเนอร์ดังนี้:

docker exec -it kirocrew kiro-cli login

ระบบจะแสดง device code และ URL ให้คุณเปิดผ่านเบราว์เซอร์ของคุณ จากนั้นให้สร้าง dashboard token ด้วยคำสั่ง:

docker exec kirocrew kirocrew token --ttl 2h

URL ของ dashboard คือ http://localhost:5476/?token=<the token> โดย token จะมีวันหมดอายุ ซึ่งเซสชันจะมีค่าเริ่มต้นที่ 1 ชั่วโมง และตามเอกสารระบุไว้สูงสุดที่ 20 ชั่วโมง หาก dashboard โหลดขึ้นมาเป็นหน้าว่างหรือเด้งกลับออกมาทันที มักเกิดจาก token หมดอายุ ให้ทำการสร้าง token ใหม่ ห้ามคัดลอก token ไปวางใน ticket หรือข้อความแชทเด็ดขาด เพราะผู้ที่ถือครอง token นี้จะสามารถเข้าถึง agent ของคุณได้ทันที

เข้าถึงแดชบอร์ดผ่าน SSH และห้ามเปิดพอร์ต 5476 สู่สาธารณะ

ให้พิจารณาค่า bind address ในตัวอย่างของโปรเจกต์อีกครั้งที่ -p 127.0.0.1:5476:5476 ภายในคอนเทนเนอร์ เกตเวย์จะฟังที่ 0.0.0.0 เนื่องจากต้องเข้าถึงได้ผ่านการทำ port mapping แต่การ mapping นี้จะเปิดให้ใช้งานเฉพาะ loopback บนโฮสต์เท่านั้น หากลบ prefix 127.0.0.1: ออก เกตเวย์จะถูกเปิดสู่สาธารณะบนอินเทอร์เน็ตสำหรับทุกคนที่สแกนพอร์ตนั้น และกฎของไฟร์วอลล์ก็ช่วยคุณไม่ได้เช่นกัน เนื่องจาก Docker จะเปิดพอร์ตโดยการเขียนกฎ DNAT ซึ่งจะถูกประเมินก่อนการกรองของ ufw ดังนั้น ufw deny 5476 จึงไม่มีผลใดๆ ต่อพอร์ตที่ถูกเปิดไว้ Docker ports bypassing ufw ได้อธิบายกลไกนี้ไว้อย่างละเอียด

ให้ใช้วิธี forward พอร์ตผ่าน SSH จากแล็ปท็อปของคุณแทน:

ssh -N -L 5476:127.0.0.1:5476 you@your-server.example.com

ปล่อยให้คำสั่งนั้นทำงานอยู่แล้วเปิด http://localhost:5476/?token=<the token> บนเครื่องของคุณ หากต้องการให้การ forward เกิดขึ้นอัตโนมัติทุกครั้งที่เชื่อมต่อ ให้ใส่ค่าไว้ใน ~/.ssh/config:

Host your-server.example.com
    LocalForward 5476 127.0.0.1:5476

หากพอร์ต 5476 ถูกใช้งานอยู่บนแล็ปท็อปของคุณ ให้เปลี่ยนเฉพาะตัวเลขด้านซ้ายมือเป็น ssh -N -L 45476:127.0.0.1:5476 you@your-server.example.com แล้วจึงเข้าใช้งานที่ http://localhost:45476/?token=... คุณจะต้องทำ forward ซ้อนกันในลักษณะนี้ทันทีที่มีเอเจนต์ตัวที่สองมาใช้งานบนเซิร์ฟเวอร์เดียวกัน เพราะ self-hosting open-kritt for security scanning จะเปิดแดชบอร์ดที่เข้าถึงได้เฉพาะ loopback อีกตัวหนึ่งบนพอร์ต 5173

พฤติกรรมหนึ่งที่ระบุไว้ในเอกสารซึ่งควรทราบเมื่อใช้งานผ่านอุโมงค์ SSH คือ เกตเวย์จะอ่านคำขอที่ถูก forward มาว่าเป็นคำขอจากระยะไกล ดังนั้น endpoint สำหรับการเขียนค่าคอนฟิกและการเปิดเผย secret ในแดชบอร์ดจะปฏิเสธคำขอเหล่านี้ การที่การตั้งค่าไม่บันทึกเมื่อทำผ่าน SSH เป็นเรื่องปกติ ไม่ใช่บั๊ก ให้แก้ไขคอนฟิกบนโฮสต์โดยตรงแทน:

docker cp kirocrew:/home/kirocrew/.kiro/crew/config.json .
# edit config.json here
docker cp config.json kirocrew:/home/kirocrew/.kiro/crew/config.json
docker exec -u 0 kirocrew chown kirocrew:kirocrew /home/kirocrew/.kiro/crew/config.json
docker restart kirocrew

สำหรับการเข้าถึงจากโทรศัพท์ โปรเจกต์นี้แนะนำ tailscale serve ของ Tailscale ซึ่งทำให้ dashboard อยู่ภายใน tailnet ของคุณเอง แทนที่จะใช้ hostname สาธารณะ ควรเลือกวิธีนี้แทน reverse proxy สาธารณะ token จะถูกส่งไปใน URL และ URL จะถูกบันทึกใน access log ทุกจุดที่เกี่ยวข้องกับเส้นทางนั้น หลักการนี้พิจารณาจากสิ่งที่อยู่หลังพอร์ต ไม่ใช่พอร์ตเอง ตัวอย่างเช่น Halcyon ซึ่งสร้างไลบรารี Jellyfin ใหม่ให้เป็นวิดีโอสโตร์ยุค 90 ที่เปิดดูได้ เป็นบริการที่ให้บุคคลอื่นเข้าถึงได้ และเหมาะสมที่จะใช้ reverse proxy ส่วน gateway ที่สามารถรันคำสั่งบนเซิร์ฟเวอร์ของคุณได้นั้นไม่เหมาะกับวิธีนี้

จำกัดขอบเขตความเสียหายของ agent ให้เหลือน้อยที่สุด

Container จะตรวจสอบการรองรับ sandbox ในการเริ่มทำงานครั้งแรก และผลลัพธ์จะเป็นตัวตัดสินว่า agent สามารถประมวลผลคำสั่งใดๆ ได้หรือไม่ หากมี namespace isolation พร้อมใช้งาน กระบวนการย่อยของ agent จะทำงานภายใต้การแยกส่วน หากไม่พร้อมใช้งานและไม่ได้ตั้งค่า KIROCREW_ALLOW_UNSANDBOXED=1 ไว้ ระบบจะปฏิเสธการประมวลผลแทนที่จะปล่อยให้ทำงานโดยไม่มีการควบคุม ดังนั้นหากพบว่า gateway ดูเหมือนทำงานปกติแต่ทุก task กลับหยุดชะงัก มักเกิดจากสาเหตุนี้ การตัดสินใจดังกล่าวจะถูกบันทึกไว้ใน docker logs kirocrew ตั้งแต่การรันครั้งแรก โครงการยังได้เผยแพร่โปรไฟล์ seccomp (secure computing mode) ที่คุณสามารถนำไปปรับใช้ได้:

curl -fsSL https://raw.githubusercontent.com/kirodotdev/KiroCrew/main/docker/seccomp/kirocrew-seccomp.json \
  -o /opt/kirocrew/kirocrew-seccomp.json
    security_opt:
      - seccomp:./kirocrew-seccomp.json

หากคุณตั้งค่า KIROCREW_ALLOW_UNSANDBOXED=1 โปรดตระหนักถึงสิ่งที่เปลี่ยนแปลงไป: ขณะนี้ container เป็นเพียงขอบเขตเดียวที่กั้นระหว่าง agent กับเซิร์ฟเวอร์ของคุณ คำเตือนของโครงการควรได้รับการย้ำเตือนอย่างครบถ้วน ห้าม mount path ของ host ที่คุณจะไม่ส่งมอบให้ agent โดยตรง ในทางปฏิบัติหมายความว่าห้ามใช้ Docker socket, ห้าม bind mount / และห้าม mount ไดเรกทอรีใดๆ ที่เก็บข้อมูลของบริการอื่น

ส่วนที่เหลือคือกรอบการทำงานที่ใช้กับทุก agent ที่ได้รับอนุญาตให้รันคำสั่ง จำกัดสิทธิ์ credential ของ agent ให้เข้าถึงได้เฉพาะ repository หรือ bucket ที่จำเป็นเท่านั้น ห้ามใช้ personal token ที่มีสิทธิ์ครอบคลุมทั้งบัญชี ให้รัน agent ด้วยผู้ใช้เฉพาะที่ไม่มีข้อมูลอื่นอยู่ใน home directory ซึ่งเป็นแนวทางเดียวกับ ผู้ใช้ที่มีสิทธิ์น้อยที่สุดบน VPS เมื่อ agent เขียนโค้ดและรันโค้ดนั้น ให้ใช้เครื่องที่ยอมรับได้หากเกิดความเสียหาย: VM แบบใช้แล้วทิ้งสำหรับ coding agent เป็นขอบเขตที่แข็งแกร่งกว่า flag ใดๆ ใน compose file นี้ เพราะคุณสามารถลบทิ้งได้แทนที่จะต้องมาทำความสะอาด แนวคิดเดียวกันนี้ยังใช้กับการ รัน OpenClaw อย่างปลอดภัยบน VPS และ การ self-host Hermes agent บน VPS เครื่องมือต่างๆ ก็นับเป็นขอบเขตความเสียหายเช่นกัน การอนุญาตให้ agent ค้นหาเว็บได้จะทำให้ทุกหน้าที่มันดึงข้อมูลมากลายเป็น input ที่ไม่น่าเชื่อถือ ดังนั้น การชี้ไปที่ SearXNG instance ของคุณเอง จึงเป็นการตัดสินใจด้าน prompt injection พอๆ กับการจัดการระบบ งานที่ตั้งเวลาไว้ยังอาจทำให้เสียค่าใช้จ่ายในขณะที่คุณหลับ เนื่องจากค่า inference จะถูกเรียกเก็บตามแผน Kiro ของคุณ ดังนั้นควรตั้งค่าขีดจำกัดตามที่อธิบายไว้ใน การควบคุมค่าใช้จ่ายของ AI agent บน VPS ก่อนที่คุณจะเพิ่มงานที่ต้องรันในตอนกลางคืน

สำรองข้อมูล volume ของสถานะก่อนการอัปเกรดทุกครั้ง

ค้นหาชื่อ volume ที่แท้จริงก่อน โดย Compose จะตั้งชื่อ prefix ของ volume ตามชื่อโปรเจกต์ ซึ่งค่าเริ่มต้นคือชื่อไดเรกทอรี ดังนั้น volume ที่ประกาศไว้เป็น kirocrew-home ใน /opt/kirocrew/compose.yaml จะถูกสร้างขึ้นในชื่อ kirocrew_kirocrew-home:

docker volume ls

หยุดการทำงานของ gateway ก่อนที่จะคัดลอกข้อมูลใดๆ memory.db และ memory_index.db เป็นฐานข้อมูล SQLite การคัดลอกฐานข้อมูลในขณะที่มีการเขียนข้อมูลอยู่อาจทำให้ได้ธุรกรรมที่เขียนไม่สมบูรณ์ ซึ่งเมื่อนำไปกู้คืนจะกลายเป็นไฟล์ที่เสียหาย คำแนะนำในการย้ายข้อมูลของโปรเจกต์เองก็ได้ระบุไว้เช่นกันว่า ให้ย้ายข้อมูลในหน่วยความจำเฉพาะในขณะที่ gateway หยุดทำงานเท่านั้น กฎการหยุดทำงานก่อนนี้ไม่ได้จำกัดอยู่แค่ KiroCrew และหากมีเซิร์ฟเวอร์รูปภาพใช้งานอยู่บนเครื่องเดียวกัน การเปรียบเทียบระหว่าง PhotoPrism และ Immich จะระบุคำสั่งสำรองข้อมูลที่จำเป็นสำหรับทั้งสองบริการไว้อย่างชัดเจน

sudo systemctl stop kirocrew
docker run --rm -v kirocrew_kirocrew-home:/data:ro -v "$PWD":/backup \
  alpine tar czf /backup/kirocrew-2026-08-06.tgz -C /data .
sudo systemctl start kirocrew

คัดลอกไฟล์เก็บถาวรออกจากเครื่อง การกู้คืนข้อมูลใช้คำสั่งเดียวกันโดยต้องหยุด container และใช้ tar xzf แทนที่ tar czf:

sudo systemctl stop kirocrew
docker run --rm -v kirocrew_kirocrew-home:/data -v "$PWD":/backup \
  alpine tar xzf /backup/kirocrew-2026-08-06.tgz -C /data
sudo systemctl start kirocrew

การย้ายไปยังโฮสต์ใหม่เป็นงานที่แตกต่างจากการกู้คืนในที่เดิม และทางโปรเจกต์ได้ระบุรายละเอียดไว้ชัดเจน ประวัติการแชทและบันทึกของโปรเจกต์ภายใต้ workspace/memory/ จะถูกย้ายไปด้วย รวมถึงไฟล์ฐานข้อมูลทั้งสองไฟล์และ config.json ส่วนไฟล์ PID, บันทึกเหตุการณ์ความปลอดภัย และ .env นั้นผูกติดอยู่กับโฮสต์เดิม จึงควรทิ้งไว้ที่เดิมและป้อนข้อมูลลับใหม่อีกครั้งบนเครื่องใหม่

วิธีการย้อนกลับเมื่อการอัปเกรดล้มเหลว

การอัปเกรดนั้นใช้เวลาสั้นและปลอดภัยได้ก็ต่อเมื่อคุณระบุเวอร์ชันไว้ (pinned) ให้สำรองข้อมูลก่อนเสมอ จากนั้นจึงเปลี่ยน tag:

sudo systemctl stop kirocrew
# take the backup here, as above
sudo nano /opt/kirocrew/compose.yaml   # set the new image tag
sudo systemctl start kirocrew
docker compose -f /opt/kirocrew/compose.yaml ps
curl -s http://127.0.0.1:5476/api/health

docker compose up -d จะดึง image มาหากยังไม่มีอยู่ในเครื่อง ดังนั้นการแก้ไข tag จึงเป็นขั้นตอนทั้งหมดของการอัปเกรด การย้อนกลับทำได้ด้วยลำดับขั้นตอนเดียวกันโดยใช้หมายเลขเวอร์ชันเดิม ซึ่งจะทำให้คุณได้ image เดิมที่เคยใช้งานเป๊ะๆ เนื่องจาก version tag นั้นไม่สามารถเปลี่ยนแปลงได้ (immutable)

ตัว binary สามารถย้อนกลับได้อย่างหมดจด แต่ส่วนของ state อาจไม่เป็นเช่นนั้น gateway เวอร์ชันใหม่กว่าอาจเขียนทับ config.json หรือย้ายข้อมูลใน memory database ไปเป็นรูปแบบที่ gateway เวอร์ชันเก่าอ่านไม่ได้ และยังไม่มีการระบุขั้นตอนการ downgrade ไว้ ณ เดือนสิงหาคม 2026 ดังนั้นหาก image เวอร์ชันเก่าเริ่มทำงานแล้วมีพฤติกรรมผิดปกติ อย่าพยายามแก้ไข (debug) ให้หยุดการทำงาน กู้คืนข้อมูลสำรองที่คุณทำไว้ก่อนการอัปเกรด แล้วเริ่มใหม่อีกครั้ง นี่คือเหตุผลทั้งหมดว่าทำไมต้องสำรองข้อมูลก่อน และเป็นเหตุผลว่าทำไมการอัปเกรดก่อนแล้วค่อยสำรองข้อมูลทีหลังจึงเป็นวิธีที่ใช้ไม่ได้ผลกับโปรเจกต์ที่ยังใหม่อยู่เช่นนี้

สิ่งที่ยังไม่ได้ผ่านการพิสูจน์ในที่นี้

โปรดพิจารณาอายุของซอฟต์แวร์นี้ตามความเป็นจริง เวอร์ชัน 0.1.3 เพิ่งเปิดตัวได้เพียงไม่กี่วัน ณ เวลาที่เขียนบทความนี้ บันทึกการเปลี่ยนแปลง (release notes) เป็นเพียงลิงก์ changelog ที่สร้างขึ้นโดยอัตโนมัติ ไม่ใช่บันทึกสำหรับการย้ายเวอร์ชัน (migration notes) และยังไม่มีประวัติการอัปเกรดให้เห็น สิ่งที่ระบุในคู่มือนี้ไม่ใช่ผลลัพธ์จากการใช้งานระยะยาว ดังนั้นให้ถือว่าการใช้หน่วยความจำ ขนาดของฐานข้อมูล และความน่าเชื่อถือของตัวจัดตารางเวลา (scheduler) เป็นสิ่งที่ต้องวัดผลด้วยตนเองบนเซิร์ฟเวอร์ของคุณ แทนที่จะคาดเดาเอาเอง

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

FAQ

ทำไมแดชบอร์ด KiroCrew ถึงไม่เปิดขึ้นมาบน Public IP ของเซิร์ฟเวอร์?

เพราะตัวอย่างที่เผยแพร่ได้กำหนดให้พอร์ตผูกกับ loopback เท่านั้น -p 127.0.0.1:5476:5476 จะแมปพอร์ตของคอนเทนเนอร์เข้ากับที่อยู่ loopback ของโฮสต์โดยเจตนา คุณสามารถเข้าถึงได้โดยการทำ port forwarding ผ่าน SSH ด้วยคำสั่ง ssh -N -L 5476:127.0.0.1:5476 you@your-server จากนั้นเปิด http://localhost:5476/?token=<token> บนแล็ปท็อปของคุณ การลบ prefix 127.0.0.1: ออกเพื่อให้เข้าถึงได้จากภายนอกจะทำให้เกตเวย์เปิดรับการเชื่อมต่อจากอินเทอร์เน็ตสาธารณะ และกฎของไฟร์วอลล์จะไม่สามารถจำกัดการเข้าถึงได้ เนื่องจากกฎ DNAT ของพอร์ตที่เผยแพร่โดย Docker จะถูกประเมินก่อนที่ ufw จะกรองทราฟฟิก

KiroCrew เก็บข้อมูลไว้ที่ไหน และควรสำรองข้อมูลอะไรบ้าง?

ข้อมูลทั้งหมดจะอยู่ใน ~/.kiro/crew ซึ่งภายในอิมเมจคอนเทนเนอร์คือ /home/kirocrew/.kiro/crew และคุณสามารถใช้ KIROCREW_HOME เพื่อย้ายตำแหน่งได้ ให้สำรองข้อมูลทั้งไดเรกทอรีหรือทั้ง Docker volume ในขณะที่หยุดการทำงานของเกตเวย์ไว้ memory.db และ memory_index.db เป็นฐานข้อมูล SQLite ดังนั้นการคัดลอกในขณะที่เกตเวย์กำลังเขียนข้อมูลอาจทำให้ข้อมูลไม่สอดคล้องกัน เมื่อย้ายไปยังโฮสต์ใหม่ ให้คัดลอก workspace/memory/, ไฟล์ฐานข้อมูลทั้งสองไฟล์ และ config.json ไปด้วย ส่วนไฟล์ PID, บันทึกเหตุการณ์ความปลอดภัย และ .env เป็นข้อมูลที่ผูกกับโฮสต์เดิม

ควรใช้แท็ก stable หรือแท็กเวอร์ชัน?

ควรใช้แท็กเวอร์ชัน แท็ก stable จะเปลี่ยนไปทุกครั้งที่มีการปล่อยซอฟต์แวร์รุ่นใหม่ ดังนั้นเวอร์ชันที่คุณใช้งานอาจเปลี่ยนไปโดยไม่รู้ตัวในการดึงอิมเมจครั้งถัดไป และตัวแท็กเองก็ไม่ได้ระบุข้อมูลว่าคุณกำลังรันเวอร์ชันใดอยู่ แท็กเวอร์ชันเช่น 0.1.3 เป็นแบบ immutable ซึ่งเป็นสิ่งที่ทำให้การย้อนกลับ (rollback) ทำงานได้จริง: คุณเพียงแค่ใส่หมายเลขเวอร์ชันเก่ากลับเข้าไปและจะได้อิมเมจเดิมที่เหมือนกับที่เคยใช้ ณ วันที่ 6 สิงหาคม 2026 รุ่นล่าสุดคือ 0.1.3

ทำไมเอเจนต์ของฉันถึงปฏิเสธที่จะรันคำสั่งใดๆ?

คอนเทนเนอร์จะตรวจสอบการรองรับ sandbox ในการเริ่มทำงานครั้งแรก หากไม่สามารถแยก subprocess ของเอเจนต์ได้และไม่ได้ตั้งค่า KIROCREW_ALLOW_UNSANDBOXED=1 ไว้ มันจะปฏิเสธการรันคำสั่งแทนที่จะรันโดยไม่มีการจำกัดสิทธิ์ ทำให้เกตเวย์ดูเหมือนทำงานปกติแต่ทุกงานกลับหยุดชะงัก docker logs kirocrew จะแสดงผลการตัดสินใจเรื่อง sandbox จากการรันครั้งแรกนั้น การตั้งค่าตัวแปรดังกล่าวจะทำให้คอนเทนเนอร์เป็นขอบเขตเดียวที่กั้นระหว่างเอเจนต์กับโฮสต์ ดังนั้นหากคุณตั้งค่านี้ ห้าม mount สิ่งใดที่คุณไม่ต้องการให้เอเจนต์เข้าถึงโดยตรง

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

จำเป็น ณ เดือนสิงหาคม 2026 KiroCrew เป็นซอฟต์แวร์เสรีภายใต้สัญญาอนุญาต Apache 2.0 แต่ตัวซอฟต์แวร์ทำงานร่วมกับ kiro-cli ซึ่งต้องมีการลงชื่อเข้าใช้ครั้งเดียว และการประมวลผล inference ของเอเจนต์จะถูกเรียกเก็บเงินตามแผนของ Kiro ภายในคอนเทนเนอร์ ให้รัน docker exec -it kirocrew kiro-cli login และยืนยันรหัสอุปกรณ์ในเบราว์เซอร์ของคุณ จนกว่าการลงชื่อเข้าใช้จะเสร็จสมบูรณ์ เกตเวย์จะเริ่มทำงานและแดชบอร์ดจะโหลดขึ้นมา แต่เอเจนต์จะไม่มีโมเดลสำหรับติดต่อสื่อสารด้วย

#kirocrew#ai-agents#docker#systemd#self-hosting