open-kritt VPS üzerinde nasıl kurulur?

Neden open-kritt uygulamasını dizüstü bilgisayarınız yerine bir VPS üzerinde barındırmalısınız

open-kritt uygulamasını, dilediğiniz zaman yok edip yeniden oluşturabileceğiniz bir sunucuda barındırın. Araç, analiz ajanlarını root yetkileriyle geçici iş container'ları içinde çalıştırır; her birine kodunuzun yazılabilir bir kopyasını ve doğrudan internet erişimini verir ve ana makinenin Docker socket dosyasını motor servisine bağlar (mount). Bu, sadece bu işe ayrılmış bir makine için makul bir takastır. Ancak SSH anahtarlarınızı barındıran bir makinede bu, kötü bir tercihtir.

Varsayılan kurulumun dört özelliği bu tavsiyeyi zorunlu kılar; bu özelliklerin dördü de projenin kendi README dosyasından ve compose dosyasından gelmektedir.

Ajanlar güçlü olacak şekilde tasarlanmıştır. README dosyası, araç destekli ajanların root yetkileriyle, geçici iş container'ları içinde, yazılabilir depo kopyaları ve doğrudan internet erişimiyle çalıştığını belirtir; böylece ajanlar araç kurabilir, hedefleri derleyebilir, testleri çalıştırabilir ve kavram kanıtları (proof of concept) oluşturabilir. Bir tarama işlemi, sadece dosyaları okuyan bir linter değildir. Bu, sizin talep ettiğiniz keyfi kod yürütme işlemidir. İnternet erişimi iki ucu keskin bir bıçaktır: Bir ajanın hedefi araştırırken getirdiği her şey, istemine ulaşan güvenilmez metinlerdir; bu, bir ajana kendi web aramasını yaptırdığınızda maruz kaldığınız riskin aynısıdır.

Motor, Docker socket dosyasını tutar. docker-compose.yml, ana makinenin Docker socket dosyasını motor servisine bağlar; çünkü motor, her iş için bir tarama container'ı oluşturur ve başlatır. Bu socket dosyasına erişebilen herhangi bir süreç, ana makinenin dosya sistemini bağlayan bir container başlatabilir. Dolayısıyla motor, üzerinde çalıştığı ana makinede fiilen root yetkisine sahiptir.

Giriş ekranı yoktur. Backend, herhangi bir uygulama kimlik doğrulaması olmadan gelir. Porta erişim, bulgularınıza ve sağlayıcı kredilerinize erişim anlamına gelir.

Taradığınız kod genellikle size ait değildir. Ajanları üçüncü taraf bir depoya yönlendirmek, o deponun derleme sürecini kendi makinenizde, root yetkileriyle ve ağ erişimiyle çalıştırmak anlamına gelir.

Eğer kodlama ajanlarının neden geçici bir VM içinde olması gerektiğini okuduysanız, bu aynı tehdit modelidir, sadece daha güçlüsüdür. open-kritt için üzerinde başka hiçbir şeyin çalışmadığı bir VPS ayırın ve bu VPS'i root yerine ayrı, en düşük yetkili bir kullanıcı hesabı üzerinden yönetin.

open-kritt ne işe yarar

open-kritt (depo Kritt-ai/open-kritt adresindedir ve AGPL-3.0 lisansına sahiptir), güvenlik açığı araştırmasını küçük görevlere böler, bu görevleri yapay zeka ajanları üzerinde paralel olarak çalıştırır ve ardından gelen sonuçları tekilleştirip sıralar. İş akışını odaklanmış istemlerden oluşan bir zincir olarak tanımlarsınız; her adım, kendinden önceki adımlardan yapılandırılmış bağlam verisi alır. Tarama hedefi, uzak veya yerel bir git deposudur. Analiz motoru olarak Codex veya Claude Code kullanılır. Bir aday sonuç ortaya çıktıktan sonra, isteğe bağlı post-script dosyaları bu sonucu doğrulamaya veya bir kavram kanıtı (proof of concept) oluşturmaya çalışabilir.

Sürecin sonunda elde ettiğiniz şey, sıralanmış bir aday listesidir. Bunu bir rapor olarak değil, bir önceliklendirme (triage) kuyruğu olarak değerlendirin.

Başlamadan önce gerekenler

• Ubuntu 24.04, Debian 12 veya Rocky Linux 9 çalıştıran bir VPS. Kurulum belgeleri, x86_64 ve ARM64 mimarilerinde test edilmiş dağıtımları listeler.
• Compose eklentisi ile birlikte Docker Engine.
• Ana makinede Node.js 20 veya daha yeni bir sürüm; çünkü ./kritt CLI, bir container içinde değil, doğrudan ana makinede çalışır.
• Bir model sağlayıcısı: Codex girişi veya OPENAI_API_KEY, CODEX_API_KEY, ANTHROPIC_API_KEY ya da OPENROUTER_API_KEY.
• Yalnızca özel depoları taramayı planlıyorsanız GITHUB_TOKEN. Dağıtılan .env.example bunu açıkça belirtir: yalnızca bir GitHub token ile tarama yapılamaz.

Önce Docker ve Node 20 kurulumunu yapın

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

Yeni grup üyeliğinin geçerli olması için oturumu kapatıp tekrar açın, ardından Compose eklentisinin yüklü olduğunu doğrulayın.

docker compose version

Bir sürüm dizisi, Compose'un eklenti olarak yüklü olduğu anlamına gelir. docker: 'compose' is not a docker command çıktısı, bunun yerine eski bağımsız docker-compose ikili dosyasının yüklü olduğunu gösterir; open-kritt ise docker compose komutunu çağırır. docker grubuna üyelik, ana makinede root yetkisine eşdeğerdir; bu nedenle gruba yalnızca open-kritt uygulamasını çalıştıran hesabı ekleyin. Bu kurulumun daha ayrıntılı hali için VPS üzerinde Docker çalıştırma bölümüne bakın.

Ubuntu 24.04 kendi deposunda Node 18 ile gelir, ancak CLI 20'nin altındaki sürümlerde çalışmayı durdurur. NodeSource kullanın.

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

node -v komutu v20. veya daha yüksek bir sürüm çıktısı vermelidir. Rocky Linux 9 üzerinde bunun karşılığı sudo dnf module enable nodejs:20 -y ve ardından sudo dnf install -y nodejs komutlarıdır.

open-kritt deposunu klonlayın ve etiketli bir sürüme sabitleyin

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

main sizin altınıza taşınır. Bir etiket ise taşınmaz. Ağustos 2026 itibarıyla en yeni etiket v1.3.0 olup 4 Ağustos 2026 tarihinde yayınlanmıştır; git tag --list ise klonladığınız gün mevcut olanları gösterir. Bir etiketi checkout etmek, depoyu detached HEAD durumunda bırakır; bu durum burada doğrudur: bu klonu üzerinde commit yapacağınız bir dal olarak değil, sabitlenmiş bir dağıtım olarak ele alıyorsunuz. Daha sonra yükseltme yapmak için sürüm notlarını okuyun, ardından git fetch --tags komutunu çalıştırın, yeni etiketi checkout edin ve start imajları yeniden oluşturduğu için ./kritt start komutunu tekrar çalıştırın.

./kritt komutunu sudo ile çalıştırmayın. Dokümantasyon bu konuda açıktır. CLI, yerel proje kimlik bilgisi dizinlerini .data/ altında yönetir; bu nedenle root olarak yapılan bir çalıştırma, bu dizinlerin sahipliğini root üzerine bırakır ve bir sonraki normal çalıştırmada bu dizinlere yazma işlemi yapılamaz.

./kritt setup ile model erişimini yapılandırma

./kritt setup

Bu komut, .env mevcut olmadığında onu .env.example dosyasından oluşturur, her kimlik bilgisinin durumunu yazdırır ve bunları ayarlamanıza veya kaldırmanıza olanak tanır. Değerleri hiçbir zaman terminale yazdırmaz. Hem .env hem de motor kimlik bilgisi dosyası 0600 modunda yazılır.

Eğer bu işlemi manuel olarak yapmayı tercih ederseniz:

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

Ardından sağlayıcı anahtarını .env içine düzenleyin ve dosya izinlerini 0600 olarak bırakın. Hangi yöntem seçilirse seçilsin, çalışan bir sağlayıcı kimlik bilgisi artık sunucuda yer alır; bu durum, sunucunun başka hiçbir şey barındırmaması gerektiğinin bir başka nedenidir. Bu proje için özel bir anahtar oluşturun; böylece daha sonra iptal ettiğinizde önem verdiğiniz hiçbir şey zarar görmez. Sırları yapay zeka ajanlarının erişiminden uzak tutmak konusu, bu alışkanlığın daha geniş kapsamını ele almaktadır.

İlk taramadan önce bir sağlayıcı harcama sınırı belirleyin

open-kritt, işleri dağıtarak (fan-out) çalışacak şekilde tasarlanmıştır ve ödeme yaptığınız kısım da bu dağıtım sürecidir. .env.example içindeki v1.3.0 sürümüne ait varsayılan değerler muhafazakardır: dosya içerisinde küçük bir 2-vCPU makine için muhafazakar bir varsayılan olarak tanımlanan ENGINE_WORKER_COUNT=2 ve ENGINE_MAX_CONCURRENT_SCANS=1. Bunların üzerinde, tek bir sağlayıcı hesabı üzerinde izin verilen maksimum eşzamanlı kök model çağrısı sayısı olan ENGINE_WORKERS_PER_ACCOUNT=15 ve bir Codex oturumu beş adede kadar alt aracı çalıştırabildiği için ENGINE_CODEX_MAX_SUBAGENTS_PER_SESSION=5 yer alır. Daha büyük bir VPS üzerinde çalışan sayısını artırdığınızda, eşzamanlı model çağrılarının sayısı da buna bağlı olarak artar.

Depodaki hiçbir ayar harcamanızı sınırlamaz. .env.example içerisinde bir bütçe ayarı bulunmamaktadır. Motorun kendi durdurma koşulları, bu çalışan sınırları ve varsayılan olarak her bir harness çalışması için 7200 saniye olan ENGINE_HARNESS_TIMEOUT_SECONDS değeridir. Bu nedenle üst sınırın sağlayıcı tarafında belirlenmesi gerekir. Sağlayıcı konsolunuzu açın ve ilk taramadan sonra değil, taramayı başlatmadan önce kesin bir aylık limit belirleyin. Bir VPS üzerinde AI aracısının size maliyetini kontrol etme rehberi, sağlayıcı bazlı ayarların nasıl yapılacağını adım adım açıklar.

Ayrıca yerel bir durdurma mekanizması da mevcuttur. ENGINE_WORKER_COUNT=0 ayarını yapmak, yeni işlerin alınmasını duraklatır; aynı çalışan değerleri, yığın (stack) çalışmaya başladıktan sonra Ayarlar ekranından değiştirilebilir.

Bu rehber, tarama başına herhangi bir fiyat belirtmemektedir; çünkü maliyet, deponun boyutuna, oluşturduğunuz iş akışına ve arkasındaki modele bağlıdır. Küçük bir depo üzerinde tek bir tarama çalıştırın ve ardından büyük bir işlem başlatmadan önce sağlayıcınızın kullanım sayfasını inceleyin.

Stack'i başlatın ve sağlıklı olduğunu doğrulayın

./kritt start

Bu komut .env ve en az bir kimlik bilgisini kontrol eder, ardından docker compose up --build komutunu çalıştırır. İlk derleme yavaştır çünkü frontend, backend, engine, executor view ve veritabanı imajlarını oluşturur. Ayrıca ön planda çalıştığı için SSH oturumunu kapatmak stack'i durdurur. Stack'i tmux içinde başlatın veya ilk derleme başarıyla tamamlandıktan sonra arka planda (detached) çalışacak şekilde ayağa kaldırın. Bu yöntemlerin hiçbiri tek başına yeniden başlatma sonrasında kalıcı olmaz; bu nedenle sunucu yeniden başlatıldıktan sonra stack'in tekrar çalışmasını istiyorsanız, self-hosted agent'ı yeniden başlatmalar arasında çalışır durumda tutma bölümündeki systemd unit yapısı doğrudan uygulanabilir.

docker compose up -d --build
docker compose ps

docker compose ps komutu open-kritt-frontend, open-kritt-backend, open-kritt-engine, open-kritt-executor-view ve open-kritt-db öğelerini listelemelidir. Ardından backend'in sunucunun kendisinde yanıt verip vermediğini kontrol edin.

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

JSON yanıtı, backend'in çalıştığı anlamına gelir. Failed to connect to 127.0.0.1 port 3002: Connection refused yanıtı çalışmadığını gösterir ve docker compose logs backend nedenini açıklar. Depo dizininden docker compose down komutu ile her şeyi durdurun.

İsteğe bağlı bir ek: docker compose exec backend npm run seed komutu demo verilerini yükler; bu, gerçek bir tarama için herhangi bir harcama yapmadan önce arayüzü incelemenin kolay bir yoludur.

SSH tüneli üzerinden 5173 numaralı portta arayüze erişim

Compose dosyasındaki her servis varsayılan olarak 127.0.0.1 adresine bağlanır: frontend 5173, backend 3002, executor görünümü 8090 ve Postgres 5432 numaralı porttadır. Bu bağlamaları değiştirmeyin ve portu kendi makinenizden SSH üzerinden yönlendirin.

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

Komut çalışırken yerel tarayıcınızda http://localhost:5173 adresini açın. -N ifadesi, bağlantının yönlendirmeyi taşıdığını ve bir kabuk (shell) açmadığını belirtir. Executor görünümüne de ihtiyaç duyduğunuzda aynı komuta ikinci bir -L 8090:127.0.0.1:8090 ekleyin.

FRONTEND_BIND_ADDRESS=0.0.0.0 ayarını yapıp tüneli atlamak cazip gelebilir. Bunu yapmayın. Backend tarafında bir giriş ekranı yoktur; bu nedenle sayfaya erişen herkes tarama başlatabilir ve sağlayıcı kredinizi tüketebilir. Bunun altında ikinci bir tuzak daha vardır: yayınlanan bir container portu, ufw varsayılan politikası uygulanmadan önce işlenir; bu yüzden bir ufw deny 5173 kuralı doğru görünse de hiçbir şeyi engellemez. ufw'yi baypas eden Docker portları bu duruma neden olan kural zincirini göstermektedir.

VPS Boyutlandırma

ENGINE_MIN_FREE_STORAGE_GB varsayılan olarak 20 değerindedir ve boş depolama alanı bu değerin altına düştüğünde motor, yeni bir iş başına tarama container'ı başlatmayı reddeder. Oluşturulan imajlar, checkout önbelleği, Postgres verileri ve iş çalışma alanlarının tamamı aynı disk üzerinde barındığından, 20 GB kapasiteli bir VPS hiçbir zaman tarama başlatamaz. 40 GB değerini alt sınır olarak kabul edin; büyük depoları tarıyorsanız bu değeri daha da artırın.

Bellek kullanımı basit bir aritmetiğe dayanır. ENGINE_MEMORY_RESERVE_GB=2; motor, veritabanı, API ve kısa süreli ek yükler için bellek ayırır; her tarama çalıştırıcısı (runner) ise ENGINE_SCAN_RUNNER_MEMORY_MB=1536 değerinde bir rezervasyon ve katı bir üst sınıra sahiptir. Bu nedenle iki işçi (worker), başka hiçbir işlem çalışmadan önce yaklaşık 5 GB belleğe ihtiyaç duyar. Motor, yalnızca kalan bütçeye sığan çalıştırıcıları kabul eder; bu sayede küçük bir sunucuda taramalar başarısız olmak yerine kuyruğa alınır. Bu, "out-of-memory killer" tarafından sonlandırılmaktan çok daha güvenli bir hata modudur.

İki temizleme (prune) ayarı varsayılan olarak true değerindedir: ENGINE_AUTO_PRUNE_DOCKER_BUILD_CACHE ve ENGINE_AUTO_PRUNE_UNUSED_DOCKER_IMAGES. Bir görev tamamlandıktan sonra motor; kullanılmayan derleme önbelleğini, kullanılmayan imajları ve durdurulmuş tarama container'larını kaldırır. Çalışan bir container tarafından referans verilen imajlar, bind mount'lar, veritabanı verileri, kimlik bilgileri ve volume'lar korunur. Bu durum, sunucuyu başka işler için paylaşmamanız gerektiğinin bir başka nedenidir: yapılandırmadığınız bir temizleme aracı, Docker daemon üzerinde çalışmaktadır.

Yerel bir depoyu sızdırmadan tarama

LOCAL_REPOS_PATH varsayılan olarak ./local_repos dizinini kullanır ve bu dizin backend ile engine container'larına /local_repos yolunda bind-mount edilir; bu sayede ana makinede ilgili klasöre bıraktığınız bir depo, container'lar içinde anında görünür hale gelir. Çalışma dizininizi değil, temiz bir clone kullanın. İş container'ı, kendi içinde root yetkileriyle yazılabilir bir kopyaya ve dış dünyaya internet erişimine sahiptir; bu da kopyanın içindeki herhangi bir verinin değiştirilebileceği veya sunucu dışına gönderilebileceği anlamına gelir. Bir projeyi kopyalamadan önce .env dosyalarını ve özel anahtarları (private keys) temizleyin.

Ne elde edersiniz, ne elde etmezsiniz

Sıralanmış aday bulgular elde edersiniz. Doğrulanmış güvenlik açıkları elde etmezsiniz. Sıralama ve tekilleştirme, triyaj kuyruğunuzun düzenini belirler. Bir girdinin gerçek olduğunu kanıtlamazlar. Post-script dosyaları doğrulama yapmaya ve bir kavram kanıtı (proof of concept) oluşturmaya çalışabilir; bu, aracın sunduğu en güçlü sinyaldir ancak başarısız olan bir post-script, bulgunun yanlış olduğu anlamına gelmez. Her adayı yine de bir insan okur.

Bu kılavuz, open-kritt'in kaç gerçek hata bulduğu konusunda hiçbir iddiada bulunmaz çünkü bunu ölçmedik. Kod tabanınız için bir tespit oranı belirten herhangi biri, aracı sizin kod tabanınız üzerinde çalıştırmamıştır. Öncelikle halihazırda iyi bildiğiniz bir depoyu tarayın: kendi başınıza değerlendirebileceğiniz bulgular, mevcut en ucuz kalibrasyon yöntemidir.

Yetkilendirme, burada çoğu self-hosted araçtan daha önemlidir. Ajanlar kod derleyip çalıştırır ve ağa erişir; bu nedenle bir kavram kanıtı adımı canlı sistemlere dokunabilir. Aracı sahibi olduğunuz veya test etmek için sözleşme yaptığınız koda yönlendirin ve herhangi bir işlem yapmadan önce hedef kapsamı yazılı hale getirin. Eğer ANTHROPIC_API_KEY yapılandırmasını yapar ve Claude Code motorunu kullanırsanız, Claude Code'u bir VPS üzerinde güvenli bir şekilde çalıştırma bölümündeki korumalı alan (sandboxing) alışkanlıkları bu ajanlar için de geçerlidir.

FAQ

open-kritt neden kendi VPS'ine ihtiyaç duyar?

Analiz aracıları, kodunuzun yazılabilir kopyalarına ve doğrudan internet erişimine sahip geçici iş container'ları içinde root yetkisiyle çalışır. Motor servisi, iş başına bir container başlatabilmek için host üzerindeki Docker socket'ini mount eder. Bu socket'e erişebilen herhangi bir süreç, host dosya sistemini mount eden bir container başlatabilir; bu nedenle tüm yığının, üzerinde çalıştığı host'ta root yetkisine sahip olduğu varsayılmalıdır. Özel bir VPS üzerinde bu kabul edilebilir bir risktir ve sunucuyu yeniden kurmanın bir maliyeti yoktur. Günlük kullanılan bir iş istasyonunda ise bu durum, SSH anahtarlarınızı ve tarayıcı profillerinizi, taradığınız kodla aynı güven sınırına sokar.

SSH tüneli kullanmak yerine 5173 numaralı portu dışarıya açabilir miyim?

Bunu yapmamalısınız. Backend, uygulama düzeyinde kimlik doğrulama olmadan dağıtılır; bu nedenle internet ile bulgularınız ve sağlayıcı kredileriniz arasındaki tek engel bu porttur. compose dosyası, bu sebeple her servisi 127.0.0.1 adresine bağlar. Bunun yerine ssh -N -L 5173:127.0.0.1:5173 you@your-server-ip komutunu çalıştırın ve yerel olarak http://localhost:5173 adresine gidin. Bir ufw kuralı bunun yerini tutmaz, çünkü yayınlanan bir Docker portu, ufw'nin varsayılan politikası uygulanmadan önce işlenir.

open-kritt'in planladığımdan fazla harcama yapmasını nasıl engellerim?

İlk taramadan önce model sağlayıcınızın konsolundan kesin bir limit belirleyin, çünkü open-kritt'in kendi bütçe ayarı yoktur. İlk birkaç çalıştırmada varsayılan eşzamanlılık ayarlarını koruyun, ENGINE_WORKER_COUNT=2 ve ENGINE_MAX_CONCURRENT_SCANS=1 değerlerine dikkat edin. Bir sağlayıcı hesabının varsayılan olarak 15 eşzamanlı root model çağrısına izin verdiğini, bir Codex oturumunun ise beş adede kadar alt aracı çalıştırabileceğini unutmayın. ENGINE_WORKER_COUNT=0 komutu yeni işlerin alınmasını durdurur ve en hızlı yerel durdurma yöntemidir.

Hangi sürümü kullanmalıyım?

Her zaman bir etiket (tag) kullanın, asla main kullanmayın. git fetch --tags ve ardından git tag --list komutları mevcut sürümleri listeler; 4 Ağustos 2026 tarihinde yayınlanan v1.3.0, bu yazının yazıldığı tarih itibarıyla en güncel sürümdür. Sürümü sabitlemek, aylar sonra yapılacak bir yeniden kurulumda aynı yığının oluşmasını sağlar. Ayrıca yükseltme işlemini, sürüm notlarını okuduktan sonra bilinçli bir karar haline getirir; farklı bir günde klonlama yapıldığında ortaya çıkan bir yan etki olmaktan çıkarır.

Tarama hiç başlamıyor. Neleri kontrol etmeliyim?

Öncelikle boş disk alanını kontrol edin; motor, boş depolama alanı varsayılan olarak 20 GB olan ENGINE_MIN_FREE_STORAGE_GB değerinin altına düştüğünde iş başına tarama container'ı başlatmaz. Ardından ENGINE_WORKER_COUNT değerinin 0 olmadığını doğrulayın, çünkü bu değer yeni işlerin alınmasını durdurur. Son olarak ./kritt setup komutunu çalıştırarak model kimlik bilgilerinin gerçekten yapılandırıldığını teyit edin, çünkü GITHUB_TOKEN tek başına tarama yapamaz. docker compose logs engine komutu, işin neden atlandığının nedenini belirtir.