Paano i-self-host ang open-kritt sa isang VPS

Bakit i-self-host ang open-kritt sa isang VPS at hindi sa iyong laptop

I-self-host ang open-kritt sa isang server na maaari mong i-destroy at i-rebuild. Pinapatakbo ng tool ang mga analysis agent nito bilang root sa loob ng disposable job containers, binibigyan ang bawat isa ng writable copy ng iyong code at direktang internet access, at mina-mount ang host Docker socket sa engine service nito. Makatuwirang trade-off ito sa isang machine na nakalaan para sa job. Masama itong gawin sa machine na naglalaman ng iyong SSH keys.

Apat na katangian ng default setup ang pinagmumulan ng payong ito, at lahat ng ito ay makikita sa sariling README at compose file ng project.

Dapat makapangyarihan ang mga agent. Sinasabi sa README na ang tool-enabled agents ay tumatakbo bilang root sa loob ng disposable job containers, na may writable repository copies at direktang internet access, upang makapag-install sila ng tools, mag-compile ng targets, magpatakbo ng tests, at gumawa ng proofs of concept. Hindi simpleng linter na nagbabasa ng files ang scan. Arbitrary code execution ito na ikaw mismo ang humiling.

Nasa engine ang Docker socket. Mina-mount ng docker-compose.yml ang host Docker socket sa engine service, dahil nagbu-build at nagla-launch ang engine ng isang scan container para sa bawat job. Anumang process na makakaabot sa socket na iyon ay maaaring magsimula ng container na nagmo-mount sa filesystem ng host. Kaya ang engine ay epektibong root sa anumang host na nagpapatakbo nito.

Walang login screen. Walang application authentication ang backend kapag inilabas. Ang access sa port ay access sa iyong findings at sa credit ng iyong provider.

Madalas ay hindi iyo ang code na ini-scan mo. Kapag itinuro mo ang mga agent sa repository ng third party, pinapatakbo mo ang build ng repository na iyon sa iyong machine, bilang root, na may network access.

Kung nabasa mo na ang kung bakit dapat nasa disposable VM ang coding agents, pareho itong threat model, ngunit mas malakas ang mga panganib. Bigyan ang open-kritt ng VPS na walang ibang laman, at pamahalaan ang VPS na iyon gamit ang hiwalay na least-privilege user account sa halip na root.

Ano ang aktuwal na ginagawa ng open-kritt

Ang open-kritt (ang repository ay Kritt-ai/open-kritt, na lisensyado sa ilalim ng AGPL-3.0) ay hinahati ang vulnerability research sa maliliit na task, sabay-sabay na pinapagana ang mga task na iyon sa mga AI agent, at pagkatapos ay inaalis ang mga duplicate at niraranggo ang mga resulta. Tinutukoy mo ang workflow bilang magkakasunod na focused prompt, at tumatanggap ang bawat hakbang ng structured context mula sa mga naunang hakbang. Ang scan target ay remote o local na git repository. Ang analysis engine ay Codex o Claude Code. Kapag may lumitaw na candidate, maaaring gumamit ng optional post-script para subukang i-validate ito o gumawa ng proof of concept.

Sa dulo, makakakuha ka ng naka-rank na listahan ng mga candidate. Ituring ito bilang triage queue, hindi bilang report.

Mga kailangan bago magsimula

• Isang VPS na nagpapatakbo ng Ubuntu 24.04, Debian 12, o Rocky Linux 9. Itinuturing ng install docs na tested distributions ang mga ito para sa x86_64 at ARM64.
• Docker Engine na may Compose plugin.
• Node.js 20 o mas bago sa host, dahil tumatakbo ang ./kritt CLI sa host at hindi sa loob ng container.
• Isang model provider: Codex login, o OPENAI_API_KEY, CODEX_API_KEY, ANTHROPIC_API_KEY, o OPENROUTER_API_KEY.
• GITHUB_TOKEN lamang kung plano mong mag-scan ng mga private repository. Malinaw itong nakasaad sa shipped .env.example: hindi sapat ang GitHub token lamang para magpatakbo ng mga scan.

Unahin ang pag-install ng Docker at Node 20

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

Mag-log out at mag-log in muli para mailapat ang bagong group membership, pagkatapos ay tiyaking available ang Compose plugin.

docker compose version

Ipinapakita ng version string na naka-install ang Compose bilang plugin. Ipinapakita ng docker: 'compose' is not a docker command na mayroon ka sa halip ng lumang standalone na docker-compose binary, at tinatawag ng open-kritt ang docker compose. Katumbas ng root access sa host ang pagiging miyembro ng docker group, kaya idagdag lamang dito ang account na nagpapatakbo ng open-kritt. Para sa mas mahabang bersyon ng setup na ito, tingnan ang pagpapatakbo ng Docker sa isang VPS.

May Node 18 ang sariling repository ng Ubuntu 24.04, ngunit nag-e-exit ang CLI kapag mas mababa sa 20 ang bersyon. Gamitin ang NodeSource.

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

Dapat mag-print ang node -v ng v20. o mas mataas. Sa Rocky Linux 9, ang katumbas nito ay sudo dnf module enable nodejs:20 -y na sinusundan ng sudo dnf install -y nodejs.

I-clone ang open-kritt at i-pin ang tagged release

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

mainay gumagalaw habang may mga bagong commit. Hindi gumagalaw ang tag. Noong August 2026, ang pinakabagong tag ay v1.3.0, na inilathala noong 4 August 2026, at ipinapakita ng git tag --list kung ano ang available sa araw ng pag-clone mo. Kapag nag-check out ka ng tag, mapupunta ang repository sa detached HEAD state. Tama ito rito dahil itinuturing mong pinned deployment ang clone na ito, hindi branch na lalagyan mo ng commit. Para mag-upgrade sa ibang pagkakataon, basahin ang release notes, pagkatapos ay patakbuhin ang git fetch --tags, i-check out ang bagong tag, at patakbuhin muli ang ./kritt start dahil nire-rebuild ng start ang mga image.

Huwag patakbuhin ang ./kritt kasama ang sudo. Malinaw itong nakasaad sa documentation. Pinamamahalaan ng CLI ang project-local credential directories sa ilalim ng .data/. Kapag pinatakbo ito bilang root, magiging pagmamay-ari ng root ang mga directory na iyon at hindi na maisusulat ng susunod na normal na run ang mga ito.

I-configure ang access sa model gamit ang ./kritt setup

./kritt setup

Lumilikha ang command ng .env mula sa .env.example kapag wala pa ito, ipinapakita ang status ng bawat credential, at hinahayaan kang i-set o i-unset ang mga ito. Hindi nito kailanman ipinapakita ang mga value sa terminal. Ang .env at ang credential file ng engine ay parehong isinusulat gamit ang mode 0600.

Kung mas gusto mong gawin ito nang manu-mano:

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

Pagkatapos, i-edit ang provider key papunta sa .env at panatilihin ang file sa mode 0600. Sa alinmang paraan, may gumaganang provider credential na ngayon sa server na iyon. Isa pa itong dahilan para walang ibang laman ang server. Gumawa ng key na para lamang sa project na ito, upang walang mahalagang maapektuhan kapag binawi mo ito sa hinaharap. Sinasaklaw ng Pag-iwas na maabot ng AI agents ang mga lihim ang mas malawak na gawaing ito.

Magtakda ng spending cap sa provider bago ang unang scan

Idinisenyo ang open-kritt para magpatakbo ng maraming task nang sabay-sabay, at ang ganitong parallel execution ang binabayaran mo. Conservative ang mga default sa .env.example sa v1.3.0: ENGINE_WORKER_COUNT=2, na inilalarawan sa file bilang conservative default para sa maliit na 2-vCPU machine, at ENGINE_MAX_CONCURRENT_SCANS=1. Nasa itaas ng mga ito ang ENGINE_WORKERS_PER_ACCOUNT=15, ang maximum na bilang ng sabay-sabay na root model call na pinapayagan sa isang provider account, at ENGINE_CODEX_MAX_SUBAGENTS_PER_SESSION=5, dahil maaaring magpatakbo ang isang Codex session ng hanggang limang child agent. Kapag tinaasan mo ang worker count sa mas malaking VPS, tataas din ang bilang ng mga model call na kasalukuyang tumatakbo.

Walang repository setting na naglilimita sa iyong gastos. Walang budget setting sa .env.example. Ang sariling stop condition ng engine ay ang mga worker limit na ito at ang ENGINE_HARNESS_TIMEOUT_SECONDS, na may default na 7200 segundo bawat harness run. Kaya dapat nasa provider ang spending limit. Buksan ang provider console at magtakda ng hard monthly limit bago ang unang scan, hindi pagkatapos nito. Ipinapaliwanag ng Pagkontrol sa gastos ng AI agent sa VPS ang mga setting para sa bawat provider.

May local brake din. Kapag itinakda ang ENGINE_WORKER_COUNT=0, hihinto ang pagkuha ng mga bagong job. Maaari ring baguhin ang parehong worker value sa Settings screen kapag tumatakbo na ang stack.

Walang presyong bawat scan sa guide na ito, dahil nakadepende ang gastos sa laki ng repository, workflow na binuo mo, at model na ginagamit nito. Magpatakbo muna ng isang scan sa isang maliit na repository, pagkatapos ay tingnan ang usage page ng provider bago ito gamitin sa mas malaking target.

Simulan ang stack at suriin kung healthy ito

./kritt start

Sinusuri nito ang .env at kahit isang credential, saka pinapatakbo ang docker compose up --build. Mabagal ang unang build dahil ginagawa nito ang frontend, backend, engine, executor view, at database images. Tumatakbo rin ito sa foreground, kaya ihihinto ng pagsasara ng SSH session ang stack. Simulan ito sa loob ng tmux, o patakbuhin ito bilang detached matapos magtagumpay ang unang build. Hindi awtomatikong nakakaligtas sa reboot ang alinman sa mga paraang ito. Kung gusto mong awtomatikong bumalik ang stack pagkatapos mag-restart ang server, direktang magagamit ang pattern ng systemd unit sa pananatiling tumatakbo ang self-hosted agent pagkatapos ng reboot.

docker compose up -d --build
docker compose ps

Dapat ilista ng docker compose ps ang open-kritt-frontend, open-kritt-backend, open-kritt-engine, open-kritt-executor-view, at open-kritt-db. Pagkatapos, suriin kung tumutugon ang backend sa mismong server.

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

Ibig sabihin ng JSON response ay gumagana ang backend. Ibig sabihin ng Failed to connect to 127.0.0.1 port 3002: Connection refused ay hindi ito gumagana, at sasabihin ng docker compose logs backend kung bakit. Ihinto ang lahat gamit ang docker compose down mula sa repository directory.

Isang optional na dagdag: nilo-load ng docker compose exec backend npm run seed ang demo data. Murang paraan ito para tingnan ang interface bago gumastos sa aktuwal na scan.

Ma-access ang UI sa port 5173 gamit ang SSH tunnel

Ang bawat service sa compose file ay naka-bind sa 127.0.0.1 bilang default: ang frontend sa 5173, ang backend sa 3002, ang executor view sa 8090, at ang Postgres sa 5432. Huwag baguhin ang mga binding na iyon. I-forward ang port sa SSH mula sa sarili mong machine.

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

Buksan ang http://localhost:5173 sa local browser habang tumatakbo ang command na iyon. Ibig sabihin ng -N, ipinapasa ng connection ang forward at walang binubuksang shell. Magdagdag ng pangalawang -L 8090:127.0.0.1:8090 sa parehong command kung kailangan mo rin ang executor view.

Maaaring matuksong i-set ang FRONTEND_BIND_ADDRESS=0.0.0.0 at laktawan ang tunnel. Huwag itong gawin. Walang login screen ang backend, kaya maaaring magsimula ng scans at gumamit ng provider credit ang sinumang makaka-access sa page na iyon. May isa pang nakatagong problema: pinoproseso ang published container port bago mailapat ang default policy ng ufw, kaya mukhang tama ang ufw deny 5173 rule pero wala itong bina-block. Ipinapakita sa Mga Docker port na lumalampas sa ufw ang rule chain na nagdudulot nito.

Pag-size ng VPS

Ang default ng ENGINE_MIN_FREE_STORAGE_GB ay 20, at tumatanggi ang engine na magsimula ng bagong per-job scan container kapag bumaba rito ang libreng storage. Nasa iisang disk ang built images, checkout cache, Postgres data, at job workspaces, kaya hindi kailanman nakapagsisimula ng scan ang 20 GB VPS. Ituring ang 40 GB bilang minimum, at dagdagan pa ito kung nag-i-scan ka ng malalaking repository.

Simple arithmetic ang batayan ng memory. Naglalaan ang ENGINE_MEMORY_RESERVE_GB=2 ng memory para sa engine, database, API, at panandaliang overhead, at bawat scan runner ay may reservation at hard cap na ENGINE_SCAN_RUNNER_MEMORY_MB=1536. Kaya nangangailangan ang dalawang worker ng humigit-kumulang 5 GB bago pa tumakbo ang iba. Tinatanggap lamang ng engine ang mga runner na kasya sa natitirang budget, kaya pumipila ang mga scan sa maliit na server sa halip na mabigo. Mas maayos itong failure mode kaysa sa pagpatay ng out-of-memory killer.

Dalawang prune setting ang default na true: ENGINE_AUTO_PRUNE_DOCKER_BUILD_CACHE at ENGINE_AUTO_PRUNE_UNUSED_DOCKER_IMAGES. Pagkatapos makumpleto ang task, inaalis ng engine ang hindi ginagamit na build cache, hindi ginagamit na images, at mga scan container na natigil. Pinapanatili ang mga image na ginagamit ng tumatakbong container, bind mount, database data, credentials, at volumes. Isa pa rin itong dahilan para huwag ibahagi ang host: may pruner na hindi mo na-configure na tumatakbo laban sa Docker daemon na iyon.

Pag-scan sa local repository nang hindi ito inilalabas

Ang LOCAL_REPOS_PATH ay naka-default sa ./local_repos at naka-bind-mount sa backend at engine containers sa /local_repos. Kaya agad na lumilitaw sa loob ng mga container ang repository na inilagay mo sa folder na iyon sa host. Gumamit ng bagong clone, hindi ng working tree. May writable copy ang job container, may root account sa loob nito, at may outbound internet access. Ibig sabihin, maaaring baguhin o ipadala sa labas ng server ang anumang nasa kopyang iyon. Alisin ang mga .env file at private key bago mo kopyahin ang project.

Mga nakukuha mo, at mga hindi mo nakukuha

Makakakuha ka ng mga kandidatong finding na naka-rank. Hindi ka makakakuha ng mga na-verify na vulnerability. Tinutukoy ng ranking at de-duplication ang pagkakasunod-sunod ng iyong triage queue. Hindi nito pinatutunayang totoo ang isang entry. Maaaring subukan ng post-scripts na mag-validate at bumuo ng proof of concept. Ito ang pinakamalakas na signal na iniaalok ng tool. Ngunit kung mabigo ang isang post-script, hindi ito ebidensiyang mali ang finding. Tao pa rin ang kailangang magbasa ng bawat kandidato.

Walang sinasabi ang gabay na ito tungkol sa dami ng totoong bug na nahahanap ng open-kritt, dahil hindi namin ito sinukat. Ang sinumang nagbabanggit ng detection rate para sa iyong codebase ay hindi nagpatakbo nito laban sa iyong codebase. Mag-scan muna ng repository na pamilyar ka na. Ang mga finding na kaya mong suriin mismo ang pinakamurang paraan ng calibration.

Mas mahalaga rito ang authorization kaysa sa karamihan ng self-hosted tool. Nagko-compile at nag-e-execute ng code ang mga agent at kumokonekta sa network, kaya maaaring maapektuhan ng proof-of-concept step ang mga live system. Ituro lamang ito sa code na pagmamay-ari mo o sa code na may kontrata kang i-test. Isulat ang saklaw ng target bago ka magpatakbo ng anuman. Kung kino-configure mo ang ANTHROPIC_API_KEY at ginagamit ang Claude Code engine, naaangkop din sa mga agent na ito ang mga sandboxing practice sa ligtas na pagpapatakbo ng Claude Code sa isang VPS.

FAQ

Bakit kailangan ng open-kritt ng sarili nitong VPS?

Dahil root ang ginagamit ng mga analysis agent nito sa loob ng disposable job container na may writable na kopya ng iyong code at direktang internet access. Naka-mount din ang host Docker socket sa engine service upang makapag-launch ito ng isang container para sa bawat job. Anumang process na makakaabot sa socket na iyon ay maaaring magsimula ng container na nagmo-mount sa filesystem ng host. Kaya dapat ituring ang buong stack na parang root access sa host nito. Sa dedicated VPS, katanggap-tanggap ang trade-off na ito, at wala kang mawawala kung kailangan mong i-rebuild ang server. Sa daily workstation naman, napapailalim sa kaparehong trust boundary ng ini-scan mong code ang iyong SSH keys at browser profiles.

Maaari ko bang i-expose ang port 5173 sa halip na gumamit ng SSH tunnel?

Hindi ito inirerekomenda. Walang application authentication ang backend pag-install nito. Dahil dito, ang port lamang ang naghihiwalay sa internet mula sa iyong findings at provider credit. Itinatali ng compose file ang bawat service sa 127.0.0.1 para sa kadahilanang ito. Patakbuhin ang ssh -N -L 5173:127.0.0.1:5173 you@your-server-ip at mag-browse sa http://localhost:5173 nang lokal. Hindi kapalit ang ufw rule, dahil pinoproseso ang published Docker port bago ilapat ang default policy ng ufw.

Paano ko pipigilan ang open-kritt na gumastos nang higit sa itinakda ko?

Magtakda ng hard limit sa console ng iyong model provider bago ang unang scan, dahil walang sariling budget setting ang open-kritt. Panatilihin ang shipped concurrency defaults sa unang ilang run, ENGINE_WORKER_COUNT=2 at ENGINE_MAX_CONCURRENT_SCANS=1, at tandaan na pinapayagan ng isang provider account ang hanggang 15 sabay-sabay na root model call bilang default, habang maaaring magpatakbo ang isang Codex session ng hanggang limang child agent. Pino-pause ng ENGINE_WORKER_COUNT=0 ang pagkuha ng mga bagong job at ito ang pinakamabilis na paraan para ihinto ito nang lokal.

Aling version ang dapat kong i-check out?

Isang tag, hindi main. Ipinapakita ng git fetch --tags na sinundan ng git tag --list kung ano ang available, at ang v1.3.0, na na-publish noong 4 August 2026, ang pinakabago sa oras ng pagsulat na ito. Kapag nag-pin ka ng version, pareho ang stack na mabubuo kahit makalipas ang ilang buwan. Nagiging sinadya rin ang upgrade, matapos basahin ang release notes, sa halip na maging epekto lamang ng pag-clone sa ibang araw.

Hindi kailanman nagsisimula ang scan. Ano ang dapat kong suriin?

Suriin muna ang available na disk space, dahil hindi magla-launch ang engine ng per-job scan container kapag mas mababa sa ENGINE_MIN_FREE_STORAGE_GB ang free storage. Naka-default ang halagang ito sa 20 GB. Suriin din na hindi 0 ang ENGINE_WORKER_COUNT, dahil pini-pause ng value na iyon ang pagkuha ng mga bagong job. Pagkatapos, tiyaking talagang naka-configure ang model credential sa pamamagitan ng pagpapatakbo ng ./kritt setup, dahil hindi kayang magpatakbo ng scan ng GITHUB_TOKEN nang mag-isa. Tinutukoy ng docker compose logs engine ang dahilan kung bakit nilaktawan nito ang job.