วิธีติดตั้ง open-kritt บน VPS ด้วย Docker Compose

เหตุผลที่ควรโฮสต์ open-kritt บน VPS แทนที่จะเป็นแล็ปท็อปส่วนตัว

จงโฮสต์ open-kritt บนเซิร์ฟเวอร์ที่คุณสามารถทำลายและสร้างใหม่ได้ตลอดเวลา เครื่องมือนี้จะรัน agent สำหรับวิเคราะห์ในฐานะ root ภายในคอนเทนเนอร์งานที่สร้างขึ้นชั่วคราว โดยให้สิทธิ์ในการเขียนสำเนาโค้ดของคุณและเข้าถึงอินเทอร์เน็ตได้โดยตรง อีกทั้งยัง mount Docker socket ของโฮสต์เข้าไปใน engine service ของมันด้วย นี่เป็นข้อแลกเปลี่ยนที่ยอมรับได้สำหรับเครื่องที่อุทิศให้กับการทำงานนี้โดยเฉพาะ แต่เป็นทางเลือกที่แย่มากสำหรับเครื่องที่เก็บ SSH keys ของคุณไว้

คุณสมบัติ 4 ประการของการตั้งค่าเริ่มต้นนำไปสู่คำแนะนำนี้ ซึ่งทั้งหมดมาจาก README และไฟล์ compose ของโปรเจกต์เอง

ตัว agent ถูกออกแบบมาให้มีอำนาจสูง README ระบุว่า agent ที่เปิดใช้งานเครื่องมือจะรันในฐานะ root ภายในคอนเทนเนอร์งานที่สร้างขึ้นชั่วคราว พร้อมสิทธิ์ในการเขียนสำเนา repository และเข้าถึงอินเทอร์เน็ตได้โดยตรง เพื่อให้สามารถติดตั้งเครื่องมือ คอมไพล์เป้าหมาย รันการทดสอบ และสร้าง proof of concept ได้ การสแกนไม่ใช่แค่การใช้ linter อ่านไฟล์ แต่เป็นการรันโค้ดตามอำเภอใจที่คุณเป็นผู้ร้องขอ การเข้าถึงอินเทอร์เน็ตนั้นเป็นดาบสองคม: สิ่งใดก็ตามที่ agent ดึงมาในระหว่างการค้นคว้าเป้าหมายถือเป็นข้อความที่ไม่น่าเชื่อถือซึ่งถูกส่งเข้ามาใน prompt ของมัน ซึ่งเป็นความเสี่ยงเดียวกับที่คุณต้องเผชิญเมื่อคุณ อนุญาตให้ agent ค้นหาข้อมูลบนเว็บด้วยตัวเอง

ตัว engine ถือครอง Docker socket docker-compose.yml ทำการ mount Docker socket ของโฮสต์เข้าไปใน engine service เนื่องจาก engine จะสร้างและเปิดใช้งานคอนเทนเนอร์สำหรับการสแกนหนึ่งตัวต่อหนึ่งงาน กระบวนการใดก็ตามที่สามารถเข้าถึง socket นั้นได้ จะสามารถเริ่มคอนเทนเนอร์ที่ mount ระบบไฟล์ของโฮสต์ได้ ดังนั้น engine จึงมีสถานะเทียบเท่า root บนโฮสต์ที่รันมันอยู่

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

โค้ดที่คุณสแกนมักไม่ใช่ของคุณ การชี้ agent ไปยัง repository ของบุคคลที่สาม หมายถึงการรัน build ของ repository นั้นบนเครื่องของคุณ ในฐานะ root และมีการเข้าถึงเครือข่าย

หากคุณได้อ่าน เหตุผลที่ coding agents ควรอยู่ใน VM ที่ทิ้งได้ นี่คือ threat model เดียวกัน แต่มีความรุนแรงกว่า ให้ใช้ VPS ที่ไม่มีข้อมูลอื่นอยู่เลยสำหรับ open-kritt และควบคุม VPS นั้นจาก บัญชีผู้ใช้ที่มีสิทธิ์จำกัด แทนการใช้ root

การทำงานจริงของ open-kritt

open-kritt (repository อยู่ที่ Kritt-ai/open-kritt ภายใต้สัญญาอนุญาต AGPL-3.0) จะแบ่งงานวิจัยช่องโหว่ออกเป็นงานย่อยๆ แล้วรันงานเหล่านั้นผ่าน AI agents แบบขนาน จากนั้นจึงทำการลบข้อมูลซ้ำและจัดลำดับผลลัพธ์ที่ได้ คุณสามารถกำหนด workflow เป็นชุดของ prompt ที่เน้นเฉพาะจุด โดยแต่ละขั้นตอนจะได้รับบริบทที่มีโครงสร้างมาจากขั้นตอนก่อนหน้า เป้าหมายของการสแกนคือ git repository ทั้งแบบ local หรือ remote ส่วน engine ที่ใช้ในการวิเคราะห์คือ Codex หรือ Claude Code หลังจากพบผู้สมัคร (candidate) ที่น่าสนใจแล้ว คุณสามารถใช้ post-scripts เพื่อตรวจสอบความถูกต้องหรือสร้าง proof of concept เพิ่มเติมได้

ผลลัพธ์ที่คุณได้รับคือรายการผู้สมัครที่ถูกจัดลำดับไว้แล้ว ให้ถือว่าสิ่งนี้เป็นคิวสำหรับการคัดกรอง (triage queue) ไม่ใช่รายงานสรุปผลฉบับสมบูรณ์

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

• VPS ที่รัน Ubuntu 24.04, Debian 12 หรือ Rocky Linux 9 เอกสารการติดตั้งระบุว่าระบบปฏิบัติการเหล่านี้ผ่านการทดสอบแล้ว ทั้งบนสถาปัตยกรรม x86_64 และ ARM64
• Docker Engine พร้อมปลั๊กอิน Compose
• Node.js 20 หรือใหม่กว่าบนโฮสต์ เนื่องจาก ./kritt CLI ทำงานบนโฮสต์โดยตรงแทนที่จะทำงานภายในคอนเทนเนอร์
• ผู้ให้บริการโมเดลหนึ่งราย: บัญชีผู้ใช้ Codex หรือ OPENAI_API_KEY, CODEX_API_KEY, ANTHROPIC_API_KEY หรือ OPENROUTER_API_KEY
• GITHUB_TOKEN จะใช้ก็ต่อเมื่อคุณวางแผนที่จะสแกน repository ส่วนตัวเท่านั้น .env.example ที่มาพร้อมกับซอฟต์แวร์ระบุไว้อย่างชัดเจนว่า: การใช้ GitHub token เพียงอย่างเดียวไม่สามารถรันการสแกนได้

ติดตั้ง Docker และ Node 20 ก่อน

curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker $USER

ให้ log out และ log in เข้าสู่ระบบใหม่อีกครั้งเพื่อให้การเพิ่มกลุ่มผู้ใช้มีผล จากนั้นตรวจสอบว่ามี Compose plugin อยู่หรือไม่

docker compose version

หากแสดงเวอร์ชันเป็นสตริง แสดงว่า Compose ถูกติดตั้งในรูปแบบ plugin แล้ว หากแสดงเป็น docker: 'compose' is not a docker command หมายความว่าคุณยังใช้ไฟล์ binary แบบ standalone รุ่นเก่าอย่าง docker-compose อยู่ ซึ่ง open-kritt จะเรียกใช้ docker compose การเป็นสมาชิกของกลุ่ม docker มีสิทธิ์เทียบเท่ากับ root บนโฮสต์ ดังนั้นให้เพิ่มเฉพาะบัญชีผู้ใช้ที่รัน open-kritt เข้าไปในกลุ่มนี้เท่านั้น สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับการตั้งค่านี้ โปรดดูที่ การรัน Docker บน VPS

Ubuntu 24.04 มี Node 18 มาให้ใน repository ของระบบ แต่ CLI จะหยุดทำงานหากเวอร์ชันต่ำกว่า 20 ให้ใช้ NodeSource แทน

curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt install -y nodejs
node -v

node -v ต้องแสดงผลเป็น v20. หรือสูงกว่า สำหรับ Rocky Linux 9 ให้ใช้คำสั่ง sudo dnf module enable nodejs:20 -y ตามด้วย sudo dnf install -y nodejs

โคลน open-kritt และตรึงเวอร์ชันที่ระบุด้วย tag

git clone https://github.com/Kritt-ai/open-kritt
cd open-kritt
git fetch --tags
git tag --list
git checkout v1.3.0

main จะเลื่อนไปตามคุณ แต่ tag จะไม่เลื่อนตาม ณ เดือนสิงหาคม 2026 tag ล่าสุดคือ v1.3.0 ซึ่งเผยแพร่เมื่อวันที่ 4 สิงหาคม 2026 และ git tag --list จะแสดงสิ่งที่อยู่ใน repository ณ วันที่คุณทำการโคลน การ checkout tag จะทำให้ repository อยู่ในสถานะ detached HEAD ซึ่งถูกต้องแล้วในกรณีนี้: คุณกำลังจัดการการโคลนนี้ในฐานะการติดตั้งแบบตรึงเวอร์ชัน (pinned deployment) ไม่ใช่ branch สำหรับการ commit หากต้องการอัปเกรดในภายหลัง ให้อ่านบันทึกประจำรุ่น (release notes) จากนั้นรัน git fetch --tags, checkout tag ใหม่ แล้วรัน ./kritt start อีกครั้ง เนื่องจาก start จะทำการสร้าง image ใหม่

ห้ามรัน ./kritt ร่วมกับ sudo เอกสารระบุเรื่องนี้ไว้อย่างชัดเจน CLI จะจัดการไดเรกทอรีข้อมูลรับรอง (credential directories) ภายในโปรเจกต์ภายใต้ .data/ ดังนั้นหากรันด้วยสิทธิ์ root ไดเรกทอรีเหล่านั้นจะมี root เป็นเจ้าของ และการรันด้วยผู้ใช้ปกติในครั้งถัดไปจะไม่สามารถเขียนข้อมูลลงไปได้

กำหนดค่าการเข้าถึงโมเดลด้วย ./kritt setup

./kritt setup

คำสั่งนี้จะสร้าง .env จาก .env.example ในกรณีที่ไฟล์ยังไม่มีอยู่จริง พร้อมทั้งแสดงสถานะของ credential แต่ละรายการ และอนุญาตให้คุณกำหนดหรือยกเลิกค่าเหล่านั้นได้ โดยคำสั่งจะไม่แสดงค่าของ credential กลับมาที่เทอร์มินัล ทั้ง .env และไฟล์ credential ของ engine จะถูกเขียนด้วยโหมด 0600

หากคุณต้องการดำเนินการด้วยตนเอง:

cp .env.example .env
chmod 600 .env
mkdir -p .data/codex
chmod 700 .data/codex

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

กำหนดเพดานการใช้จ่ายของผู้ให้บริการก่อนการสแกนครั้งแรก

open-kritt ถูกออกแบบมาให้ทำงานแบบกระจายงาน (fan-out) ซึ่งค่าใช้จ่ายจะเกิดขึ้นตามปริมาณงานที่กระจายออกไป ค่าเริ่มต้นใน .env.example ที่เวอร์ชัน v1.3.0 นั้นถูกตั้งไว้แบบระมัดระวัง ได้แก่ ENGINE_WORKER_COUNT=2 ซึ่งระบุไว้ในไฟล์ว่าเป็นค่าเริ่มต้นที่เหมาะสมสำหรับเครื่องขนาด 2-vCPU และ ENGINE_MAX_CONCURRENT_SCANS=1 เหนือค่าเหล่านั้นคือ ENGINE_WORKERS_PER_ACCOUNT=15 ซึ่งเป็นจำนวนสูงสุดของการเรียกใช้โมเดลระดับ root พร้อมกันที่อนุญาตต่อหนึ่งบัญชีผู้ให้บริการ และ ENGINE_CODEX_MAX_SUBAGENTS_PER_SESSION=5 เนื่องจากเซสชันของ Codex อาจรัน child agent ได้สูงสุดถึงห้าตัว หากคุณเพิ่มจำนวน worker บน VPS ที่มีขนาดใหญ่ขึ้น จำนวนการเรียกใช้โมเดลที่ทำงานอยู่พร้อมกันก็จะเพิ่มขึ้นตามไปด้วย

ไม่มีสิ่งใดใน repository ที่จะจำกัดค่าใช้จ่ายของคุณ ไม่มีการตั้งค่า budget ใน .env.example เงื่อนไขการหยุดทำงานของ engine เองนั้นขึ้นอยู่กับขีดจำกัดของ worker เหล่านั้นรวมถึง ENGINE_HARNESS_TIMEOUT_SECONDS ซึ่งมีค่าเริ่มต้นที่ 7200 วินาทีต่อการรัน harness หนึ่งครั้ง ดังนั้นเพดานการใช้จ่ายจึงต้องถูกกำหนดไว้ที่ฝั่งผู้ให้บริการ ให้คุณเปิดคอนโซลของผู้ให้บริการและกำหนดวงเงินรายเดือนแบบ hard limit ก่อนที่จะเริ่มการสแกนครั้งแรก ไม่ใช่หลังจากนั้น การควบคุมค่าใช้จ่ายของ AI agent บน VPS จะอธิบายขั้นตอนการตั้งค่าสำหรับผู้ให้บริการแต่ละราย

นอกจากนี้ยังมีระบบเบรกในเครื่องด้วย การตั้งค่า ENGINE_WORKER_COUNT=0 จะเป็นการหยุดรับงานใหม่ชั่วคราว และค่า worker เดียวกันนี้สามารถเปลี่ยนแปลงได้ในหน้า Settings เมื่อ stack กำลังทำงานอยู่

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

เริ่มการทำงานของ stack และตรวจสอบความพร้อมใช้งาน

./kritt start

คำสั่งนี้จะตรวจสอบ .env และข้อมูลรับรองอย่างน้อยหนึ่งรายการ จากนั้นจึงรัน docker compose up --build การ build ครั้งแรกจะใช้เวลานานเนื่องจากระบบต้องสร้างอิมเมจสำหรับ frontend, backend, engine, executor view และ database นอกจากนี้กระบวนการยังทำงานใน foreground ดังนั้นการปิด SSH session จะทำให้ stack หยุดทำงาน คุณควรเริ่มการทำงานภายใน tmux หรือสั่งให้ทำงานแบบ detached หลังจาก build ครั้งแรกสำเร็จแล้ว ทั้งสองวิธีนี้ไม่สามารถคงสถานะหลังการรีบูตได้ด้วยตัวเอง ดังนั้นหากคุณต้องการให้ stack กลับมาทำงานหลังจากรีสตาร์ทเครื่อง รูปแบบการใช้ systemd unit ใน การรักษาให้ self-hosted agent ทำงานต่อเนื่องหลังรีบูต สามารถนำมาปรับใช้ได้โดยตรง

docker compose up -d --build
docker compose ps

docker compose ps ควรแสดงรายการ open-kritt-frontend, open-kritt-backend, open-kritt-engine, open-kritt-executor-view และ open-kritt-db จากนั้นให้ตรวจสอบว่า backend ตอบสนองบนเซิร์ฟเวอร์หรือไม่

curl -s http://127.0.0.1:3002/api/health

การตอบกลับเป็น JSON หมายความว่า backend พร้อมใช้งาน หากได้รับ Failed to connect to 127.0.0.1 port 3002: Connection refused แสดงว่า backend ยังไม่ทำงาน และ docker compose logs backend จะระบุสาเหตุให้ทราบ คุณสามารถหยุดการทำงานทั้งหมดได้ด้วย docker compose down จากไดเรกทอรีของ repository

ส่วนเสริมเพิ่มเติม: docker compose exec backend npm run seed จะโหลดข้อมูลตัวอย่าง ซึ่งเป็นวิธีที่ง่ายในการทดลองใช้งานอินเทอร์เฟซก่อนที่คุณจะเริ่มการสแกนจริง

เข้าถึง UI บนพอร์ต 5173 ผ่าน SSH tunnel

บริการทุกตัวในไฟล์ compose จะผูกกับ 127.0.0.1 โดยค่าเริ่มต้น ได้แก่ frontend ที่พอร์ต 5173, backend ที่พอร์ต 3002, executor view ที่พอร์ต 8090 และ Postgres ที่พอร์ต 5432 ให้คงการตั้งค่าการผูกพอร์ตเหล่านั้นไว้ตามเดิม แล้วใช้วิธี forward พอร์ตผ่าน SSH จากเครื่องของคุณแทน

ssh -N -L 5173:127.0.0.1:5173 you@your-server-ip

เปิด http://localhost:5173 ในเบราว์เซอร์บนเครื่องของคุณในขณะที่คำสั่งดังกล่าวยังทำงานอยู่ -N หมายความว่าการเชื่อมต่อนี้จะทำหน้าที่ส่งผ่านข้อมูลเท่านั้นโดยไม่เปิด shell ขึ้นมา ให้เพิ่ม -L 8090:127.0.0.1:8090 ตัวที่สองเข้าไปในคำสั่งเดียวกันหากคุณต้องการเข้าถึง executor view ด้วย

หลายคนมักจะตั้งค่า FRONTEND_BIND_ADDRESS=0.0.0.0 เพื่อข้ามขั้นตอนการทำ tunnel แต่อย่าทำเช่นนั้น เนื่องจาก backend ไม่มีหน้าจอสำหรับล็อกอิน ดังนั้นใครก็ตามที่เข้าถึงหน้านั้นได้จะสามารถเริ่มการสแกนและใช้เครดิตของผู้ให้บริการของคุณได้ นอกจากนี้ยังมีกับดักอีกชั้นหนึ่งคือ พอร์ตของคอนเทนเนอร์ที่ถูกเผยแพร่ออกมาจะถูกประมวลผลก่อนที่นโยบายเริ่มต้นของ ufw จะทำงาน ดังนั้นกฎ ufw deny 5173 จึงดูเหมือนถูกต้องแต่กลับไม่สามารถบล็อกอะไรได้เลย พอร์ต Docker ที่ข้ามการทำงานของ ufw แสดงให้เห็นถึงลำดับของกฎที่ทำให้เกิดปัญหานี้

การกำหนดขนาด VPS

ENGINE_MIN_FREE_STORAGE_GB มีค่าเริ่มต้นอยู่ที่ 20 และเอนจินจะปฏิเสธการเริ่มคอนเทนเนอร์สำหรับสแกนงานใหม่เมื่อพื้นที่จัดเก็บข้อมูลว่างเหลือน้อยกว่าค่านี้ เนื่องจากอิมเมจที่ build แล้ว, แคชของการ checkout, ข้อมูล Postgres และพื้นที่ทำงานของงานทั้งหมดอยู่บนดิสก์เดียวกัน VPS ขนาด 20 GB จึงไม่สามารถเริ่มการสแกนได้เลย ให้ถือว่า 40 GB เป็นขนาดขั้นต่ำ และเพิ่มขนาดหากคุณต้องสแกน repository ขนาดใหญ่

หน่วยความจำใช้การคำนวณแบบพื้นฐาน ENGINE_MEMORY_RESERVE_GB=2 จะสำรองหน่วยความจำไว้สำหรับเอนจิน, ฐานข้อมูล, API และส่วนงานเสริมระยะสั้น โดยตัวรันการสแกน (scan runner) แต่ละตัวจะมีการจองหน่วยความจำและขีดจำกัดสูงสุดไว้ที่ ENGINE_SCAN_RUNNER_MEMORY_MB=1536 ดังนั้น worker สองตัวจึงต้องการหน่วยความจำประมาณ 5 GB ก่อนที่จะเริ่มรันงานอื่น เอนจินจะอนุญาตให้เฉพาะ runner ที่มีขนาดพอดีกับงบประมาณหน่วยความจำที่เหลืออยู่เท่านั้น ดังนั้นบนเครื่องขนาดเล็ก งานสแกนจะเข้าคิวแทนที่จะล้มเหลว ซึ่งเป็นรูปแบบการจัดการความล้มเหลวที่ดีกว่าการถูก out-of-memory killer สั่งยุติการทำงาน

การตั้งค่าการล้างข้อมูล (prune) สองรายการมีค่าเริ่มต้นเป็น true ได้แก่ ENGINE_AUTO_PRUNE_DOCKER_BUILD_CACHE และ ENGINE_AUTO_PRUNE_UNUSED_DOCKER_IMAGES หลังจากงานเสร็จสิ้น เอนจินจะลบ build cache ที่ไม่ได้ใช้งาน, อิมเมจที่ไม่ได้ใช้งาน และคอนเทนเนอร์สแกนที่หยุดทำงานออกไป ส่วนอิมเมจที่ถูกอ้างอิงโดยคอนเทนเนอร์ที่กำลังทำงาน, bind mounts, ข้อมูลฐานข้อมูล, ข้อมูลรับรอง (credentials) และ volume จะถูกเก็บไว้ นี่เป็นอีกหนึ่งเหตุผลที่ไม่ควรแชร์โฮสต์ร่วมกับผู้อื่น เนื่องจากจะมีตัวล้างข้อมูลที่คุณไม่ได้ตั้งค่าไว้ทำงานอยู่กับ Docker daemon นั้น

การสแกน repository ในเครื่องโดยไม่ให้ข้อมูลรั่วไหล

LOCAL_REPOS_PATH จะใช้ค่าเริ่มต้นเป็น ./local_repos และถูก bind-mount เข้าไปใน container ของ backend และ engine ที่ตำแหน่ง /local_repos ดังนั้น repository ที่คุณวางไว้ในโฟลเดอร์นั้นบนโฮสต์จะปรากฏอยู่ภายใน container ทันที ให้ใช้การ clone ใหม่แทนการใช้ working tree ของคุณ ตัว job container จะได้รับสำเนาที่เขียนข้อมูลได้ โดยมีสิทธิ์เป็น root ภายในตัวมันเอง และสามารถเข้าถึงอินเทอร์เน็ตภายนอกได้ ซึ่งหมายความว่าสิ่งใดก็ตามที่อยู่ในสำเนานั้นอาจถูกเปลี่ยนแปลงหรือส่งออกไปนอกเครื่องได้ ให้ลบไฟล์ .env และ private key ออกก่อนที่คุณจะคัดลอกโปรเจกต์เข้าไป

สิ่งที่คุณได้รับและสิ่งที่คุณไม่ได้รับ

คุณจะได้รับรายการผลการค้นหาที่ผ่านการจัดอันดับแล้ว แต่คุณจะไม่ได้รับช่องโหว่ที่ผ่านการตรวจสอบยืนยันแล้ว การจัดอันดับและการกำจัดรายการซ้ำจะเป็นตัวกำหนดลำดับคิวในการคัดกรองของคุณ สิ่งเหล่านี้ไม่ได้เป็นเครื่องพิสูจน์ว่ารายการนั้นเป็นช่องโหว่จริง สคริปต์ภายหลังการสแกน (post-scripts) สามารถพยายามตรวจสอบและสร้างหลักฐานแนวคิด (proof of concept) ซึ่งถือเป็นสัญญาณที่ชัดเจนที่สุดที่เครื่องมือนี้มอบให้ แต่หากสคริปต์ดังกล่าวทำงานล้มเหลว ก็ไม่ได้หมายความว่าผลการค้นหานั้นเป็นเท็จ มนุษย์ยังคงต้องเป็นผู้ตรวจสอบผลการค้นหาแต่ละรายการด้วยตนเอง

คู่มือนี้ไม่ได้กล่าวอ้างว่า open-kritt สามารถตรวจพบข้อผิดพลาดจริงได้จำนวนเท่าใด เนื่องจากเรายังไม่ได้ทำการวัดผล ผู้ใดก็ตามที่กล่าวอ้างถึงอัตราการตรวจพบสำหรับ codebase ของคุณ แสดงว่าผู้นั้นยังไม่ได้ทดสอบเครื่องมือนี้กับ codebase ของคุณจริง ให้เริ่มจากการสแกน repository ที่คุณคุ้นเคยเป็นอย่างดีก่อน เพราะผลการค้นหาที่คุณสามารถตัดสินได้ด้วยตนเองคือวิธีปรับเทียบเครื่องมือที่ประหยัดที่สุด

การอนุญาตสิทธิ์มีความสำคัญในที่นี้มากกว่าเครื่องมือแบบ self-hosted ส่วนใหญ่ เนื่องจากเอเจนต์จะทำการคอมไพล์และเรียกใช้โค้ดรวมถึงเข้าถึงเครือข่าย ดังนั้นขั้นตอนการสร้างหลักฐานแนวคิดอาจส่งผลกระทบต่อระบบที่ใช้งานจริง ให้ชี้เป้าไปยังโค้ดที่คุณเป็นเจ้าของหรือได้รับสัญญาให้ทดสอบเท่านั้น และระบุขอบเขตเป้าหมายให้ชัดเจนก่อนเริ่มดำเนินการใดๆ หากคุณกำหนดค่า ANTHROPIC_API_KEY และใช้เอนจิน Claude Code แนวทางการทำ sandboxing ใน การใช้งาน Claude Code อย่างปลอดภัยบน VPS ก็สามารถนำมาปรับใช้กับเอเจนต์เหล่านี้ได้เช่นกัน

FAQ

ทำไม open-kritt ถึงต้องใช้ VPS แยกต่างหาก?

เพราะตัวแทนวิเคราะห์ (analysis agents) ทำงานด้วยสิทธิ์ root ภายในคอนเทนเนอร์สำหรับงานชั่วคราว ซึ่งมีสำเนาโค้ดของคุณที่เขียนทับได้และเข้าถึงอินเทอร์เน็ตได้โดยตรง อีกทั้งบริการ engine ยัง mount Docker socket ของโฮสต์เพื่อให้สามารถเริ่มคอนเทนเนอร์แยกตามงานได้ กระบวนการใดก็ตามที่เข้าถึง socket นั้นได้จะสามารถเริ่มคอนเทนเนอร์ที่ mount ระบบไฟล์ของโฮสต์ได้ ดังนั้นทั้ง stack จึงควรถูกมองว่ามีสิทธิ์ระดับ root บนโฮสต์นั้น บน VPS เฉพาะทางถือเป็นความเสี่ยงที่ยอมรับได้และการสร้างเซิร์ฟเวอร์ใหม่ก็ไม่มีค่าใช้จ่าย แต่หากรันบนเวิร์กสเตชันส่วนตัว จะเป็นการนำ SSH keys และโปรไฟล์เบราว์เซอร์ของคุณไปไว้ในขอบเขตความเชื่อถือเดียวกับโค้ดที่คุณกำลังสแกน

ฉันสามารถเปิดพอร์ต 5173 แทนการใช้ SSH tunnel ได้หรือไม่?

ไม่ควรทำอย่างยิ่ง เนื่องจาก backend ถูกส่งมอบมาโดยไม่มีระบบยืนยันตัวตนในระดับแอปพลิเคชัน พอร์ตดังกล่าวจึงเป็นปราการด่านเดียวที่กั้นระหว่างอินเทอร์เน็ตกับผลการสแกนและเครดิตของผู้ให้บริการของคุณ ไฟล์ compose จึงผูกทุกบริการไว้กับ 127.0.0.1 ด้วยเหตุผลนี้ ให้รัน ssh -N -L 5173:127.0.0.1:5173 you@your-server-ip แล้วเข้าใช้งานผ่าน http://localhost:5173 ในเครื่องแทน การใช้กฎ ufw ไม่สามารถทดแทนได้ เพราะพอร์ต Docker ที่ถูกเผยแพร่จะถูกจัดการก่อนที่นโยบายเริ่มต้นของ ufw จะทำงาน

ฉันจะป้องกันไม่ให้ open-kritt ใช้จ่ายเกินงบที่วางไว้ได้อย่างไร?

ให้กำหนดวงเงินสูงสุด (hard limit) ในคอนโซลของผู้ให้บริการโมเดลก่อนเริ่มการสแกนครั้งแรก เพราะ open-kritt ไม่มีระบบตั้งค่าวงเงินในตัว ให้คงค่า concurrency เริ่มต้นที่ให้มาไว้สำหรับการรันครั้งแรกๆ คือ ENGINE_WORKER_COUNT=2 และ ENGINE_MAX_CONCURRENT_SCANS=1 และโปรดจำไว้ว่าบัญชีผู้ให้บริการหนึ่งบัญชีอนุญาตให้เรียกใช้โมเดลระดับ root พร้อมกันได้สูงสุด 15 รายการตามค่าเริ่มต้น ในขณะที่เซสชัน Codex อาจรันตัวแทนลูกได้สูงสุด 5 รายการ ENGINE_WORKER_COUNT=0 จะหยุดการรับงานใหม่และเป็นวิธีหยุดการทำงานในเครื่องที่เร็วที่สุด

ฉันควรเลือกใช้เวอร์ชันไหน?

ให้เลือกใช้ tag เสมอ ห้ามใช้ main การใช้ git fetch --tags ตามด้วย git tag --list จะแสดงรายการที่มีให้เลือก และ v1.3.0 ซึ่งเผยแพร่เมื่อวันที่ 4 สิงหาคม 2026 คือเวอร์ชันล่าสุด ณ เวลาที่เขียนบทความนี้ การระบุเวอร์ชันที่แน่นอน (pinning) ช่วยให้มั่นใจได้ว่าการสร้าง stack ใหม่ในอีกหลายเดือนข้างหน้าจะได้ผลลัพธ์เหมือนเดิม และทำให้การอัปเกรดเป็นสิ่งที่คุณตัดสินใจทำหลังจากอ่านบันทึกการเปลี่ยนแปลง (release notes) แล้ว ไม่ใช่ผลพลอยได้จากการ clone ในวันที่ต่างกัน

การสแกนไม่เริ่มทำงาน ฉันควรตรวจสอบอะไรบ้าง?

ให้ตรวจสอบพื้นที่ดิสก์ว่างเป็นอันดับแรก เนื่องจาก engine จะไม่เริ่มคอนเทนเนอร์สแกนสำหรับงานหากพื้นที่เก็บข้อมูลว่างต่ำกว่า ENGINE_MIN_FREE_STORAGE_GB ซึ่งค่าเริ่มต้นคือ 20 GB จากนั้นตรวจสอบว่า ENGINE_WORKER_COUNT ไม่ใช่ 0 เพราะค่าดังกล่าวจะหยุดการรับงานใหม่ จากนั้นยืนยันว่ามีการตั้งค่า credential ของโมเดลไว้จริงโดยรัน ./kritt setup เพราะการมีเพียง GITHUB_TOKEN อย่างเดียวไม่สามารถรันการสแกนได้ docker compose logs engine จะระบุสาเหตุที่งานนั้นถูกข้ามไป