SSD Nodes Learn 🎉 VPS เริ่ม $5.50/เดือน
คู่มือ Matt Connorโดย Matt Connor · อัปเดตเมื่อ 2026-08-13

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

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

เหตุใดจึงควร self-host KiroCrew บน VPS แทนแล็ปท็อป

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

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

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

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

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

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

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

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 ไปวางไว้บนโฮสต์เดียวกับที่รันบริการอื่นๆ ของคุณ ดังนั้นหากการอัปเกรดเกิดข้อผิดพลาด คุณจะต้องมาคอยไล่แก้ไขด้วยตนเอง แต่คอนเทนเนอร์จะเก็บรันไทม์ไว้ในอิมเมจเดียวและเก็บสถานะไว้ในวอลลุ่มเดียว ซึ่งทำให้การย้อนกลับเวอร์ชัน (rollback) ทำได้เพียงแค่เปลี่ยนแท็กและรีสตาร์ทเท่านั้น

ตรึงอิมเมจไว้ที่แท็กของรุ่น (release tag) แทนที่จะใช้ stable

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

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

stable เป็นแท็กที่มีการเปลี่ยนแปลงตลอดเวลา (moving tag) มันจะชี้ไปยังรุ่นเสถียรล่าสุดเสมอ ดังนั้นการดึงอิมเมจครั้งถัดไปอาจเปลี่ยนเวอร์ชันที่คุณใช้งานอยู่โดยที่คุณไม่ได้เลือก และแท็กนี้ไม่ได้บันทึกข้อมูลใดๆ ว่าเวอร์ชันนั้นคืออะไร แท็กเวอร์ชันมีความคงที่ (immutable) ดังนั้นควรตรึงไว้ที่เวอร์ชันใดเวอร์ชันหนึ่ง รุ่นล่าสุด ณ วันที่ 6 สิงหาคม 2026 คือ 0.1.3 ซึ่งเผยแพร่เมื่อวันที่ 5 สิงหาคม 2026 นอกจากนี้ยังมีแท็ก 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 กำลังทำงานอยู่ ไม่ใช่ติดตามกระบวนการที่ทำงานอยู่เบื้องหน้า หากคุณเขียน Type=simple แทน systemd จะเห็นว่าคำสั่งจบการทำงานทันที และทำเครื่องหมายว่า service นั้นตายแล้ว จากนั้นจะยอมแพ้หรือวนลูปการรีสตาร์ทขึ้นอยู่กับการตั้งค่า Restart= ของคุณ สำหรับการติดตั้งแบบ native ตัวโปรเจกต์จะมีไฟล์เทียบเท่ามาให้คือ kirocrew service install ซึ่งจะเขียน /etc/systemd/system/kirocrew.service และรัน gateway ในฐานะผู้ใช้ของคุณ ห้ามรันทั้งสอง unit พร้อมกัน เนื้อหาที่ครอบคลุมหัวข้อนี้ในวงกว้างอยู่ใน systemd services และ timers บน VPS

การรันครั้งแรก: ลงชื่อเข้าใช้และรับ 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> โทเค็นมีวันหมดอายุ โดยเซสชันจะมีค่าเริ่มต้นที่หนึ่งชั่วโมงและกำหนดไว้สูงสุดที่ยี่สิบชั่วโมง หาก dashboard โหลดขึ้นมาเป็นหน้าว่างหรือเด้งกลับออกไปทันที มักเกิดจากโทเค็นหมดอายุ ให้สร้างโทเค็นใหม่ ห้ามคัดลอกโทเค็นไปวางใน ticket หรือข้อความแชทเด็ดขาด เพราะผู้ที่ถือโทเค็นนี้จะสามารถเข้าถึง agent ของคุณได้ทันที

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

ให้พิจารณาค่า bind address ในตัวอย่างของโปรเจกต์อีกครั้งที่ -p 127.0.0.1:5476:5476 ภายในคอนเทนเนอร์ เกตเวย์จะฟังที่ 0.0.0.0 เนื่องจากต้องเข้าถึงได้ผ่านการทำ port 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=...

พฤติกรรมหนึ่งที่ระบุไว้ในเอกสารซึ่งควรทราบเมื่อใช้งานผ่านอุโมงค์ (tunnel) คือ เกตเวย์จะอ่านคำขอที่ถูก 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 ซึ่งจะเก็บแดชบอร์ดไว้ภายใน tailnet ของคุณเองแทนที่จะใช้ชื่อโฮสต์สาธารณะ ควรเลือกวิธีนี้แทนการใช้ reverse proxy สาธารณะ เนื่องจากโทเค็นจะถูกส่งไปใน URL และ URL จะถูกบันทึกลงใน access log ทุกจุดที่ผ่านไป

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

คอนเทนเนอร์จะตรวจสอบการรองรับ sandbox ในการเริ่มทำงานครั้งแรก และผลลัพธ์จะเป็นตัวตัดสินว่า agent สามารถประมวลผลคำสั่งใดๆ ได้หรือไม่ หากมี namespace isolation พร้อมใช้งาน กระบวนการย่อยของ agent จะทำงานภายใต้การแยกส่วน หากไม่มีและไม่ได้ตั้งค่า KIROCREW_ALLOW_UNSANDBOXED=1 ระบบจะปฏิเสธการประมวลผลแทนที่จะปล่อยให้ทำงานโดยไม่มีการควบคุม ดังนั้นหาก gateway ดูเหมือนทำงานปกติแต่ทุกงานหยุดชะงัก มักเกิดจากสาเหตุนี้ การตัดสินใจดังกล่าวจะถูกบันทึกไว้ใน 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 โปรดตระหนักถึงสิ่งที่เปลี่ยนแปลง: คอนเทนเนอร์จะเป็นเพียงขอบเขตเดียวที่กั้นระหว่าง agent กับเซิร์ฟเวอร์ของคุณ คำเตือนของโครงการควรได้รับการย้ำเตือนอย่างครบถ้วน ห้าม mount path ของโฮสต์ที่คุณจะไม่ส่งมอบให้ agent โดยตรง ในทางปฏิบัติหมายถึงห้ามใช้ Docker socket, ห้าม bind mount / และห้าม mount ไดเรกทอรีที่เก็บข้อมูลของบริการอื่น

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

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

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

docker volume ls

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

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 นั้นผูกติดอยู่กับโฮสต์เดิม จึงควรทิ้งไฟล์เหล่านี้ไว้และป้อนข้อมูลลับ (secrets) ใหม่อีกครั้งบนเครื่องใหม่

วิธีการย้อนกลับการอัปเกรดที่ผิดพลาด

การอัปเกรดใช้เวลาสั้นและมีความปลอดภัยก็ต่อเมื่อคุณได้ระบุเวอร์ชันไว้ (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 เวอร์ชันเก่าอ่านไม่ได้ และยังไม่มีการระบุเส้นทางการดาวน์เกรดไว้ ณ เดือนสิงหาคม 2026 ดังนั้นหาก image เวอร์ชันเก่าเริ่มทำงานแล้วมีพฤติกรรมผิดปกติ อย่าพยายามแก้ไข (debug) ให้หยุดการทำงาน กู้คืนข้อมูลสำรองที่คุณทำไว้ก่อนการอัปเกรด แล้วเริ่มใหม่อีกครั้ง นี่คือเหตุผลทั้งหมดว่าทำไมต้องสำรองข้อมูลก่อน และเป็นสาเหตุที่นิสัยการอัปเกรดก่อนแล้วค่อยสำรองข้อมูลทีหลังมักจะล้มเหลวในโปรเจกต์ที่ยังใหม่เช่นนี้

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

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

มีพฤติกรรมสองประการที่ควรทดสอบด้วยตนเองก่อนที่จะนำไปใช้งานจริง ประการแรก คือการตรวจสอบว่าการทำ downgrade จะสามารถอ่านสถานะที่เขียนโดยเวอร์ชันใหม่กว่าได้หรือไม่ ให้ทดสอบกับสำเนาของ 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 เป็นสิ่งที่แก้ไขไม่ได้ ซึ่งเป็นหัวใจสำคัญที่ทำให้การย้อนกลับ (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 ซึ่งต้องมีการลงชื่อเข้าใช้หนึ่งครั้ง และการประมวลผลของเอเจนต์จะถูกเรียกเก็บเงินตามแผนการใช้งานของ Kiro ภายในคอนเทนเนอร์ ให้รันคำสั่ง docker exec -it kirocrew kiro-cli login และยืนยันรหัสอุปกรณ์ผ่านเบราว์เซอร์ของคุณ จนกว่าการลงชื่อเข้าใช้จะเสร็จสมบูรณ์ เกตเวย์จะเริ่มทำงานและแดชบอร์ดจะโหลดขึ้นมา แต่เอเจนต์จะไม่มีโมเดลสำหรับติดต่อสื่อสารด้วย

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