open-kritt auf einem VPS selbst hosten

Warum Sie open-kritt auf einem VPS und nicht auf Ihrem Laptop selbst hosten

Hosten Sie open-kritt auf einem Server, den Sie zerstören und neu aufbauen können. Das Tool führt seine Analyseagenten als root in kurzlebigen Job-Containern aus, stellt jedem Agenten eine beschreibbare Kopie Ihres Codes bereit und gewährt direkten Internetzugriff. Außerdem bindet es den Docker-Socket des Hosts in seinen Engine-Dienst ein. Auf einem ausschließlich für diese Aufgabe vorgesehenen System ist das ein vertretbarer Kompromiss. Auf dem Rechner, auf dem Ihre SSH-Schlüssel liegen, ist es ein schlechter Kompromiss.

Vier Eigenschaften der Standardkonfiguration führen zu dieser Empfehlung. Alle vier stammen aus der README und der Compose-Datei des Projekts.

Die Agenten sollen weitreichende Berechtigungen haben. Die README beschreibt tool-fähige Agenten, die als root in kurzlebigen Job-Containern ausgeführt werden. Sie erhalten beschreibbare Kopien des Repositorys und direkten Internetzugriff. Dadurch können sie Tools installieren, Ziele kompilieren, Tests ausführen und Proofs of Concept erstellen. Ein Scan ist kein Linter, der Dateien liest. Er führt beliebigen Code aus, den Sie ausdrücklich angefordert haben. Der Internetzugriff wirkt in beide Richtungen: Alles, was ein Agent bei der Untersuchung eines Ziels abruft, ist nicht vertrauenswürdiger Text, der in seinen Prompt gelangt. Derselben Gefährdung setzen Sie sich aus, wenn Sie einem Agenten eine eigene Websuche überlassen.

Die Engine besitzt den Docker-Socket. docker-compose.yml bindet den Docker-Socket des Hosts in den Engine-Dienst ein, weil die Engine für jeden Auftrag einen eigenen Scan-Container erstellt und startet. Jeder Prozess, der diesen Socket erreichen kann, kann einen Container starten und darin das Dateisystem des Hosts einbinden. Daher hat die Engine auf dem Host, auf dem sie ausgeführt wird, effektiv root-Berechtigungen.

Es gibt keine Anmeldemaske. Das Backend wird ohne Anwendungsauthentifizierung ausgeliefert. Der Zugriff auf den Port ermöglicht den Zugriff auf Ihre Ergebnisse und auf Ihr Guthaben beim Provider.

Der analysierte Code gehört häufig nicht Ihnen. Wenn Sie Agenten auf ein Repository eines Dritten ansetzen, wird der Build dieses Repositorys auf Ihrem Rechner als root und mit Netzwerkzugriff ausgeführt.

Wenn Sie gelesen haben, warum Coding-Agenten in eine kurzlebige VM gehören, kennen Sie dasselbe Bedrohungsmodell, nur mit höherem Risiko. Stellen Sie open-kritt einen VPS bereit, auf dem sich nichts anderes befindet, und verwalten Sie diesen VPS über ein separates Benutzerkonto mit den geringsten erforderlichen Berechtigungen statt über root.

Was open-kritt tatsächlich macht

open-kritt (das Repository ist Kritt-ai/open-kritt und steht unter der Lizenz AGPL-3.0) zerlegt die Schwachstellenforschung in kleine Aufgaben, führt diese Aufgaben parallel über mehrere KI-Agenten aus und entfernt anschließend Duplikate aus den Ergebnissen und bewertet sie. Sie definieren einen Workflow als Kette fokussierter Prompts. Jeder Schritt erhält strukturierten Kontext aus den vorherigen Schritten. Das Scan-Ziel ist ein entferntes oder lokales Git-Repository. Als Analyse-Engine dient Codex oder Claude Code. Sobald ein Kandidat gefunden wurde, können optionale Post-Skripte versuchen, ihn zu validieren oder einen Proof of Concept zu erstellen.

Am Ende erhalten Sie eine nach Relevanz sortierte Liste von Kandidaten. Behandeln Sie sie als Triage-Warteschlange und nicht als Bericht.

Was Sie vor dem Start benötigen

• Einen VPS mit Ubuntu 24.04, Debian 12 oder Rocky Linux 9. Die Installationsdokumentation führt diese als getestete Distributionen für x86_64 und ARM64 auf.
• Docker Engine mit dem Compose-Plugin.
• Node.js 20 oder neuer auf dem Host, weil die ./kritt-CLI auf dem Host und nicht innerhalb eines Containers ausgeführt wird.
• Einen Modellanbieter: ein Codex-Login oder OPENAI_API_KEY, CODEX_API_KEY, ANTHROPIC_API_KEY oder OPENROUTER_API_KEY.
• GITHUB_TOKEN nur, wenn Sie private Repositorys scannen möchten. Im mitgelieferten .env.example steht dies eindeutig: Ein GitHub-Token allein kann keine Scans ausführen.

Docker und Node 20 zuerst installieren

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

Melden Sie sich ab und wieder an, damit die neue Gruppenmitgliedschaft wirksam wird. Prüfen Sie anschließend, ob das Compose-Plugin vorhanden ist.

docker compose version

Eine Versionszeichenfolge bedeutet, dass Compose als Plugin installiert ist. docker: 'compose' is not a docker command bedeutet, dass stattdessen die alte eigenständige docker-compose-Binärdatei vorhanden ist und open-kritt docker compose aufruft. Die Mitgliedschaft in der Gruppe docker entspricht Root-Rechten auf dem Host. Nehmen Sie daher nur das Konto auf, mit dem open-kritt ausgeführt wird. Eine ausführlichere Beschreibung dieser Einrichtung finden Sie unter Docker auf einem VPS ausführen.

Ubuntu 24.04 stellt in seinem eigenen Repository Node 18 bereit. Die CLI wird jedoch bei jeder Version unter 20 beendet. Verwenden Sie NodeSource.

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

node -v muss v20. oder höher ausgeben. Unter Rocky Linux 9 verwenden Sie entsprechend sudo dnf module enable nodejs:20 -y und anschließend sudo dnf install -y nodejs.

Open-kritt klonen und einen getaggten Release festsetzen

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

main bewegt sich mit. Ein Tag tut das nicht. Im August 2026 ist der neueste Tag v1.3.0, veröffentlicht am 4. August 2026. git tag --list zeigt, welche Version am Tag des Klonens vorhanden ist. Wenn Sie einen Tag auschecken, befindet sich das Repository im Zustand detached HEAD. Das ist hier korrekt: Sie verwenden diesen Klon als festgesetzte Bereitstellung und nicht als Branch, in den Sie Commits schreiben. Lesen Sie für ein späteres Upgrade die Release-Hinweise. Führen Sie anschließend git fetch --tags aus, checken Sie den neuen Tag aus und führen Sie erneut ./kritt start aus, weil start die Images neu erstellt.

Führen Sie ./kritt nicht zusammen mit sudo aus. Die Dokumentation weist ausdrücklich darauf hin. Die CLI verwaltet projektspezifische Anmeldedatenverzeichnisse unter .data/. Wenn der Befehl als root ausgeführt wird, gehören diese Verzeichnisse anschließend root. Beim nächsten normalen Aufruf können sie dann nicht beschrieben werden.

Zugriff auf Modelle mit ./kritt setup konfigurieren

./kritt setup

Der Befehl erstellt .env aus .env.example, falls die Datei noch nicht vorhanden ist. Er zeigt den Status jeder Zugangsdaten an und ermöglicht, sie zu setzen oder zu entfernen. Die Werte selbst werden niemals im Terminal ausgegeben. Sowohl .env als auch die Zugangsdatendatei der Engine werden mit den Berechtigungen 0600 angelegt.

Wenn Sie die Einrichtung lieber manuell vornehmen:

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

Tragen Sie anschließend den Provider-Schlüssel in .env ein und belassen Sie die Dateiberechtigungen bei 0600. In beiden Fällen liegt nun ein gültiger Provider-Zugangsschlüssel auf diesem Server. Das ist ein weiterer Grund, auf dem Server keine anderen Daten oder Dienste abzulegen. Erstellen Sie einen Schlüssel ausschließlich für dieses Projekt. Wenn Sie ihn später widerrufen, werden dadurch keine anderen wichtigen Zugriffe unterbrochen. Geheimnisse vor dem Zugriff durch AI-Agenten schützen behandelt diese Vorgehensweise ausführlicher.

Ausgabenlimit beim Provider vor dem ersten Scan festlegen

open-kritt ist für parallele Ausführung ausgelegt. Diese Parallelität verursacht die Kosten. Die Standardwerte in .env.example bei v1.3.0 sind konservativ: ENGINE_WORKER_COUNT=2, in der Datei als konservativer Standardwert für eine kleine Maschine mit 2 vCPUs beschrieben, und ENGINE_MAX_CONCURRENT_SCANS=1. Darüber liegen ENGINE_WORKERS_PER_ACCOUNT=15, die maximal zulässige Anzahl gleichzeitig ausgeführter Root-Modellaufrufe über ein Provider-Konto, sowie ENGINE_CODEX_MAX_SUBAGENTS_PER_SESSION=5, da eine Codex-Sitzung bis zu fünf untergeordnete Agents ausführen kann. Wenn Sie die Anzahl der Worker auf einem größeren VPS erhöhen, steigt auch die Anzahl der gleichzeitig laufenden Modellaufrufe.

Im Repository gibt es keine Begrenzung Ihrer Ausgaben. In .env.example ist keine Budgeteinstellung vorhanden. Die eigenen Abbruchbedingungen der Engine sind diese Worker-Limits sowie ENGINE_HARNESS_TIMEOUT_SECONDS, das standardmäßig auf 7200 Sekunden pro Harness-Lauf gesetzt ist. Das Ausgabenlimit muss daher beim Provider festgelegt werden. Öffnen Sie die Provider-Konsole und setzen Sie vor dem ersten Scan ein hartes monatliches Limit, nicht erst danach. Kosten eines AI-Agents auf einem VPS kontrollieren beschreibt die Einstellungen der einzelnen Provider.

Es gibt außerdem eine lokale Bremse. Mit ENGINE_WORKER_COUNT=0 wird die Abholung neuer Jobs pausiert. Dieselben Worker-Werte können im Bildschirm Settings geändert werden, sobald der Stack läuft.

Dieser Leitfaden nennt keinen Preis pro Scan. Die Kosten hängen von der Größe des Repositorys, dem erstellten Workflow und dem verwendeten Modell ab. Führen Sie zunächst einen Scan für ein kleines Repository aus. Prüfen Sie anschließend die Nutzungsseite Ihres Providers, bevor Sie größere Repositorys verarbeiten.

Stack starten und den Zustand prüfen

./kritt start

Damit werden .env geprüft und mindestens ein Zugangsschlüssel abgefragt. Anschließend wird docker compose up --build ausgeführt. Der erste Build dauert länger, weil dabei die Images für Frontend, Backend, Engine, Executor-Ansicht und Datenbank erstellt werden. Der Stack läuft außerdem im Vordergrund. Wenn Sie die SSH-Sitzung schließen, wird der Stack beendet. Starten Sie ihn innerhalb von tmux oder starten Sie ihn nach erfolgreichem ersten Build im Detached-Modus. Keine dieser Varianten übersteht einen Reboot selbstständig. Wenn der Stack nach einem Neustart des Servers automatisch wieder gestartet werden soll, lässt sich das systemd-Unit-Muster aus einen Self-Hosted-Agent über Reboots hinweg ausführen direkt übernehmen.

docker compose up -d --build
docker compose ps

docker compose ps sollte open-kritt-frontend, open-kritt-backend, open-kritt-engine, open-kritt-executor-view und open-kritt-db auflisten. Prüfen Sie anschließend, ob das Backend auf dem Server selbst antwortet.

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

Eine JSON-Antwort bedeutet, dass das Backend läuft. Failed to connect to 127.0.0.1 port 3002: Connection refused bedeutet, dass dies nicht der Fall ist. docker compose logs backend zeigt den Grund an. Beenden Sie alles mit docker compose down aus dem Repository-Verzeichnis.

Optional können Sie mit docker compose exec backend npm run seed Demodaten laden. Damit lässt sich die Oberfläche prüfen, bevor Sie Geld für einen echten Scan ausgeben.

Zugriff auf die UI über Port 5173 per SSH-Tunnel

Jeder Dienst in der Compose-Datei bindet standardmäßig an 127.0.0.1: das Frontend an Port 5173, das Backend an Port 3002, die Executor-Ansicht an Port 8090 und Postgres an Port 5432. Lassen Sie diese Bindings unverändert und leiten Sie den Port von Ihrem eigenen Rechner aus über SSH weiter.

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

Öffnen Sie http://localhost:5173 in Ihrem lokalen Browser, während der Befehl läuft. -N bedeutet, dass die Verbindung die Weiterleitung übernimmt und keine Shell öffnet. Fügen Sie demselben Befehl ein zweites -L 8090:127.0.0.1:8090 hinzu, wenn Sie auch die Executor-Ansicht benötigen.

Die naheliegende Lösung ist, FRONTEND_BIND_ADDRESS=0.0.0.0 zu setzen und den Tunnel wegzulassen. Tun Sie das nicht. Das Backend hat keine Anmeldeseite. Jeder, der diese Seite erreicht, kann Scans starten und Ihr Provider-Guthaben verbrauchen. Außerdem gibt es eine weitere wichtige Falle: Ein veröffentlichter Container-Port wird verarbeitet, bevor die Standardrichtlinie von ufw greift. Daher sieht eine ufw deny 5173-Regel zwar korrekt aus, blockiert aber nichts. Docker-Ports, die ufw umgehen zeigt die Regelkette, die dies verursacht.

Größe des VPS

ENGINE_MIN_FREE_STORAGE_GB ist standardmäßig auf 20 gesetzt. Die Engine startet keinen neuen Scan-Container pro Auftrag, wenn der freie Speicher darunter fällt. Die erstellten Images, der Checkout-Cache, die Postgres-Daten und die Arbeitsbereiche der Aufträge liegen auf derselben Festplatte. Ein VPS mit 20 GB startet daher überhaupt keinen Scan. Betrachten Sie 40 GB als Mindestgröße. Für große Repositorys sollten Sie mehr Speicher bereitstellen.

Der Speicherbedarf lässt sich einfach berechnen. ENGINE_MEMORY_RESERVE_GB=2 reserviert Speicher für die Engine, die Datenbank, die API und kurzlebigen Zusatzbedarf. Jeder Scan-Runner hat außerdem eine Reservierung und eine harte Obergrenze von ENGINE_SCAN_RUNNER_MEMORY_MB=1536. Zwei Worker benötigen daher bereits etwa 5 GB, bevor andere Prozesse ausgeführt werden. Die Engine lässt nur so viele Runner zu, wie in das verbleibende Budget passen. Auf einem kleinen System werden Scans daher in die Warteschlange gestellt, anstatt fehlzuschlagen. Das ist ein deutlich besseres Fehlerverhalten als ein Eingreifen des Out-of-Memory-Killers.

Zwei Prune-Einstellungen stehen standardmäßig auf true: ENGINE_AUTO_PRUNE_DOCKER_BUILD_CACHE und ENGINE_AUTO_PRUNE_UNUSED_DOCKER_IMAGES. Nach Abschluss eines Tasks entfernt die Engine nicht verwendeten Build-Cache, nicht verwendete Images und gestoppte Scan-Container. Von einem laufenden Container referenzierte Images, Bind-Mounts, Datenbankdaten, Zugangsdaten und Volumes bleiben erhalten. Das ist ein weiterer Grund, den Host nicht gemeinsam zu nutzen: Ein Pruner, den Sie nicht konfiguriert haben, läuft gegen diesen Docker-Daemon.

Ein lokales Repository scannen, ohne es offenzulegen

LOCAL_REPOS_PATH wird standardmäßig auf ./local_repos gesetzt und in den Backend- und Engine-Containern unter /local_repos als Bind-Mount eingebunden. Ein Repository, das Sie auf dem Host in diesen Ordner kopieren, ist daher sofort in den Containern verfügbar. Verwenden Sie einen frischen Clone, nicht Ihren Arbeitsbaum. Der Job-Container erhält eine beschreibbare Kopie, läuft darin als root und hat ausgehenden Internetzugriff. Dadurch kann alles, was sich in dieser Kopie befindet, geändert oder vom Server übertragen werden. Entfernen Sie .env-Dateien und private Schlüssel, bevor Sie ein Projekt hineinkopieren.

Was Sie erhalten und was nicht

Sie erhalten nach Rang geordnete potenzielle Befunde. Sie erhalten keine verifizierten Schwachstellen. Die Rangfolge und die Duplikatbereinigung bestimmen die Reihenfolge Ihrer Triage-Warteschlange. Sie belegen nicht, dass ein Eintrag tatsächlich zutrifft. Post-Skripte können eine Validierung versuchen und einen Proof of Concept erstellen. Das ist das stärkste Signal, das das Tool liefert. Ein fehlgeschlagenes Post-Skript ist jedoch kein Beleg dafür, dass der Befund falsch ist. Eine Person prüft weiterhin jeden potenziellen Befund.

Dieser Leitfaden macht keine Aussage darüber, wie viele echte Fehler open-kritt findet, weil wir das nicht gemessen haben. Wer eine Erkennungsrate für Ihre Codebasis nennt, hat open-kritt nicht gegen Ihre Codebasis ausgeführt. Scannen Sie zunächst ein Repository, das Sie bereits gut kennen. Befunde, die Sie selbst beurteilen können, bieten die kostengünstigste Möglichkeit zur Kalibrierung.

Die Autorisierung ist hier wichtiger als bei den meisten selbst gehosteten Tools. Die Agents kompilieren Code, führen ihn aus und greifen auf das Netzwerk zu. Daher kann ein Proof-of-Concept-Schritt produktive Systeme erreichen. Richten Sie das Tool auf Code, dessen Eigentümer Sie sind oder den Sie vertraglich testen dürfen. Dokumentieren Sie den Zielumfang, bevor Sie etwas ausführen. Wenn Sie ANTHROPIC_API_KEY konfigurieren und die Claude-Code-Engine verwenden, gelten die Vorgehensweisen zum sicheren Betrieb von Claude Code in Claude Code sicher auf einem VPS ausführen auch für diese Agents.

FAQ

Warum benötigt open-kritt einen eigenen VPS?

Die Analyseagenten laufen als root in kurzlebigen Job-Containern mit beschreibbaren Kopien Ihres Codes und direktem Internetzugriff. Außerdem bindet der Engine-Dienst den Docker-Socket des Hosts ein, damit er pro Job einen Container starten kann. Jeder Prozess, der diesen Socket erreicht, kann einen Container starten, der das Dateisystem des Hosts einbindet. Deshalb sollte der gesamte Stack so behandelt werden, als liefe er als root auf dem Host. Auf einem dedizierten VPS ist dieser Kompromiss vertretbar. Ein Neuaufsetzen des Systems verursacht dort keinen Verlust Ihrer täglichen Arbeitsumgebung. Auf Ihrer täglichen Workstation befinden sich Ihre SSH-Schlüssel und Browserprofile dagegen innerhalb derselben Vertrauensgrenze wie der Code, den Sie prüfen.

Kann ich Port 5173 veröffentlichen, statt einen SSH-Tunnel zu verwenden?

Das sollten Sie nicht tun. Das Backend wird ohne Anwendungsauthentifizierung ausgeliefert. Der Port ist daher die einzige Barriere zwischen dem Internet und Ihren Analyseergebnissen sowie dem Guthaben beim Anbieter. Die Compose-Datei bindet aus diesem Grund jeden Dienst an 127.0.0.1. Führen Sie stattdessen ssh -N -L 5173:127.0.0.1:5173 you@your-server-ip aus und öffnen Sie anschließend lokal http://localhost:5173. Eine ufw-Regel ist kein Ersatz dafür, weil ein veröffentlichter Docker-Port verarbeitet wird, bevor die Standardrichtlinie von ufw greift.

Wie verhindere ich, dass open-kritt mehr ausgibt als geplant?

Legen Sie vor dem ersten Scan in der Konsole Ihres Modellanbieters ein festes Limit fest. open-kritt besitzt keine eigene Budgeteinstellung. Behalten Sie bei den ersten Durchläufen die mitgelieferten Standardwerte für die Parallelität bei, ENGINE_WORKER_COUNT=2 und ENGINE_MAX_CONCURRENT_SCANS=1. Beachten Sie außerdem, dass ein Anbieteraccount standardmäßig bis zu 15 gleichzeitige Aufrufe des root-Modells zulässt, während eine Codex-Sitzung bis zu fünf untergeordnete Agenten ausführen kann. ENGINE_WORKER_COUNT=0 pausiert die Aufnahme neuer Jobs und ist der schnellste lokale Stopp.

Welche Version sollte ich auschecken?

Ein Tag, niemals main. git fetch --tags gefolgt von git tag --list zeigt, was verfügbar ist. v1.3.0, veröffentlicht am 4. August 2026, ist zum Zeitpunkt der Erstellung dieses Textes die neueste Version. Durch das Festlegen einer Version erzeugt ein Monate späterer Neuaufbau denselben Stack. Außerdem wird das Upgrade zu einer bewussten Entscheidung nach dem Lesen der Release Notes und nicht zu einem Nebeneffekt des Klonens an einem anderen Tag.

Ein Scan startet nie. Was sollte ich prüfen?

Prüfen Sie zuerst den freien Speicherplatz. Die Engine startet keinen Scan-Container pro Job, wenn der freie Speicher unter ENGINE_MIN_FREE_STORAGE_GB liegt. Der Standardwert beträgt 20 GB. Prüfen Sie anschließend, dass ENGINE_WORKER_COUNT nicht 0 ist, da dieser Wert die Aufnahme neuer Jobs pausiert. Bestätigen Sie danach, dass ein Modellzugang tatsächlich konfiguriert ist, indem Sie ./kritt setup ausführen. Ein GITHUB_TOKEN allein kann keine Scans ausführen. docker compose logs engine nennt den Grund, aus dem der Job übersprungen wurde.