Jinsi ya ku-self-host open-kritt kwenye VPS kwa usalama

Kwa nini u-self-host open-kritt kwenye VPS badala ya laptop yako

Self-host open-kritt kwenye seva unayoweza kuifuta na kuijenga upya. Zana hii huendesha mawakala wake wa uchanganuzi kama root ndani ya kontena za muda za kazi, huipa kila moja nakala inayoweza kuandikwa ya msimbo wako na ufikiaji wa moja kwa moja wa Internet, na huweka Docker socket ya mwenyeji kwenye huduma yake ya injini. Hiyo ni biashara inayokubalika kwenye mashine iliyotengwa kwa kazi hiyo. Ni wazo mbaya kwenye mashine inayohifadhi SSH keys zako.

Sifa nne za usanidi chaguo-msingi huongoza ushauri huo, na zote nne zinatoka kwenye README na faili ya compose ya mradi wenyewe.

Mawakala wamekusudiwa kuwa na nguvu. README inasema mawakala waliozamilishwa na zana huendeshwa kama root ndani ya kontena za muda za kazi, wakiwa na nakala za hazina zinazoweza kuandikwa na ufikiaji wa moja kwa moja wa Internet, ili waweze kusakinisha zana, kukusanya malengo, kuendesha majaribio, na kujenga uthibitisho wa dhana. Skani si linter inayosoma faili. Ni utekelezaji wa msimbo wa kiholela uliouomba.

Injini inashikilia Docker socket. docker-compose.yml huweka Docker socket ya mwenyeji kwenye huduma ya injini, kwa sababu injini hujenga na kuzindua kontena moja la skani kwa kila kazi. Mchakato wowote unaoweza kufikia socket hiyo unaweza kuanzisha kontena inayoweka mfumo wa faili wa mwenyeji. Kwa hivyo injini kimsingi ni root kwenye mwenyeji yeyote anayeiendesha.

Hakuna skrini ya kuingia. Backend inatolewa bila uthibitishaji wa programu. Ufikiaji wa port ni ufikiaji wa matokeo yako na mkopo wako wa mtoa huduma.

Msimbo unaouskani mara nyingi si wako. Kuelekeza mawakala kwenye hazina ya mtu wa tatu kunamaanisha kuendesha ujenzi wa hazina hiyo kwenye mashine yako, kama root, na ufikiaji wa mtandao.

Ikiwa umesoma kwa nini mawakala wa kuandika msimbo wanapaswa kuwa kwenye VM ya muda, huu ni mfano uleule wa vitisho, isipokuwa ni mkali zaidi. Ipe open-kritt VPS isiyo na kitu kingine chochote, na uendeshe VPS hiyo kutoka kwa akaunti tofauti ya mtumiaji mwenye haki ndogo badala ya root.

Kazi halisi ya open-kritt

open-kritt (repostiory yake ni Kritt-ai/open-kritt, yenye leseni ya AGPL-3.0) hugawanya utafiti wa udhaifu (vulnerability research) katika kazi ndogo, huendesha kazi hizo kupitia mawakala wa AI kwa wakati mmoja, kisha huondoa nakala rudufu na kupanga matokeo yaliyopatikana. Unafafanua workflow kama msururu wa prompts zilizolenga lengo mahususi, na kila hatua hupokea muktadha uliopangwa kutoka kwa hatua zilizotangulia. Lengo la skani ni git repository ya mbali au ya ndani. Injini ya uchambuzi ni Codex au Claude Code. Baada ya mgombea (candidate) kujitokeza, hati za hiari za baada ya uchambuzi (post-scripts) zinaweza kujaribu kuithibitisha au kuunda uthibitisho wa dhana (proof of concept).

Unachopata mwishoni ni orodha iliyopangwa ya wagombea. Ichukulie kama foleni ya triage, si kama ripoti.

Unachohitaji kabla ya kuanza

• VPS inayoendesha Ubuntu 24.04, Debian 12 au Rocky Linux 9. Nyaraka za usakinishaji zinaorodhesha mifumo hiyo kama iliyojaribiwa, kwenye x86_64 na ARM64.
• Docker Engine pamoja na Compose plugin.
• Node.js 20 au mpya zaidi kwenye host, kwa sababu ./kritt CLI huendeshwa kwenye host badala ya ndani ya container.
• Mtoa huduma mmoja wa model: akaunti ya Codex, au OPENAI_API_KEY, CODEX_API_KEY, ANTHROPIC_API_KEY au OPENROUTER_API_KEY.
• GITHUB_TOKEN ikiwa tu unapanga kuchanganua hazina (repositories) za faragha. .env.example iliyosafirishwa inasema wazi: token ya GitHub pekee haiwezi kuendesha uchanganuzi.

Sakinisha Docker na Node 20 kwanza

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

Ondoka kwenye mfumo (log out) na uingie tena ili uanachama mpya wa kikundi uanze kufanya kazi, kisha thibitisha kuwa Compose plugin inapatikana.

docker compose version

Mfuatano wa herufi za toleo (version string) unamaanisha kuwa Compose imesakinishwa kama plugin. docker: 'compose' is not a docker command inamaanisha kuwa unatumia binary ya zamani ya pekee ya docker-compose badala yake, na open-kritt inaita docker compose. Uanachama wa kikundi cha docker ni sawa na kuwa root kwenye host, kwa hivyo weka akaunti inayotumia open-kritt pekee kwenye kikundi hicho. Kwa maelezo zaidi ya usanidi huo, tazama kuendesha Docker kwenye VPS.

Ubuntu 24.04 inakuja na Node 18 katika hazina (repository) yake yenyewe, na CLI inajifunga (exit) ikiwa toleo ni chini ya 20. Tumia NodeSource.

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

node -v lazima ichapishe v20. au zaidi. Kwenye Rocky Linux 9, hatua inayolingana na hiyo ni sudo dnf module enable nodejs:20 -y ikifuatiwa na sudo dnf install -y nodejs.

Clone open-kritt na uweke tag ya release iliyothibitiwa

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

main husogea kufuata commit yako. Tag haisogei. Kufikia Agosti 2026, tag ya hivi karibuni ni v1.3.0, iliyochapishwa tarehe 4 Agosti 2026, na git tag --list inaonyesha kilichopo siku unayofanya clone. Kufanya checkout ya tag huacha repository katika hali ya detached HEAD, jambo ambalo ni sahihi hapa: unachukulia clone hii kama deployment iliyofungwa kwenye toleo maalum, si kama branch unayofanyia commit. Ili kuboresha baadaye, soma maelezo ya release, kisha endesha git fetch --tags, fanya checkout ya tag mpya, na uendeshe ./kritt start tena, kwa sababu start hujenga upya images.

Usiendeshe ./kritt ukiwa na sudo. Nyaraka zimeeleza hili wazi. CLI hudhibiti saraka za vitambulisho vya ndani ya mradi chini ya .data/, kwa hivyo ukiendesha kama root, saraka hizo zitamilikiwa na root na uendeshaji wa kawaida unaofuata hautoweza kuziandikia.

Sanidi ufikiaji wa modeli kwa kutumia ./kritt setup

./kritt setup

Amri hii hutengeneza .env kutoka kwa .env.example pale ambapo haipo, huchapisha hali ya kila kitambulisho (credential), na hukuruhusu kukisanidi au kukiondoa. Haiwahi kuchapisha thamani hizo kwenye terminal. Faili zote mbili, .env na faili ya kitambulisho cha injini, huandikwa kwa mode 0600.

Ikiwa unapendelea kufanya hivyo kwa mikono:

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

Kisha hariri ufunguo wa mtoa huduma (provider key) ndani ya .env na uache faili hiyo ikiwa katika mode 0600. Kwa njia yoyote ile, kitambulisho cha mtoa huduma kinachofanya kazi sasa kipo kwenye seva hiyo, jambo ambalo ni sababu nyingine kwa nini seva hiyo haipaswi kuwa na kitu kingine chochote. Tengeneza ufunguo kwa ajili ya mradi huu pekee, ili kuufuta baadaye kusiathiri chochote unachokijali. Kuweka siri mbali na mawakala wa AI kunashughulikia tabia hii kwa mapana zaidi.

Weka kikomo cha matumizi ya mtoa huduma kabla ya scan ya kwanza

open-kritt imeundwa ili kusambaza kazi (fan-out), na unasimamia gharama za usambazaji huo. Mipangilio chaguo-msingi katika .env.example kwenye v1.3.0 ni ya tahadhari: ENGINE_WORKER_COUNT=2, inayoelezewa kwenye faili kama chaguo-msingi la tahadhari kwa mashine ndogo ya 2-vCPU, na ENGINE_MAX_CONCURRENT_SCANS=1. Juu ya hayo kuna ENGINE_WORKERS_PER_ACCOUNT=15, idadi ya juu zaidi ya miito ya root model inayoruhusiwa kwa wakati mmoja kwenye akaunti ya mtoa huduma, na ENGINE_CODEX_MAX_SUBAGENTS_PER_SESSION=5, kwa sababu kipindi cha Codex kinaweza kuendesha hadi mawakala watano (child agents). Ongeza idadi ya wafanyakazi (worker count) kwenye VPS kubwa na idadi ya miito ya model inayofanyika kwa wakati mmoja itaongezeka pia.

Hakuna chochote kwenye hazina (repository) kinachoweka kikomo cha kile unachotumia. Hakuna mpangilio wa bajeti katika .env.example. Masharti ya kusimamisha injini hiyo ni mipaka ya wafanyakazi hao pamoja na ENGINE_HARNESS_TIMEOUT_SECONDS, ambayo chaguo-msingi lake ni sekunde 7200 kwa kila mzunguko wa harness. Kwa hivyo, kikomo lazima kiwekwe kwenye mtoa huduma. Fungua dashibodi ya mtoa huduma wako na uweke kikomo cha kila mwezi (hard monthly limit) kabla ya scan ya kwanza, si baada yake. Kudhibiti gharama za wakala wa AI kwenye VPS inaelezea mipangilio ya kila mtoa huduma.

Kuna breki ya ndani pia. Kuweka ENGINE_WORKER_COUNT=0 husitisha uchukuaji wa kazi mpya, na thamani zilezile za wafanyakazi zinaweza kubadilishwa kwenye skrini ya Settings mara tu stack inapokuwa inaendeshwa.

Mwongozo huu hautoa bei kwa kila scan, kwa sababu gharama inategemea ukubwa wa repository, mtiririko wa kazi unaojenga na model iliyo nyuma yake. Endesha scan moja dhidi ya repository ndogo, kisha soma ukurasa wa matumizi wa mtoa huduma wako kabla ya kuielekeza kwenye kitu chochote kikubwa.

Anzisha stack na uhakikishe kuwa iko sawa

./kritt start

Hiyo hukagua .env na angalau kitambulisho kimoja, kisha huendesha docker compose up --build. Build ya kwanza ni ya polepole, kwa sababu inajenga images za frontend, backend, engine, executor view na database. Pia inaendeshwa mbele (foreground), kwa hivyo kufunga session ya SSH kutasimamisha stack. Ianzishe ndani ya tmux, au iendeshe kwa nyuma (detached) baada ya build ya kwanza kufanikiwa. Hakuna kati ya hizo inayobaki ikiwa hai baada ya reboot, kwa hivyo ikiwa unataka stack iwake tena baada ya seva kuanza upya, muundo wa systemd unit katika kudumisha agent inayojiendesha wakati wa reboot unaweza kutumika moja kwa moja.

docker compose up -d --build
docker compose ps

docker compose ps inapaswa kuorodhesha open-kritt-frontend, open-kritt-backend, open-kritt-engine, open-kritt-executor-view na open-kritt-db. Kisha hakikisha kuwa backend inajibu kwenye seva yenyewe.

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

Jibu la JSON linamaanisha kuwa backend iko juu. Failed to connect to 127.0.0.1 port 3002: Connection refused inamaanisha haiko juu, na docker compose logs backend itaeleza sababu. Simamisha kila kitu kwa kutumia docker compose down ukiwa ndani ya saraka ya repository.

Ziada moja ya hiari: docker compose exec backend npm run seed hupakia data ya demo, ambayo ni njia rahisi ya kuangalia interface kabla ya kutumia gharama yoyote kwa scan halisi.

Fikia UI kwenye port 5173 kupitia SSH tunnel

Kila huduma kwenye faili ya compose hufungwa kwenye 127.0.0.1 kwa chaguomsingi: frontend kwenye 5173, backend kwenye 3002, mwonekano wa executor kwenye 8090 na Postgres kwenye 5432. Acha vifungo hivyo kama vilivyo na uelekeze port hiyo kupitia SSH kutoka kwenye mashine yako.

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

Fungua http://localhost:5173 kwenye kivinjari chako cha ndani wakati amri hiyo ikiwa inaendeshwa. -N inamaanisha kuwa muunganisho hubeba uelekezaji huo na haufungui shell. Ongeza -L 8090:127.0.0.1:8090 ya pili kwenye amri hiyo hiyo pale unapotaka mwonekano wa executor pia.

Jaribu ni kuweka FRONTEND_BIND_ADDRESS=0.0.0.0 na kuruka hatua ya tunnel. Usifanye hivyo. Backend haina skrini ya kuingia, kwa hivyo mtu yeyote anayefikia ukurasa huo anaweza kuanza skani na kutumia mkopo wako wa mtoa huduma. Kuna mtego wa pili chini yake: port ya container iliyochapishwa hushughulikiwa kabla ya sera ya chaguomsingi ya ufw kutumika, kwa hivyo sheria ya ufw deny 5173 inaonekana kuwa sahihi lakini haizuii chochote. Docker ports that bypass ufw inaonyesha mnyororo wa sheria unaosababisha hali hiyo.

Kukadiria ukubwa wa VPS

ENGINE_MIN_FREE_STORAGE_GB ina thamani chaguo-msingi ya 20, na injini hukataa kuanzisha container mpya ya scan kwa kila kazi wakati nafasi ya diski iliyo wazi inapungua chini ya thamani hiyo. Picha zilizojengwa (built images), cache ya checkout, data ya Postgres na nafasi za kazi (job workspaces) zote hukaa kwenye diski moja, kwa hivyo VPS ya 20 GB haitaanzisha scan yoyote. Zingatia 40 GB kama kiwango cha chini, na ongeza zaidi ikiwa unachanganua (scan) hazina (repositories) kubwa.

Kumbukumbu hufuata hesabu rahisi. ENGINE_MEMORY_RESERVE_GB=2 hutenga kumbukumbu kwa ajili ya injini, database, API na matumizi mengine madogo, na kila scan runner hubeba nafasi iliyotengwa na kikomo cha juu cha ENGINE_SCAN_RUNNER_MEMORY_MB=1536. Kwa hivyo, wafanyakazi (workers) wawili wanahitaji takriban 5 GB kabla ya kitu kingine chochote kuendeshwa. Injini hukubali tu runners wanaotoshea kwenye bajeti iliyobaki, kwa hivyo kwenye mashine ndogo, scans hupangwa kwenye foleni badala ya kufeli, hali ambayo ni bora zaidi kuliko kuua mchakato kwa sababu ya kukosa kumbukumbu (out-of-memory killer).

Mipangilio miwili ya kusafisha (prune) imewekwa kuwa true kwa chaguo-msingi: ENGINE_AUTO_PRUNE_DOCKER_BUILD_CACHE na ENGINE_AUTO_PRUNE_UNUSED_DOCKER_IMAGES. Baada ya kazi kukamilika, injini huondoa cache ya ujenzi isiyotumika, picha zisizotumika na containers za scan zilizosimamishwa. Picha zinazorejelewa na container inayoendelea, bind mounts, data ya database, vitambulisho na volumes huhifadhiwa. Hii ni sababu nyingine ya kutoshiriki host: mchakato wa kusafisha (pruner) ambao hukukuusanidi unafanya kazi dhidi ya Docker daemon hiyo.

Kuchanganua hazina ya ndani bila kuivujisha

LOCAL_REPOS_PATH hutumia ./local_repos kama chaguo-msingi na huwekwa kupitia bind-mount kwenye kontena za backend na engine katika /local_repos, kwa hivyo hazina unayoiweka kwenye folda hiyo kwenye seva mwenyeji huonekana ndani ya kontena mara moja. Tumia clone mpya, si folda yako ya kazi. Kontena la kazi hupata nakala inayoweza kuandikwa, ina root ndani yake, na ina uwezo wa kufikia Internet, jambo linalomaanisha kuwa chochote kilichomo kwenye nakala hiyo kinaweza kubadilishwa au kutumwa nje ya seva. Ondoa faili za .env na funguo za siri (private keys) kabla ya kunakili mradi ndani ya folda hiyo.

Unachopata na usichopata

Unapata orodha ya matokeo yaliyopangwa kulingana na kipaumbele. Hupati udhaifu uliothibitishwa. Upangaji na uondoaji wa marudio huamua mpangilio wa foleni yako ya triage. Haya hayathibitishi kuwa matokeo ni ya kweli. Hati za baada ya uchanganuzi (post-scripts) zinaweza kujaribu uthibitishaji na kuunda uthibitisho wa dhana (proof of concept), na hiyo ndiyo ishara yenye nguvu zaidi inayotolewa na zana hii, lakini hati inayoshindwa si ushahidi kwamba matokeo hayo ni ya uongo. Mwanadamu bado anapaswa kusoma kila matokeo yanayopendekezwa.

Mwongozo huu hautoi madai yoyote kuhusu idadi ya hitilafu halisi ambazo open-kritt inazipata, kwa sababu hatujapima hilo. Mtu yeyote anayenukuu kiwango cha ugunduzi kwa ajili ya codebase yako haijawahi kuiendesha dhidi ya codebase yako. Changanua hazina (repository) unayoijua vyema kwanza: matokeo unayoweza kuyahukumu mwenyewe ndiyo njia rahisi zaidi ya kurekebisha zana.

Idhini ni muhimu zaidi hapa kuliko ilivyo kwa zana nyingi zinazojiendesha (self-hosted). Mawakala hawa hukusanya (compile) na kutekeleza msimbo na kufikia mtandao, kwa hivyo hatua ya uthibitisho wa dhana inaweza kugusa mifumo iliyo hai. Ielekeze kwenye msimbo unaomiliki au ambao umepewa mkataba wa kuujaribu, na uandike wigo wa lengo (target scope) kabla ya kuendesha chochote. Ikiwa utasanidi ANTHROPIC_API_KEY na kutumia injini ya Claude Code, mazoea ya kutumia sanduku la mchanga (sandboxing) katika kuendesha Claude Code kwa usalama kwenye VPS yanawahusu mawakala hawa pia.

FAQ

Kwa nini open-kritt inahitaji VPS yake yenyewe?

Kwa sababu mawakala wake wa uchanganuzi huendeshwa kama root ndani ya container za muda za kazi, wakiwa na nakala za msimbo wako zinazoweza kuandikika na ufikiaji wa moja kwa moja wa Internet, na kwa sababu huduma ya injini hu-mount Docker socket ya seva pangishi ili iweze kuanzisha container moja kwa kila kazi. Mchakato wowote unaofikia socket hiyo unaweza kuanzisha container inayoweza ku-mount mfumo wa faili wa seva pangishi, kwa hivyo stack nzima inapaswa kuchukuliwa kama root kwenye seva yake. Kwenye VPS iliyojitolea, huu ni ubadilishaji unaokubalika, na kujenga upya seva hakukugharimu chochote. Kwenye workstation yako ya kila siku, hii huweka funguo zako za SSH na maelezo ya kivinjari ndani ya mipaka ileile ya uaminifu kama msimbo unaouchanganua.

Je, ninaweza kufungua port 5173 badala ya kutumia SSH tunnel?

Hupaswi kufanya hivyo. Backend inatolewa bila uthibitishaji wa programu, kwa hivyo port ndiyo kitu pekee kilichopo kati ya Internet na matokeo yako pamoja na mkopo wa mtoa huduma. Faili ya compose hufunga kila huduma kwenye 127.0.0.1 kwa sababu hiyo. Endesha ssh -N -L 5173:127.0.0.1:5173 you@your-server-ip na uvinjari kwenda http://localhost:5173 ndani ya mfumo wako. Kanuni ya ufw si mbadala, kwa sababu port ya Docker iliyochapishwa hushughulikiwa kabla ya sera ya kawaida ya ufw kutumika.

Ninawezaje kuzuia open-kritt isitumie pesa nyingi kuliko nilivyopanga?

Weka kikomo kigumu kwenye dashibodi ya mtoa huduma wako wa modeli kabla ya uchanganuzi wa kwanza, kwa sababu open-kritt haina mpangilio wa bajeti wake wenyewe. Dumisha mipangilio chaguo-msingi ya concurrency iliyotolewa kwa majaribio ya kwanza, ENGINE_WORKER_COUNT=2 na ENGINE_MAX_CONCURRENT_SCANS=1, na kumbuka kuwa akaunti moja ya mtoa huduma inaruhusu hadi simu 15 za modeli za root kwa wakati mmoja, wakati kikao cha Codex kinaweza kuendesha hadi mawakala watoto watano. ENGINE_WORKER_COUNT=0 husitisha uchukuaji wa kazi mpya na ndiyo njia ya haraka zaidi ya kusimamisha shughuli ndani ya mfumo.

Ni toleo gani ninalopaswa kuchagua?

Tumia tag, kamwe usitumie main. git fetch --tags ikifuatiwa na git tag --list huonyesha kile kinachopatikana, na v1.3.0, iliyochapishwa tarehe 4 Agosti 2026, ndiyo mpya zaidi wakati wa kuandika mwongozo huu. Kuweka toleo maalum (pinning) kunamaanisha kuwa ujenzi upya miezi kadhaa baadaye utazalisha stack ileile, na hufanya uboreshaji kuwa uamuzi unaoufanya baada ya kusoma maelezo ya toleo badala ya kuwa matokeo ya kusakinisha kwa siku tofauti.

Uchanganuzi hauanzi kamwe. Nini ninapaswa kuangalia?

Angalia nafasi ya diski kwanza, kwa sababu injini haitaanzisha container ya uchanganuzi kwa kila kazi wakati hifadhi iliyo wazi iko chini ya ENGINE_MIN_FREE_STORAGE_GB, ambayo ni 20 GB kwa chaguo-msingi. Kisha angalia kuwa ENGINE_WORKER_COUNT si 0, kwa sababu thamani hiyo husitisha uchukuaji wa kazi mpya. Kisha thibitisha kuwa kitambulisho cha modeli kimesanidiwa kikamilifu kwa kuendesha ./kritt setup, kwa sababu GITHUB_TOKEN pekee haiwezi kuendesha uchanganuzi. docker compose logs engine hutaja sababu iliyoifanya iruke kazi hiyo.