Open-kritt zelf hosten op een VPS: handleiding

Waarom open-kritt zelf hosten op een VPS en niet op uw laptop

Host open-kritt op een server die u kunt vernietigen en opnieuw kunt opbouwen. De tool voert zijn analyse-agents uit als root binnen tijdelijke job-containers, geeft elke container een beschrijfbare kopie van uw code en directe internettoegang, en koppelt de Docker-socket van de host aan zijn engine-service. Dat is een acceptabele afweging op een machine die specifiek voor deze taak is ingericht. Het is een onverstandige keuze op de machine waar uw SSH-keys op staan.

Vier eigenschappen van de standaardconfiguratie vormen de basis voor dit advies, en alle vier zijn afkomstig uit de README en het compose-bestand van het project zelf.

De agents zijn ontworpen om krachtig te zijn. De README stelt dat agents met tool-ondersteuning als root draaien binnen tijdelijke job-containers, voorzien van beschrijfbare kopieën van repositories en directe internettoegang, zodat ze tools kunnen installeren, targets kunnen compileren, tests kunnen uitvoeren en proofs of concept kunnen bouwen. Een scan is geen linter die alleen bestanden leest. Het is willekeurige code-executie waar u zelf om heeft gevraagd. Die internettoegang werkt twee kanten op: alles wat een agent ophaalt tijdens het onderzoeken van een target is niet-vertrouwde tekst die in de prompt terechtkomt; dit is hetzelfde risico dat u neemt wanneer u een agent zelf laat zoeken op het web.

De engine beheert de Docker-socket. docker-compose.yml koppelt de Docker-socket van de host aan de engine-service, omdat de engine per job één scan-container bouwt en start. Elk proces dat toegang heeft tot die socket kan een container starten die het bestandssysteem van de host koppelt. De engine heeft daardoor in feite root-rechten op de host waarop deze draait.

Er is geen inlogscherm. De backend wordt geleverd zonder applicatie-authenticatie. Toegang tot de poort betekent toegang tot uw resultaten en uw provider-tegoed.

De code die u scant is vaak niet van u. Wanneer u agents naar een repository van derden wijst, betekent dit dat u de build van die repository op uw eigen machine uitvoert, als root, met netwerktoegang.

Als u heeft gelezen waarom coding agents in een tijdelijke VM thuishoren, dan is dit hetzelfde dreigingsmodel, maar dan sterker. Geef open-kritt een VPS waar verder niets op staat, en beheer die VPS vanuit een afzonderlijk gebruikersaccount met minimale rechten in plaats van als root.

Wat open-kritt daadwerkelijk doet

open-kritt (de repository is Kritt-ai/open-kritt, gelicentieerd onder AGPL-3.0) splitst kwetsbaarheidsonderzoek op in kleine taken, voert deze taken parallel uit via AI-agents en ontdubbelt en rangschikt vervolgens de resultaten. U definieert een workflow als een keten van gerichte prompts, waarbij elke stap gestructureerde context ontvangt van de voorgaande stappen. Het scandoel is een externe of lokale git-repository. De analyse-engine is Codex of Claude Code. Nadat een kandidaat-kwetsbaarheid is gevonden, kunnen optionele post-scripts proberen deze te valideren of een proof of concept te bouwen.

Wat u aan het einde ontvangt, is een gerangschikte lijst met kandidaten. Behandel dit als een triage-wachtrij, niet als een definitief rapport.

Vereisten voor aanvang

• Een VPS met Ubuntu 24.04, Debian 12 of Rocky Linux 9. De installatiedocumentatie vermeldt deze als geteste distributies, op zowel x86_64 als ARM64.
• Docker Engine met de Compose-plugin.
• Node.js 20 of nieuwer op de host, aangezien de ./kritt CLI op de host draait in plaats van in een container.
• Eén modelprovider: een Codex-login, of OPENAI_API_KEY, CODEX_API_KEY, ANTHROPIC_API_KEY of OPENROUTER_API_KEY.
• GITHUB_TOKEN alleen als u van plan bent om private repositories te scannen. De meegeleverde .env.example stelt dit duidelijk: een GitHub-token alleen is onvoldoende om scans uit te voeren.

Installeer eerst Docker en Node 20

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

Meld u af en weer aan zodat het nieuwe groepslidmaatschap wordt toegepast, en bevestig vervolgens dat de Compose-plugin aanwezig is.

docker compose version

Een versiereeks betekent dat Compose als plugin is geïnstalleerd. docker: 'compose' is not a docker command betekent dat u in plaats daarvan het oude zelfstandige docker-compose-binarybestand heeft, en open-kritt roept docker compose aan. Lidmaatschap van de docker-groep staat gelijk aan root-toegang op de host; voeg daarom alleen het account toe dat open-kritt uitvoert. Zie Docker draaien op een VPS voor een uitgebreidere uitleg van die configuratie.

Ubuntu 24.04 levert Node 18 in de eigen repository, en de CLI sluit af bij alles lager dan 20. Gebruik NodeSource.

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

node -v moet v20. of hoger weergeven. Op Rocky Linux 9 is het equivalent sudo dnf module enable nodejs:20 -y gevolgd door sudo dnf install -y nodejs.

Kloon open-kritt en pin een getagde release

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

main verplaatst zich onder u. Een tag doet dat niet. Per augustus 2026 is de nieuwste tag v1.3.0, gepubliceerd op 4 augustus 2026, en git tag --list toont wat er bestaat op de dag dat u kloont. Het uitchecken van een tag laat de repository achter in een detached HEAD-status, wat hier correct is: u behandelt deze kloon als een vastgezette deployment, niet als een branch waaraan u commits toevoegt. Om later te upgraden, leest u de release notes, voert u git fetch --tags uit, checkt u de nieuwe tag uit en voert u ./kritt start opnieuw uit, aangezien start de images opnieuw bouwt.

Voer ./kritt niet uit met sudo. De documentatie is hier expliciet over. De CLI beheert project-lokale credential-mappen onder .data/, dus een uitvoering als root zorgt ervoor dat die mappen eigendom worden van root en de volgende normale uitvoering kan er niet naar schrijven.

Toegang tot het model configureren met ./kritt setup

./kritt setup

Het commando maakt .env aan vanuit .env.example als dit bestand nog niet bestaat, toont de status van elke credential en stelt u in staat deze in of uit te schakelen. De waarden worden nooit in de terminal getoond. Zowel .env als het credential-bestand van de engine worden geschreven met modus 0600.

Als u dit liever handmatig doet:

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

Bewerk vervolgens de provider-key in .env en zorg dat het bestand de rechten 0600 behoudt. Hoe dan ook, er bevindt zich nu een werkende provider-credential op de server; dit is een extra reden waarom de server geen andere taken zou moeten uitvoeren. Maak een key aan die uitsluitend voor dit project is bedoeld, zodat het intrekken ervan later geen andere zaken verstoort. Geheimen buiten het bereik van AI-agents houden behandelt de bredere werkwijze hiervoor.

Stel een uitgavenlimiet in bij de provider vóór de eerste scan

open-kritt is ontworpen om taken te spreiden, en voor deze spreiding betaalt u. De standaardinstellingen in .env.example bij v1.3.0 zijn conservatief: ENGINE_WORKER_COUNT=2, in het bestand omschreven als een conservatieve standaard voor een kleine 2-vCPU machine, en ENGINE_MAX_CONCURRENT_SCANS=1. Daarboven staat ENGINE_WORKERS_PER_ACCOUNT=15, het maximale aantal gelijktijdige root-modelaanroepen dat is toegestaan op één provideraccount, en ENGINE_CODEX_MAX_SUBAGENTS_PER_SESSION=5, omdat een Codex-sessie tot vijf onderliggende agents kan uitvoeren. Verhoogt u het aantal workers op een grotere VPS, dan stijgt het aantal actieve modelaanroepen daarmee mee.

Niets in de repository begrenst uw uitgaven. Er is geen budgetinstelling in .env.example. De eigen stopcondities van de engine zijn die worker-limieten plus ENGINE_HARNESS_TIMEOUT_SECONDS, die standaard op 7200 seconden per harness-run staat. Het plafond moet daarom bij de provider worden ingesteld. Open de console van uw provider en stel een harde maandelijkse limiet in vóór de eerste scan, niet erna. Beheersing van de kosten van een AI-agent op een VPS doorloopt de instellingen per provider.

Er is ook een lokale rem. Het instellen van ENGINE_WORKER_COUNT=0 pauzeert het oppakken van nieuwe taken, en dezelfde worker-waarden kunnen in het instellingenscherm worden gewijzigd zodra de stack draait.

Deze handleiding noemt geen prijs per scan, omdat de kosten afhangen van de grootte van de repository, de workflow die u bouwt en het model dat erachter zit. Voer één scan uit op één kleine repository en bekijk vervolgens de verbruikspagina van uw provider voordat u de tool op iets groots loslaat.

De stack starten en de status controleren

./kritt start

Dit controleert .env en ten minste één inloggegeven, waarna docker compose up --build wordt uitgevoerd. De eerste build duurt lang, omdat de images voor de frontend, backend, engine, executor view en database worden gebouwd. Het proces draait bovendien op de voorgrond; het sluiten van de SSH-sessie stopt de stack daarom. Start deze binnen tmux, of start de stack op de achtergrond zodra de eerste build is geslaagd. Geen van beide methoden overleeft een reboot uit zichzelf. Als u wilt dat de stack na een herstart van de server automatisch weer opkomt, is het systemd-unitpatroon in een self-hosted agent actief houden na reboots direct toepasbaar.

docker compose up -d --build
docker compose ps

docker compose ps hoort open-kritt-frontend, open-kritt-backend, open-kritt-engine, open-kritt-executor-view en open-kritt-db weer te geven. Controleer vervolgens of de backend antwoordt op de server zelf.

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

Een JSON-antwoord betekent dat de backend actief is. Failed to connect to 127.0.0.1 port 3002: Connection refused betekent dat dit niet het geval is, en docker compose logs backend geeft de reden daarvan aan. Stop alles met docker compose down vanuit de repository-directory.

Een optionele extra: docker compose exec backend npm run seed laadt demogegevens. Dit is een eenvoudige manier om de interface te bekijken voordat u tijd of middelen investeert in een echte scan.

Toegang tot de UI op poort 5173 via een SSH-tunnel

Elke service in het compose-bestand bindt standaard aan 127.0.0.1: de frontend op 5173, de backend op 3002, de executor-view op 8090 en Postgres op 5432. Wijzig deze bindingen niet en forward de poort via SSH vanaf uw eigen machine.

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

Open http://localhost:5173 in uw lokale browser terwijl dit commando actief is. -N betekent dat de verbinding de forward uitvoert zonder shell-toegang. Voeg een tweede -L 8090:127.0.0.1:8090 toe aan hetzelfde commando als u ook de executor-view wilt gebruiken.

De verleiding is groot om FRONTEND_BIND_ADDRESS=0.0.0.0 in te stellen en de tunnel over te slaan. Doe dit niet. De backend heeft geen inlogscherm, dus iedereen die die pagina bereikt, kan scans starten en uw provider-tegoed verbruiken. Er is nog een tweede valkuil: een gepubliceerde containerpoort wordt afgehandeld voordat het standaardbeleid van ufw wordt toegepast, waardoor een ufw deny 5173-regel correct lijkt maar niets blokkeert. Docker-poorten die ufw omzeilen toont de regelketen die dit veroorzaakt.

De VPS dimensioneren

ENGINE_MIN_FREE_STORAGE_GB staat standaard op 20, en de engine weigert een nieuwe scan-container per taak te starten wanneer de vrije opslagruimte hieronder zakt. De gebouwde images, de checkout-cache, de Postgres-data en de werkmappen van de taken bevinden zich allemaal op dezelfde schijf, waardoor een VPS van 20 GB nooit een scan zal starten. Hanteer 40 GB als ondergrens en wijs meer toe als u grote repositories scant.

Geheugengebruik volgt een eenvoudige rekensom. ENGINE_MEMORY_RESERVE_GB=2 houdt geheugen achter voor de engine, de database, de API en kortstondige overhead, en elke scan-runner heeft een reservering en een harde limiet van ENGINE_SCAN_RUNNER_MEMORY_MB=1536. Twee workers vereisen daarom ongeveer 5 GB voordat er iets anders draait. De engine laat alleen de runners toe die in het resterende budget passen; op een kleine machine komen scans dus in de wachtrij te staan in plaats van te falen, wat een veel betere foutmodus is dan de out-of-memory killer.

Twee opschooninstellingen staan standaard op true: ENGINE_AUTO_PRUNE_DOCKER_BUILD_CACHE en ENGINE_AUTO_PRUNE_UNUSED_DOCKER_IMAGES. Nadat een taak is voltooid, verwijdert de engine ongebruikte build-cache, ongebruikte images en gestopte scan-containers. Images waarnaar wordt verwezen door een draaiende container, bind mounts, database-data, inloggegevens en volumes blijven behouden. Dit is nog een reden om de host niet te delen: er draait een pruner die u niet zelf heeft geconfigureerd tegen die Docker-daemon.

Een lokale repository scannen zonder dat deze uitlekt

LOCAL_REPOS_PATH gebruikt standaard ./local_repos en wordt via een bind-mount gekoppeld aan de backend- en engine-containers op /local_repos. Een repository die u in die map op de host plaatst, is daardoor direct zichtbaar binnen de containers. Gebruik een verse clone, niet uw actieve working tree. De job-container krijgt een beschrijfbare kopie, beschikt over root-rechten en heeft toegang tot het internet. Dit betekent dat alles wat zich in die kopie bevindt, kan worden gewijzigd of naar buiten kan worden verstuurd. Verwijder .env-bestanden en privésleutels voordat u een project kopieert.

Wat u krijgt en wat u niet krijgt

U ontvangt gerangschikte kandidaat-bevindingen. U krijgt geen geverifieerde kwetsbaarheden. Rangschikking en ontdubbeling bepalen de volgorde van uw triage-wachtrij. Ze bewijzen niet dat een vermelding daadwerkelijk bestaat. Post-scripts kunnen validatie proberen en een proof-of-concept opbouwen; dit is het sterkste signaal dat de tool biedt. Een post-script dat faalt, is echter geen bewijs dat de bevinding onjuist is. Een persoon beoordeelt nog steeds elke kandidaat.

Deze handleiding doet geen uitspraken over hoeveel echte bugs open-kritt vindt, omdat we dit niet hebben gemeten. Iedereen die een detectiepercentage voor uw codebase noemt, heeft de tool niet op uw codebase uitgevoerd. Scan eerst een repository die u al goed kent: bevindingen die u zelf kunt beoordelen, zijn de goedkoopste manier van kalibratie.

Autorisatie is hier belangrijker dan bij de meeste zelfgehoste tools. De agents compileren en voeren code uit en bereiken het netwerk, dus een proof-of-concept-stap kan live systemen raken. Wijs de tool alleen aan op code die uw eigendom is of die u contractueel mag testen, en leg het doelbereik vast voordat u iets uitvoert. Als u ANTHROPIC_API_KEY configureert en de Claude Code engine gebruikt, zijn de sandboxing-gewoonten in veilig uitvoeren van Claude Code op een VPS ook van toepassing op deze agents.

FAQ

Waarom heeft open-kritt een eigen VPS nodig?

Omdat de analyse-agents als root draaien in tijdelijke job-containers met beschrijfbare kopieën van uw code en directe internettoegang, en omdat de engine-service de Docker-socket van de host mount om per job een container te kunnen starten. Elk proces dat die socket bereikt, kan een container starten die het bestandssysteem van de host mount; de gehele stack moet daarom als root op de host worden beschouwd. Op een toegewezen VPS is dit een acceptabel risico en kost het opnieuw opbouwen van de server niets. Op uw dagelijkse werkstation plaatst dit uw SSH-sleutels en browserprofielen binnen dezelfde vertrouwensgrens als de code die u scant.

Kan ik poort 5173 openstellen in plaats van een SSH-tunnel te gebruiken?

Dat moet u niet doen. De backend wordt geleverd zonder applicatie-authenticatie, waardoor de poort de enige barrière is tussen het internet en uw bevindingen en provider-tegoed. Het compose-bestand bindt om die reden elke service aan 127.0.0.1. Voer ssh -N -L 5173:127.0.0.1:5173 you@your-server-ip uit en navigeer lokaal naar http://localhost:5173. Een ufw-regel is geen vervanging, omdat een gepubliceerde Docker-poort wordt afgehandeld voordat het standaardbeleid van ufw van toepassing is.

Hoe voorkom ik dat open-kritt meer uitgeeft dan gepland?

Stel vóór de eerste scan een harde limiet in via de console van uw modelprovider, aangezien open-kritt zelf geen budgetinstelling heeft. Houd voor de eerste paar runs de meegeleverde standaardwaarden voor gelijktijdigheid aan, ENGINE_WORKER_COUNT=2 en ENGINE_MAX_CONCURRENT_SCANS=1, en onthoud dat één provider-account standaard tot 15 gelijktijdige root-modelaanroepen toestaat, terwijl een Codex-sessie tot vijf onderliggende agents kan draaien. ENGINE_WORKER_COUNT=0 pauzeert het oppakken van nieuwe jobs en is de snelste lokale stopmethode.

Welke versie moet ik uitchecken?

Een tag, nooit main. git fetch --tags gevolgd door git tag --list toont wat beschikbaar is, en v1.3.0, gepubliceerd op 4 augustus 2026, is de nieuwste versie op het moment van schrijven. Vastpinnen betekent dat een rebuild maanden later dezelfde stack oplevert, en het maakt upgraden een beslissing die u neemt na het lezen van de release notes, in plaats van een bijwerking van het klonen op een andere dag.

Een scan start nooit. Wat moet ik controleren?

Controleer eerst de vrije schijfruimte, aangezien de engine geen scan-container per job start wanneer de vrije opslag onder ENGINE_MIN_FREE_STORAGE_GB komt, wat standaard 20 GB is. Controleer vervolgens of ENGINE_WORKER_COUNT niet 0 is, omdat die waarde het oppakken van nieuwe jobs pauzeert. Bevestig daarna of een model-credential daadwerkelijk is geconfigureerd door ./kritt setup uit te voeren, omdat een GITHUB_TOKEN op zichzelf geen scans kan uitvoeren. docker compose logs engine benoemt de reden waarom de job werd overgeslagen.