Jak samodzielnie hostować open-kritt na VPS

Dlaczego warto hostować open-kritt na VPS, a nie na laptopie

Hostuj open-kritt na serwerze, który można zniszczyć i odtworzyć. Narzędzie uruchamia agentów analitycznych z uprawnieniami root wewnątrz tymczasowych kontenerów zadań, nadaje każdemu z nich dostęp do zapisu kopii kodu oraz bezpośredni dostęp do Internetu, a także montuje gniazdo Docker hosta w swojej usłudze silnika. Jest to akceptowalny kompromis w przypadku maszyny dedykowanej do tego zadania. Jest to natomiast złe rozwiązanie na urządzeniu, na którym przechowywane są klucze SSH.

Cztery właściwości domyślnej konfiguracji uzasadniają to zalecenie, a wszystkie cztery wynikają z pliku README oraz pliku compose samego projektu.

Agenci mają być potężni. Dokumentacja README podaje, że agenci z dostępem do narzędzi działają jako root wewnątrz tymczasowych kontenerów zadań, z dostępem do zapisu kopii repozytorium i bezpośrednim dostępem do Internetu, dzięki czemu mogą instalować narzędzia, kompilować cele, uruchamiać testy i budować proof-of-concept. Skanowanie to nie linter czytający pliki. Jest to dowolne wykonanie kodu, o które użytkownik sam prosi. Dostęp do Internetu działa w obie strony: wszystko, co agent pobierze podczas badania celu, jest niezaufanym tekstem trafiającym do jego promptu, co stanowi to samo zagrożenie, na które narażasz się, gdy pozwalasz agentowi na samodzielne wyszukiwanie w sieci.

Silnik posiada dostęp do gniazda Docker. docker-compose.yml montuje gniazdo Docker hosta w usłudze silnika, ponieważ silnik buduje i uruchamia jeden kontener skanujący na zadanie. Każdy proces, który może uzyskać dostęp do tego gniazda, może uruchomić kontener montujący system plików hosta. Zatem silnik posiada w praktyce uprawnienia root na każdym hoście, na którym działa.

Brak ekranu logowania. Backend dostarczany jest bez uwierzytelniania aplikacji. Dostęp do portu oznacza dostęp do wyników skanowania oraz do środków u dostawcy usług.

Skanowany kod często nie należy do Ciebie. Skierowanie agentów na repozytorium strony trzeciej oznacza uruchomienie kompilacji tego repozytorium na własnej maszynie, z uprawnieniami root i dostępem do sieci.

Jeśli zapoznałeś się z informacją dlaczego agenci programujący powinni działać w tymczasowej maszynie wirtualnej, jest to ten sam model zagrożeń, tylko silniejszy. Przeznacz dla open-kritt serwer VPS, na którym nie ma nic innego, i zarządzaj tym VPS-em z poziomu oddzielnego konta użytkownika o ograniczonych uprawnieniach, zamiast z konta root.

Czym w rzeczywistości zajmuje się open-kritt

open-kritt (repozytorium znajduje się pod adresem Kritt-ai/open-kritt, na licencji AGPL-3.0) dzieli badania nad podatnościami na niewielkie zadania, uruchamia je równolegle przy użyciu agentów AI, a następnie usuwa duplikaty i szereguje uzyskane wyniki. Przepływ pracy definiuje się jako łańcuch ukierunkowanych zapytań (prompts), gdzie każdy krok otrzymuje ustrukturyzowany kontekst z poprzednich etapów. Celem skanowania jest zdalne lub lokalne repozytorium git. Silnikiem analizy jest Codex lub Claude Code. Po wygenerowaniu kandydata, opcjonalne skrypty końcowe mogą podjąć próbę jego walidacji lub stworzenia dowodu koncepcji (proof of concept).

Wynikiem końcowym jest uszeregowana lista kandydatów. Należy traktować ją jako kolejkę do weryfikacji (triage), a nie jako gotowy raport.

Wymagania wstępne

• VPS z systemem Ubuntu 24.04, Debian 12 lub Rocky Linux 9. Dokumentacja instalacji wymienia te dystrybucje jako przetestowane, zarówno dla architektury x86_64, jak i ARM64.
• Docker Engine z wtyczką Compose.
• Node.js w wersji 20 lub nowszej na hoście, ponieważ interfejs ./kritt CLI uruchamia się na hoście, a nie wewnątrz kontenera.
• Jeden dostawca modelu: login do Codex lub OPENAI_API_KEY, CODEX_API_KEY, ANTHROPIC_API_KEY lub OPENROUTER_API_KEY.
• GITHUB_TOKEN tylko w przypadku planowania skanowania prywatnych repozytoriów. Dostarczona dokumentacja .env.example jasno to określa: sam token GitHub nie wystarczy do przeprowadzenia skanowania.

Zainstaluj najpierw Docker oraz Node 20

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

Wyloguj się i zaloguj ponownie, aby członkostwo w nowej grupie zostało uwzględnione, a następnie potwierdź obecność wtyczki Compose.

docker compose version

Ciąg znaków wersji oznacza, że Compose jest zainstalowany jako wtyczka. docker: 'compose' is not a docker command oznacza, że zamiast tego używany jest stary, samodzielny plik binarny docker-compose, a open-kritt wywołuje docker compose. Członkostwo w grupie docker jest równoważne z uprawnieniami root na hoście, dlatego należy dodać do niej wyłącznie konto, na którym uruchamiany jest open-kritt. Szczegółowe informacje na temat tej konfiguracji znajdują się w sekcji uruchamianie Docker na VPS.

Ubuntu 24.04 dostarcza Node 18 w swoim własnym repozytorium, a CLI kończy działanie przy każdej wersji niższej niż 20. Użyj NodeSource.

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

node -v musi zwrócić v20. lub wyższą wersję. W systemie Rocky Linux 9 odpowiednikiem jest sudo dnf module enable nodejs:20 -y, po którym następuje sudo dnf install -y nodejs.

Klonowanie open-kritt i przypięcie do oznaczonej wersji

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

main przesuwa się wraz z Tobą. Znacznik (tag) nie. Według stanu na sierpień 2026 najnowszym znacznikiem jest v1.3.0, opublikowany 4 sierpnia 2026, a git tag --list pokazuje stan repozytorium w dniu klonowania. Przełączenie na znacznik pozostawia repozytorium w stanie detached HEAD, co jest w tym przypadku poprawne: klon traktowany jest jako przypięte wdrożenie, a nie gałąź, w której dokonywane są commity. Aby przeprowadzić aktualizację w przyszłości, należy zapoznać się z informacjami o wydaniu, wykonać git fetch --tags, przełączyć się na nowy znacznik i ponownie uruchomić ./kritt start, ponieważ start przebudowuje obrazy.

Nie należy uruchamiać ./kritt z sudo. Dokumentacja wyraźnie tego zabrania. Interfejs CLI zarządza lokalnymi katalogami poświadczeń projektu w .data/, więc uruchomienie z uprawnieniami root powoduje, że katalogi te stają się własnością użytkownika root, co uniemożliwia ich zapis przez zwykłego użytkownika przy kolejnym uruchomieniu.

Konfiguracja dostępu do modelu za pomocą ./kritt setup

./kritt setup

Polecenie tworzy .env z .env.example, jeśli plik nie istnieje, wyświetla status każdego poświadczenia oraz umożliwia ich ustawienie lub usunięcie. Wartości nigdy nie są wypisywane w terminalu. Zarówno .env, jak i plik poświadczeń silnika są zapisywane z uprawnieniami 0600.

Jeśli wolisz wykonać to ręcznie:

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

Następnie wprowadź klucz dostawcy do .env i pozostaw plik z uprawnieniami 0600. Niezależnie od wybranej metody, działające poświadczenie dostawcy znajduje się teraz na serwerze, co stanowi kolejny powód, dla którego maszyna nie powinna zawierać żadnych innych danych. Utwórz klucz przeznaczony wyłącznie dla tego projektu, aby jego późniejsze unieważnienie nie wpłynęło na inne usługi. Artykuł Utrzymywanie sekretów poza zasięgiem agentów AI omawia szersze aspekty tego nawyku.

Ustawienie limitu wydatków u dostawcy przed pierwszym skanowaniem

Narzędzie open-kritt zostało zaprojektowane z myślą o rozpraszaniu zadań (fan-out), a to właśnie za ten mechanizm ponoszone są opłaty. Wartości domyślne w .env.example w wersji v1.3.0 są zachowawcze: ENGINE_WORKER_COUNT=2, opisane w pliku jako bezpieczne ustawienie dla małej maszyny 2-vCPU, oraz ENGINE_MAX_CONCURRENT_SCANS=1. Powyżej nich znajdują się ENGINE_WORKERS_PER_ACCOUNT=15, czyli maksymalna liczba równoległych wywołań modelu głównego dozwolona na jednym koncie dostawcy, oraz ENGINE_CODEX_MAX_SUBAGENTS_PER_SESSION=5, ponieważ sesja Codex może uruchomić do pięciu agentów podrzędnych. Zwiększenie liczby workerów na większym VPS powoduje proporcjonalny wzrost liczby jednoczesnych wywołań modelu.

W repozytorium nie ma mechanizmu ograniczającego wydatki. W .env.example nie przewidziano ustawień budżetowych. Własne warunki zatrzymania silnika ograniczają się do limitów workerów oraz ENGINE_HARNESS_TIMEOUT_SECONDS, którego wartość domyślna wynosi 7200 sekund na jeden przebieg testowy. Dlatego górny limit musi zostać nałożony po stronie dostawcy. Należy otworzyć konsolę dostawcy i ustawić sztywny limit miesięczny przed wykonaniem pierwszego skanowania, a nie po nim. Artykuł Kontrola kosztów agenta AI na VPS zawiera szczegółowy opis ustawień u poszczególnych dostawców.

Dostępny jest również lokalny hamulec. Ustawienie ENGINE_WORKER_COUNT=0 wstrzymuje pobieranie nowych zadań, a te same wartości workerów można zmienić w ekranie ustawień po uruchomieniu stosu.

Niniejszy przewodnik nie podaje ceny za skanowanie, ponieważ koszt zależy od rozmiaru repozytorium, zbudowanego przepływu pracy oraz wykorzystanego modelu. Należy wykonać jedno skanowanie małego repozytorium, a następnie sprawdzić stronę użycia u dostawcy przed skierowaniem narzędzia na jakikolwiek większy zasób.

Uruchomienie stosu i weryfikacja poprawności działania

./kritt start

Polecenie to sprawdza .env oraz przynajmniej jeden zestaw danych uwierzytelniających, a następnie uruchamia docker compose up --build. Pierwsza kompilacja trwa długo, ponieważ obejmuje budowanie obrazów dla frontend, backend, engine, executor view oraz bazy danych. Proces działa w pierwszym planie, więc zamknięcie sesji SSH spowoduje zatrzymanie stosu. Należy uruchomić go wewnątrz tmux lub użyć trybu odłączonego (detached) po zakończeniu pierwszej kompilacji. Żadna z tych metod nie zapewnia automatycznego startu po restarcie systemu, więc w celu przywrócenia stosu po ponownym uruchomieniu serwera, należy zastosować wzorzec jednostki systemd opisany w utrzymywanie działającego agenta self-hosted po restarcie.

docker compose up -d --build
docker compose ps

docker compose ps powinno wyświetlić open-kritt-frontend, open-kritt-backend, open-kritt-engine, open-kritt-executor-view oraz open-kritt-db. Następnie należy sprawdzić, czy backend odpowiada na samym serwerze.

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

Odpowiedź w formacie JSON oznacza, że backend działa. Failed to connect to 127.0.0.1 port 3002: Connection refused oznacza, że usługa nie jest dostępna, a docker compose logs backend wskaże przyczynę. Wszystkie elementy można zatrzymać za pomocą docker compose down z poziomu katalogu repozytorium.

Opcjonalny dodatek: docker compose exec backend npm run seed ładuje dane demonstracyjne, co pozwala na szybkie zapoznanie się z interfejsem przed rozpoczęciem właściwego skanowania.

Dostęp do interfejsu użytkownika na porcie 5173 przez tunel SSH

Każda usługa w pliku compose domyślnie wiąże się z 127.0.0.1: frontend na 5173, backend na 3002, widok executor na 8090 oraz Postgres na 5432. Pozostaw te powiązania bez zmian i przekieruj port przez SSH ze swojej maszyny lokalnej.

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

Otwórz http://localhost:5173 w lokalnej przeglądarce, gdy to polecenie jest uruchomione. -N oznacza, że połączenie realizuje przekierowanie bez otwierania powłoki. Dodaj drugie -L 8090:127.0.0.1:8090 do tego samego polecenia, jeśli potrzebujesz również widoku executor.

Kuszące jest ustawienie FRONTEND_BIND_ADDRESS=0.0.0.0 i pominięcie tunelu. Nie rób tego. Backend nie posiada ekranu logowania, więc każdy, kto uzyska dostęp do tej strony, może uruchamiać skanowanie i zużywać Twoje środki u dostawcy. Istnieje również drugie zagrożenie: opublikowany port kontenera jest obsługiwany przed zastosowaniem domyślnej polityki ufw, więc reguła ufw deny 5173 wygląda poprawnie, ale niczego nie blokuje. Porty Docker omijające ufw przedstawia łańcuch reguł, który to powoduje.

Dobieranie rozmiaru VPS

ENGINE_MIN_FREE_STORAGE_GB domyślnie wynosi 20, a silnik odmawia uruchomienia nowego kontenera skanującego dla zadania, gdy ilość wolnego miejsca na dysku spada poniżej tej wartości. Zbudowane obrazy, pamięć podręczna checkout, dane Postgres oraz obszary robocze zadań znajdują się na tym samym dysku, więc na VPS o pojemności 20 GB skanowanie w ogóle się nie uruchomi. Należy przyjąć 40 GB jako wartość minimalną, a w przypadku skanowania dużych repozytoriów przydzielić więcej miejsca.

Zapotrzebowanie na pamięć wynika z prostych obliczeń. ENGINE_MEMORY_RESERVE_GB=2 rezerwuje pamięć dla silnika, bazy danych, API oraz krótkotrwałych procesów pomocniczych, a każdy proces skanujący (runner) posiada rezerwację oraz twardy limit ENGINE_SCAN_RUNNER_MEMORY_MB=1536. Zatem dwa procesy robocze wymagają około 5 GB pamięci przed uruchomieniem czegokolwiek innego. Silnik dopuszcza tylko te procesy, które mieszczą się w pozostałym budżecie, więc na małej maszynie zadania trafiają do kolejki zamiast kończyć się błędem, co jest znacznie lepszym rozwiązaniem niż działanie mechanizmu out-of-memory killer.

Dwa ustawienia czyszczenia (pruning) są domyślnie włączone: ENGINE_AUTO_PRUNE_DOCKER_BUILD_CACHE oraz ENGINE_AUTO_PRUNE_UNUSED_DOCKER_IMAGES. Po zakończeniu zadania silnik usuwa nieużywaną pamięć podręczną budowania, nieużywane obrazy oraz zatrzymane kontenery skanujące. Obrazy, do których odwołuje się uruchomiony kontener, montowania typu bind, dane bazy danych, poświadczenia oraz wolumeny są zachowywane. Jest to kolejny powód, dla którego nie należy współdzielić hosta: mechanizm czyszczący, którego nie skonfigurowałeś, działa na tym samym Docker daemon.

Skanowanie lokalnego repozytorium bez ryzyka wycieku danych

LOCAL_REPOS_PATH domyślnie wskazuje na ./local_repos i jest montowane (bind-mount) w kontenerach backendu oraz silnika w lokalizacji /local_repos. Dzięki temu repozytorium umieszczone w tym folderze na hoście jest natychmiast widoczne wewnątrz kontenerów. Należy użyć świeżego klona, a nie aktywnego drzewa roboczego. Kontener zadania otrzymuje kopię z prawami zapisu, uprawnieniami root wewnątrz siebie oraz dostępem do Internetu. Oznacza to, że każda zawartość tej kopii może zostać zmodyfikowana lub przesłana poza serwer. Przed skopiowaniem projektu należy usunąć pliki .env oraz klucze prywatne.

Co otrzymujesz, a czego nie

Otrzymujesz uszeregowane wyniki analizy kandydatów. Nie otrzymujesz zweryfikowanych podatności. Ranking oraz deduplikacja decydują o kolejności w kolejce triage. Nie stanowią one dowodu na to, że wpis jest prawdziwy. Skrypty post-processingowe mogą podjąć próbę walidacji i stworzyć dowód koncepcji (PoC), co jest najsilniejszym sygnałem oferowanym przez narzędzie, jednak niepowodzenie takiego skryptu nie jest dowodem na to, że wynik jest fałszywy. Każdy kandydat jest nadal weryfikowany przez człowieka.

Niniejszy przewodnik nie zawiera zapewnień dotyczących liczby rzeczywistych błędów wykrywanych przez open-kritt, ponieważ nie zostało to zmierzone. Każdy, kto podaje wskaźnik wykrywalności dla Twojej bazy kodu, nie uruchomił tego narzędzia w Twoim środowisku. Najpierw przeskanuj repozytorium, które dobrze znasz: wyniki, które możesz samodzielnie ocenić, są najtańszym dostępnym sposobem kalibracji.

Autoryzacja ma tutaj większe znaczenie niż w przypadku większości narzędzi typu self-hosted. Agenci kompilują i wykonują kod oraz uzyskują dostęp do sieci, więc krok tworzenia dowodu koncepcji może wpłynąć na działające systemy. Kieruj narzędzie wyłącznie na kod, którego jesteś właścicielem lub który masz zakontraktowany do testowania, i określ zakres docelowy przed uruchomieniem jakichkolwiek działań. Jeśli konfigurujesz ANTHROPIC_API_KEY i korzystasz z silnika Claude Code, zasady izolacji (sandboxing) opisane w bezpiecznym uruchamianiu Claude Code na VPS mają zastosowanie również do tych agentów.

FAQ

Dlaczego open-kritt wymaga własnego VPS?

Ponieważ agenci analityczni działają z uprawnieniami root wewnątrz tymczasowych kontenerów zadań, które mają dostęp do zapisu w kopiach kodu oraz bezpośredni dostęp do Internetu. Ponadto usługa silnika montuje gniazdo Docker hosta, aby móc uruchamiać jeden kontener na zadanie. Każdy proces, który uzyska dostęp do tego gniazda, może uruchomić kontener montujący system plików hosta, dlatego cały stos należy traktować jako posiadający uprawnienia root na hoście. Na dedykowanym VPS jest to akceptowalny kompromis, a ponowna instalacja serwera nie generuje kosztów. Na stacji roboczej takie rozwiązanie umieszcza klucze SSH i profile przeglądarki w tej samej strefie zaufania, co skanowany kod.

Czy mogę wystawić port 5173 zamiast używać tunelu SSH?

Nie należy tego robić. Backend jest dostarczany bez uwierzytelniania aplikacji, więc port jest jedyną barierą między Internetem a wynikami skanowania oraz środkami u dostawcy modelu. Z tego powodu plik compose wiąże każdą usługę z adresem 127.0.0.1. Należy uruchomić ssh -N -L 5173:127.0.0.1:5173 you@your-server-ip i przeglądać http://localhost:5173 lokalnie. Reguła ufw nie stanowi zabezpieczenia, ponieważ opublikowany port Docker jest obsługiwany przed zastosowaniem domyślnej polityki ufw.

Jak zapobiec przekroczeniu planowanego budżetu przez open-kritt?

Przed pierwszym skanowaniem należy ustawić twardy limit w konsoli dostawcy modelu, ponieważ open-kritt nie posiada własnych ustawień budżetowych. Przy pierwszych uruchomieniach warto zachować domyślne wartości współbieżności, ENGINE_WORKER_COUNT=2 oraz ENGINE_MAX_CONCURRENT_SCANS=1. Należy pamiętać, że jedno konto u dostawcy pozwala domyślnie na 15 jednoczesnych wywołań modelu głównego, podczas gdy sesja Codex może uruchomić do pięciu agentów podrzędnych. ENGINE_WORKER_COUNT=0 wstrzymuje pobieranie nowych zadań i jest najszybszym sposobem na lokalne zatrzymanie pracy.

Którą wersję należy pobrać?

Zawsze należy wybierać tag, nigdy main. git fetch --tags w połączeniu z git tag --list wyświetla dostępne wersje, a v1.3.0, opublikowana 4 sierpnia 2026, jest najnowszą wersją w momencie pisania tego tekstu. Przypięcie wersji gwarantuje, że ponowna budowa stosu po kilku miesiącach przyniesie ten sam rezultat. Dzięki temu aktualizacja staje się świadomą decyzją podjętą po zapoznaniu się z informacjami o wydaniu, a nie skutkiem ubocznym klonowania repozytorium w innym dniu.

Skanowanie nie uruchamia się. Co sprawdzić?

W pierwszej kolejności należy sprawdzić wolne miejsce na dysku, ponieważ silnik nie uruchomi kontenera skanującego, jeśli wolna przestrzeń jest mniejsza niż ENGINE_MIN_FREE_STORAGE_GB (wartość domyślna to 20 GB). Następnie należy sprawdzić, czy ENGINE_WORKER_COUNT nie wynosi 0, ponieważ ta wartość wstrzymuje pobieranie nowych zadań. Należy również potwierdzić, że poświadczenia modelu są poprawnie skonfigurowane, uruchamiając ./kritt setup, ponieważ samo GITHUB_TOKEN nie pozwala na wykonywanie skanowań. docker compose logs engine wskazuje przyczynę pominięcia zadania.