Cara Self-host Open-Kritt pada VPS dengan Docker

Mengapa anda perlu self-host open-kritt pada VPS dan bukan pada komputer riba anda

Lakukan self-host open-kritt pada pelayan yang boleh anda hapuskan dan bina semula. Alat ini menjalankan ejen analisisnya sebagai root di dalam bekas kerja (job containers) yang boleh dibuang, memberikan setiap ejen salinan kod anda yang boleh ditulis serta akses internet terus, dan melekapkan (mount) soket Docker hos ke dalam perkhidmatan enjinnya. Ini merupakan pertukaran yang munasabah pada mesin yang dikhaskan untuk tugasan tersebut. Ia adalah tindakan yang buruk pada mesin yang menyimpan kunci SSH anda.

Empat sifat tetapan lalai mendorong nasihat tersebut, dan kesemuanya datang daripada README dan fail compose projek itu sendiri.

Ejen-ejen tersebut direka untuk menjadi berkuasa. README menyatakan bahawa ejen yang didayakan dengan alatan berjalan sebagai root di dalam bekas kerja yang boleh dibuang, dengan salinan repositori yang boleh ditulis dan akses internet terus, supaya ia boleh memasang alatan, menyusun sasaran, menjalankan ujian, dan membina bukti konsep. Imbasan bukanlah sekadar linter yang membaca fail. Ia adalah pelaksanaan kod arbitrari yang anda minta. Akses internet itu mempunyai dua sisi: apa sahaja yang diambil oleh ejen semasa menyelidik sasaran adalah teks tidak dipercayai yang tiba di dalam gesaannya (prompt), pendedahan yang sama yang anda hadapi apabila anda memberikan ejen keupayaan carian webnya sendiri.

Enjin memegang soket Docker. docker-compose.yml melekapkan soket Docker hos ke dalam perkhidmatan enjin, kerana enjin membina dan melancarkan satu bekas imbasan bagi setiap kerja. Sebarang proses yang boleh mencapai soket tersebut boleh memulakan bekas yang melekapkan sistem fail hos. Jadi, enjin tersebut secara efektifnya adalah root pada mana-mana hos yang menjalankannya.

Tiada skrin log masuk. Bahagian belakang (backend) dihantar tanpa pengesahan aplikasi. Akses kepada port tersebut bermakna akses kepada penemuan anda dan kredit pembekal anda.

Kod yang anda imbas selalunya bukan milik anda. Menghalakan ejen kepada repositori pihak ketiga bermakna menjalankan binaan repositori tersebut pada mesin anda, sebagai root, dengan akses rangkaian.

Jika anda telah membaca mengapa ejen pengekodan perlu berada dalam VM yang boleh dibuang, ini adalah model ancaman yang sama, cuma lebih kuat. Berikan open-kritt sebuah VPS yang tidak mengandungi apa-apa lagi, dan kendalikan VPS tersebut daripada akaun pengguna dengan keistimewaan minimum yang berasingan dan bukannya root.

Fungsi sebenar open-kritt

open-kritt (repositori berada di Kritt-ai/open-kritt, dilesenkan di bawah AGPL-3.0) memecahkan penyelidikan kerentanan kepada tugasan kecil, menjalankan tugasan tersebut merentasi ejen AI secara selari, kemudian menyahganda dan menyusun hasil yang diterima. Anda menentukan aliran kerja sebagai rantaian prompt yang fokus, dan setiap langkah menerima konteks berstruktur daripada langkah sebelumnya. Sasaran imbasan ialah repositori git jauh atau tempatan. Enjin analisis ialah Codex atau Claude Code. Selepas calon kerentanan muncul, skrip pasca-pemprosesan pilihan boleh cuba mengesahkannya atau membina bukti konsep (proof of concept).

Apa yang anda peroleh pada akhirnya ialah senarai calon yang telah disusun. Anggap ia sebagai baris gilir triaj, bukan sebagai laporan akhir.

Keperluan sebelum bermula

• Sebuah VPS yang menjalankan Ubuntu 24.04, Debian 12 atau Rocky Linux 9. Dokumentasi pemasangan menyenaraikan sistem pengendalian ini sebagai pengedaran yang telah diuji, pada seni bina x86_64 dan ARM64.
• Docker Engine dengan pemalam Compose.
• Node.js 20 atau lebih baharu pada hos, kerana ./kritt CLI berjalan pada hos dan bukannya di dalam kontena.
• Satu penyedia model: log masuk Codex, atau OPENAI_API_KEY, CODEX_API_KEY, ANTHROPIC_API_KEY atau OPENROUTER_API_KEY.
• GITHUB_TOKEN hanya jika anda merancang untuk mengimbas repositori peribadi. .env.example yang disertakan menyatakan perkara ini dengan jelas: token GitHub sahaja tidak boleh menjalankan imbasan.

Pasang Docker dan Node 20 terlebih dahulu

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

Log keluar dan masuk semula supaya keahlian kumpulan baharu berkuat kuasa, kemudian sahkan pemalam Compose telah tersedia.

docker compose version

Rentetan versi bermaksud Compose dipasang sebagai pemalam. docker: 'compose' is not a docker command bermaksud anda mempunyai binari docker-compose kendiri yang lama, dan open-kritt memanggil docker compose. Keahlian kumpulan docker adalah setara dengan root pada hos, jadi masukkan hanya akaun yang menjalankan open-kritt ke dalamnya. Untuk versi persediaan yang lebih panjang, lihat menjalankan Docker pada VPS.

Ubuntu 24.04 membekalkan Node 18 dalam repositorinya sendiri, dan CLI akan keluar jika versi di bawah 20 dikesan. Gunakan NodeSource.

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

node -v mesti memaparkan v20. atau lebih tinggi. Pada Rocky Linux 9, langkah setara ialah sudo dnf module enable nodejs:20 -y diikuti dengan sudo dnf install -y nodejs.

Klon open-kritt dan kunci kepada keluaran bertanda

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

main bergerak mengikut anda. Tag tidak berbuat demikian. Setakat Ogos 2026, tag terbaharu ialah v1.3.0, yang diterbitkan pada 4 Ogos 2026, dan git tag --list menunjukkan apa yang wujud pada hari anda melakukan klon. Melakukan checkout pada tag akan meninggalkan repositori dalam keadaan detached HEAD, yang merupakan tindakan betul di sini: anda melayan klon ini sebagai penempatan yang dikunci, bukan sebagai cawangan yang anda lakukan commit. Untuk menaik taraf kemudian, baca nota keluaran, kemudian jalankan git fetch --tags, lakukan checkout pada tag baharu, dan jalankan ./kritt start sekali lagi, kerana start membina semula imej tersebut.

Jangan jalankan ./kritt dengan sudo. Dokumentasi menyatakan perkara ini dengan jelas. CLI mengurus direktori kelayakan setempat projek di bawah .data/, jadi pelaksanaan sebagai root akan menyebabkan direktori tersebut dimiliki oleh root dan pelaksanaan biasa seterusnya tidak dapat menulis ke dalamnya.

Konfigurasikan akses model dengan ./kritt setup

./kritt setup

Perintah ini mencipta .env daripada .env.example apabila ia tidak wujud, memaparkan status setiap kelayakan, dan membolehkan anda menetapkan atau membatalkan tetapan tersebut. Ia tidak akan memaparkan nilai tersebut kembali ke terminal. Kedua-dua .env dan fail kelayakan enjin ditulis dengan mod 0600.

Jika anda lebih suka melakukannya secara manual:

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

Kemudian, sunting kunci pembekal ke dalam .env dan biarkan fail tersebut pada mod 0600. Walau apa pun caranya, kelayakan pembekal yang berfungsi kini berada pada pelayan tersebut, yang merupakan satu lagi sebab mengapa pelayan itu tidak sepatutnya menyimpan apa-apa perkara lain. Cipta kunci khusus untuk projek ini sahaja, supaya pembatalannya nanti tidak menjejaskan perkara lain yang penting bagi anda. Menjauhkan rahsia daripada capaian ejen AI merangkumi tabiat yang lebih meluas.

Tetapkan had perbelanjaan penyedia sebelum imbasan pertama

open-kritt dibina untuk melakukan fan-out, dan fan-out inilah yang anda bayar. Nilai lalai dalam .env.example pada v1.3.0 adalah konservatif: ENGINE_WORKER_COUNT=2, yang diterangkan dalam fail tersebut sebagai nilai lalai konservatif untuk mesin 2-vCPU kecil, dan ENGINE_MAX_CONCURRENT_SCANS=1. Di atas nilai tersebut terdapat ENGINE_WORKERS_PER_ACCOUNT=15, iaitu bilangan maksimum panggilan model root serentak yang dibenarkan pada satu akaun penyedia, dan ENGINE_CODEX_MAX_SUBAGENTS_PER_SESSION=5, kerana sesi Codex boleh menjalankan sehingga lima ejen kanak-kanak. Tingkatkan bilangan pekerja pada VPS yang lebih besar dan bilangan panggilan model yang sedang berjalan akan meningkat bersamanya.

Tiada apa-apa dalam repositori yang mengehadkan perbelanjaan anda. Tiada tetapan bajet dalam .env.example. Syarat henti enjin itu sendiri adalah had pekerja tersebut ditambah dengan ENGINE_HARNESS_TIMEOUT_SECONDS, yang ditetapkan secara lalai kepada 7200 saat bagi setiap larian harness. Jadi, had maksimum perlu diletakkan pada pihak penyedia. Buka konsol penyedia anda dan tetapkan had bulanan yang tegas sebelum imbasan pertama, bukan selepasnya. Mengawal kos ejen AI pada VPS menerangkan tetapan bagi setiap penyedia.

Terdapat juga brek setempat. Menetapkan ENGINE_WORKER_COUNT=0 akan menjeda pengambilan kerja baharu, dan nilai pekerja yang sama boleh diubah dalam skrin Settings sebaik sahaja stack sedang berjalan.

Panduan ini tidak memetik harga bagi setiap imbasan, kerana kos bergantung pada saiz repositori, aliran kerja yang anda bina dan model di sebaliknya. Jalankan satu imbasan terhadap satu repositori kecil, kemudian baca halaman penggunaan penyedia anda sebelum anda menghalakannya kepada mana-mana repositori yang besar.

Mulakan tindanan dan pastikan ia sihat

./kritt start

Perintah tersebut menyemak .env dan sekurang-kurangnya satu kelayakan, kemudian menjalankan docker compose up --build. Binaan pertama adalah perlahan kerana ia membina imej untuk frontend, backend, engine, executor view dan pangkalan data. Ia juga berjalan di latar depan, jadi menutup sesi SSH akan menghentikan tindanan tersebut. Mulakannya di dalam tmux, atau jalankan ia dalam mod terasing (detached) setelah binaan pertama berjaya. Tiada satu pun daripada cara ini yang akan bertahan selepas but semula secara automatik, jadi jika anda mahukan tindanan tersebut kembali berjalan selepas pelayan dimulakan semula, corak unit systemd dalam mengekalkan ejen layan diri berjalan merentasi but semula boleh digunakan secara terus.

docker compose up -d --build
docker compose ps

docker compose ps sepatutnya menyenaraikan open-kritt-frontend, open-kritt-backend, open-kritt-engine, open-kritt-executor-view dan open-kritt-db. Kemudian, pastikan backend memberikan respons pada pelayan itu sendiri.

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

Respons JSON bermaksud backend sedang berjalan. Failed to connect to 127.0.0.1 port 3002: Connection refused bermaksud ia tidak berjalan, dan docker compose logs backend akan menyatakan puncanya. Hentikan segala-galanya dengan docker compose down dari direktori repositori.

Satu tambahan pilihan: docker compose exec backend npm run seed memuatkan data demo, yang merupakan cara mudah untuk melihat antara muka sebelum anda membelanjakan apa-apa untuk imbasan sebenar.

Capai UI pada port 5173 melalui SSH tunnel

Setiap servis dalam fail compose terikat pada 127.0.0.1 secara lalai: frontend pada 5173, backend pada 3002, paparan executor pada 8090 dan Postgres pada 5432. Biarkan ikatan tersebut seperti sedia ada dan lakukan port forwarding melalui SSH dari mesin anda sendiri.

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

Buka http://localhost:5173 dalam pelayar tempatan anda semasa arahan tersebut dijalankan. -N bermaksud sambungan tersebut membawa forward dan tiada shell. Tambahkan -L 8090:127.0.0.1:8090 kedua pada arahan yang sama apabila anda mahukan paparan executor juga.

Terdapat kecenderungan untuk menetapkan FRONTEND_BIND_ADDRESS=0.0.0.0 dan melangkau tunnel tersebut. Jangan lakukannya. Backend tidak mempunyai skrin log masuk, jadi sesiapa sahaja yang mencapai halaman tersebut boleh memulakan imbasan dan menghabiskan kredit pembekal anda. Terdapat perangkap kedua di bawahnya: port kontena yang diterbitkan dikendalikan sebelum polisi lalai ufw digunakan, jadi peraturan ufw deny 5173 kelihatan betul tetapi tidak menyekat apa-apa. Port Docker yang memintas ufw menunjukkan rantaian peraturan yang menyebabkannya.

Menentukan saiz VPS

ENGINE_MIN_FREE_STORAGE_GB ditetapkan secara lalai kepada 20, dan enjin akan menolak untuk memulakan kontena imbasan bagi setiap kerja baharu apabila storan bebas jatuh di bawah nilai tersebut. Imej yang dibina, cache daftar keluar, data Postgres dan ruang kerja kerja semuanya berada pada cakera yang sama, jadi VPS 20 GB tidak akan memulakan sebarang imbasan. Anggap 40 GB sebagai had minimum, dan berikan lebih banyak jika anda mengimbas repositori yang besar.

Memori mengikut pengiraan aritmetik yang mudah. ENGINE_MEMORY_RESERVE_GB=2 menahan memori untuk enjin, pangkalan data, API dan overhed jangka pendek, dan setiap pelari imbasan membawa tempahan serta had keras sebanyak ENGINE_SCAN_RUNNER_MEMORY_MB=1536. Oleh itu, dua pekerja memerlukan kira-kira 5 GB sebelum apa-apa lagi dijalankan. Enjin hanya membenarkan pelari yang muat dalam bajet yang tinggal, jadi pada mesin kecil, imbasan akan beratur dan bukannya gagal, yang merupakan mod kegagalan yang jauh lebih baik daripada pembunuh kehabisan memori (OOM killer).

Dua tetapan pemangkasan (prune) ditetapkan kepada benar secara lalai: ENGINE_AUTO_PRUNE_DOCKER_BUILD_CACHE dan ENGINE_AUTO_PRUNE_UNUSED_DOCKER_IMAGES. Selepas sesuatu tugasan selesai, enjin akan mengalih keluar cache binaan yang tidak digunakan, imej yang tidak digunakan dan kontena imbasan yang telah dihentikan. Imej yang dirujuk oleh kontena yang sedang berjalan, bind mount, data pangkalan data, kelayakan dan volum akan dikekalkan. Ini merupakan satu lagi sebab untuk tidak berkongsi hos: pemangkas yang tidak anda konfigurasikan sedang berjalan terhadap daemon Docker tersebut.

Mengimbas repositori tempatan tanpa kebocoran

LOCAL_REPOS_PATH ditetapkan secara lalai kepada ./local_repos dan dipasang (bind-mounted) ke dalam kontena backend dan engine pada /local_repos, jadi repositori yang anda letakkan ke dalam folder tersebut pada hos akan muncul di dalam kontena dengan serta-merta. Gunakan klon baharu, bukan working tree anda. Kontena kerja mendapat salinan yang boleh ditulis, akses root di dalamnya, dan akses internet keluar, yang bermaksud apa-apa sahaja yang berada dalam salinan itu boleh diubah atau dihantar keluar dari pelayan. Buang fail .env dan kunci peribadi sebelum anda menyalin projek masuk.

Apa yang anda peroleh, dan apa yang tidak

Anda akan menerima penemuan calon yang telah disusun mengikut ranking. Anda tidak akan menerima kerentanan yang telah disahkan. Ranking dan penyahduplikasian menentukan urutan baris gilir triaj anda. Ia tidak membuktikan bahawa sesuatu entri itu benar. Skrip pasca (post-script) boleh mencuba pengesahan dan membina bukti konsep, dan itu merupakan isyarat paling kukuh yang ditawarkan oleh alat ini, namun skrip pasca yang gagal bukanlah bukti bahawa penemuan tersebut adalah palsu. Seseorang masih perlu membaca setiap calon penemuan.

Panduan ini tidak membuat sebarang tuntutan tentang berapa banyak pepijat sebenar yang ditemui oleh open-kritt, kerana kami belum mengukurnya. Sesiapa yang memetik kadar pengesanan untuk pangkalan kod anda bermakna mereka belum menjalankannya terhadap pangkalan kod anda. Imbas repositori yang anda sudah kenali dengan baik terlebih dahulu: penemuan yang boleh anda nilai sendiri adalah penentukuran paling murah yang tersedia.

Kebenaran (authorization) lebih penting di sini berbanding kebanyakan alat yang dihoskan sendiri. Ejen-ejen ini menyusun dan melaksanakan kod serta mencapai rangkaian, jadi langkah bukti konsep boleh menyentuh sistem yang sedang berjalan. Halakan ia kepada kod yang anda miliki atau yang anda dikontrakkan untuk diuji, dan tulis skop sasaran sebelum anda menjalankan apa-apa. Jika anda mengkonfigurasi ANTHROPIC_API_KEY dan menggunakan enjin Claude Code, tabiat pemisahan (sandboxing) dalam menjalankan Claude Code dengan selamat pada VPS juga terpakai kepada ejen-ejen ini.

FAQ

Mengapa open-kritt memerlukan VPS sendiri?

Kerana ejen analisisnya berjalan sebagai root di dalam kontena kerja pakai buang yang mempunyai salinan kod anda yang boleh ditulis serta akses internet terus, dan kerana servis enjin melekapkan (mount) soket Docker hos supaya ia boleh melancarkan satu kontena bagi setiap kerja. Mana-mana proses yang mencapai soket tersebut boleh memulakan kontena yang melekapkan sistem fail hos, jadi keseluruhan tindanan (stack) ini harus dianggap sebagai root pada hosnya. Pada VPS khusus, ini adalah pertukaran yang boleh diterima, dan membina semula pelayan tersebut tidak menelan sebarang kos. Pada stesen kerja harian anda, ia meletakkan kunci SSH dan profil pelayar anda di dalam sempadan kepercayaan yang sama dengan kod yang sedang anda imbas.

Bolehkah saya mendedahkan port 5173 dan bukannya menggunakan terowong SSH?

Anda tidak sepatutnya berbuat demikian. Bahagian backend dihantar tanpa pengesahan aplikasi, jadi port tersebut adalah satu-satunya penghalang antara internet dengan penemuan anda serta kredit pembekal. Fail compose mengikat setiap servis kepada 127.0.0.1 atas sebab tersebut. Jalankan ssh -N -L 5173:127.0.0.1:5173 you@your-server-ip dan layari http://localhost:5173 secara setempat. Peraturan ufw bukanlah pengganti, kerana port Docker yang diterbitkan dikendalikan sebelum polisi lalai ufw digunakan.

Bagaimanakah cara untuk menghalang open-kritt daripada berbelanja melebihi perancangan saya?

Tetapkan had keras dalam konsol pembekal model anda sebelum imbasan pertama, kerana open-kritt tidak mempunyai tetapan bajetnya sendiri. Kekalkan tetapan serentak (concurrency) lalai yang dihantar untuk beberapa larian pertama, ENGINE_WORKER_COUNT=2 dan ENGINE_MAX_CONCURRENT_SCANS=1, dan ingat bahawa satu akaun pembekal membenarkan sehingga 15 panggilan model root serentak secara lalai manakala sesi Codex mungkin menjalankan sehingga lima ejen kanak-kanak. ENGINE_WORKER_COUNT=0 menjeda pengambilan kerja baharu dan merupakan cara berhenti setempat yang paling pantas.

Versi manakah yang perlu saya semak keluar (check out)?

Gunakan tag, jangan sekali-kali main. git fetch --tags diikuti dengan git tag --list menunjukkan perkara yang tersedia, dan v1.3.0, yang diterbitkan pada 4 Ogos 2026, adalah yang terbaharu semasa penulisan ini. Melakukan pinning bermakna pembinaan semula beberapa bulan kemudian menghasilkan tindanan yang sama, dan ia menjadikan peningkatan sebagai keputusan yang anda ambil selepas membaca nota keluaran dan bukannya kesan sampingan daripada melakukan pengklonan pada hari yang berbeza.

Imbasan tidak pernah bermula. Apakah yang perlu saya semak?

Semak ruang cakera kosong terlebih dahulu, kerana enjin tidak akan melancarkan kontena imbasan bagi setiap kerja apabila storan kosong berada di bawah ENGINE_MIN_FREE_STORAGE_GB, yang ditetapkan secara lalai kepada 20 GB. Kemudian, semak bahawa ENGINE_WORKER_COUNT bukan 0, kerana nilai tersebut menjeda pengambilan kerja baharu. Seterusnya, sahkan bahawa kelayakan model benar-benar dikonfigurasikan dengan menjalankan ./kritt setup, kerana GITHUB_TOKEN sahaja tidak boleh menjalankan imbasan. docker compose logs engine menamakan sebab mengapa ia melangkau kerja tersebut.