VPS वर open-kritt कसे सेटअप करावे

तुमच्या लॅपटॉपऐवजी VPS वर open-kritt self-host का करावे

open-kritt अशा सर्व्हरवर self-host करा जो तुम्ही नष्ट करून पुन्हा तयार करू शकता. हे साधन त्याचे analysis agents root म्हणून disposable job containers मध्ये चालवते, प्रत्येक कंटेनरला तुमच्या कोडची writable प्रत आणि थेट इंटरनेट ॲक्सेस देते, आणि host Docker socket त्याच्या engine service मध्ये mount करते. या कामासाठी समर्पित असलेल्या मशीनवर हा एक रास्त तडजोड आहे. परंतु, ज्या मशीनवर तुमच्या SSH keys आहेत, तिथे ही एक मोठी चूक ठरू शकते.

डिफॉल्ट सेटअपचे चार गुणधर्म या सल्ल्याला कारणीभूत ठरतात आणि हे चारही गुणधर्म प्रकल्पाच्या स्वतःच्या README आणि compose फाईलमध्ये नमूद केलेले आहेत.

हे agents शक्तिशाली असण्यासाठीच बनवले आहेत. README मध्ये म्हटल्याप्रमाणे, tool-enabled agents हे root म्हणून disposable job containers मध्ये चालतात. त्यांना repository च्या writable प्रती आणि थेट इंटरनेट ॲक्सेस असतो, जेणेकरून ते टूल्स इन्स्टॉल करू शकतील, टार्गेट्स compile करू शकतील, टेस्ट्स रन करू शकतील आणि proofs of concept तयार करू शकतील. स्कॅन म्हणजे केवळ फाईल्स वाचणारा linter नाही. ही एक arbitrary code execution प्रक्रिया आहे, जी तुम्ही स्वतःहून सुरू केली आहे. इंटरनेट ॲक्सेस दोन्ही बाजूंनी काम करतो: टार्गेटवर संशोधन करताना एजंट जे काही मिळवतो, ते untrusted मजकूर म्हणून त्याच्या प्रॉम्प्टमध्ये येतो. जेव्हा तुम्ही एजंटला स्वतःचे वेब सर्च हाताळायला देता, तेव्हा तुम्ही याच धोक्याला निमंत्रण देत असता.

engine कडे Docker socket असते. docker-compose.yml हे host Docker socket ला engine service मध्ये mount करते, कारण engine प्रत्येक जॉबसाठी एक स्कॅन कंटेनर तयार करते आणि लाँच करते. ज्या प्रक्रियेला त्या socket पर्यंत पोहोचता येते, ती प्रक्रिया host filesystem mount करणारा कंटेनर सुरू करू शकते. त्यामुळे, engine ज्या host वर चालते, तिथे ते प्रभावीपणे root असते.

यात कोणतीही login screen नाही. backend मध्ये कोणतीही application authentication सुविधा नाही. पोर्टचा ॲक्सेस असणे म्हणजे तुमच्या निष्कर्षांचा आणि तुमच्या प्रोव्हायडर क्रेडिटचा ॲक्सेस असणे होय.

तुम्ही स्कॅन करत असलेला कोड अनेकदा तुमचा नसतो. एजंट्सना थर्ड-पार्टी repository कडे वळवणे म्हणजे त्या repository चे बिल्ड तुमच्या मशीनवर, root म्हणून आणि नेटवर्क ॲक्सेससह चालवणे होय.

जर तुम्ही coding agents disposable VM मध्ये का असावेत हे वाचले असेल, तर हा त्याच प्रकारचा threat model आहे, फक्त अधिक तीव्र. open-kritt साठी एक स्वतंत्र VPS वापरा ज्यावर इतर काहीही नसेल आणि त्या VPS ला root ऐवजी स्वतंत्र least-privilege user account वरून नियंत्रित करा.

open-kritt नक्की काय करते

open-kritt (याचे रिपॉझिटरी Kritt-ai/open-kritt आहे आणि ते AGPL-3.0 परवान्याअंतर्गत उपलब्ध आहे) असुरक्षितता संशोधनाचे (vulnerability research) लहान कामांमध्ये विभाजन करते, ही कामे AI एजंट्सद्वारे समांतरपणे चालवते आणि त्यानंतर मिळालेल्या निकालांमधून पुनरावृत्ती काढून त्यांची क्रमवारी लावते. तुम्ही वर्कफ्लोची व्याख्या एकाग्र प्रॉम्प्ट्सची साखळी म्हणून करता आणि प्रत्येक टप्प्याला मागील टप्प्यांकडून संरचित संदर्भ (structured context) मिळतो. स्कॅनचे लक्ष्य हे रिमोट किंवा स्थानिक git रिपॉझिटरी असते. विश्लेषण इंजिन म्हणून Codex किंवा Claude Code वापरले जाते. एखादा संभाव्य धोका (candidate) समोर आल्यानंतर, पर्यायी पोस्ट-स्क्रिप्ट्सद्वारे त्याचे प्रमाणीकरण किंवा proof of concept तयार करण्याचा प्रयत्न केला जाऊ शकतो. ही साखळी तयार करणे हे सुरक्षा कार्यापेक्षा सामान्य एजंट कार्यासारखे आहे, त्यामुळे जर प्रॉम्प्ट्स, टूल्स आणि संदर्भ देणे या गोष्टी तुमच्यासाठी नवीन असतील, तर एजंट्स कसे एकत्र केले जातात हे शिकणे तुम्हाला या मार्गदर्शिकेतील कोणत्याही सेटिंगपेक्षा अधिक चांगले परिणाम देईल.

शेवटी तुम्हाला संभाव्य धोक्यांची एक क्रमवारी लावलेली यादी मिळते. याकडे अहवाल म्हणून न पाहता, त्रुटी निवारण रांग (triage queue) म्हणून पहा.

सुरू करण्यापूर्वी आवश्यक गोष्टी

• Ubuntu 24.04, Debian 12 किंवा Rocky Linux 9 वर चालणारा एक VPS. इन्स्टॉल डॉक्युमेंट्समध्ये x86_64 आणि ARM64 आर्किटेक्चरवर या वितरणांची (distributions) चाचणी केल्याचे नमूद आहे.
• Docker Engine सोबत Compose प्लगइन.
• होस्टवर Node.js 20 किंवा त्यापुढील आवृत्ती, कारण ./kritt CLI कंटेनरच्या आत न चालता थेट होस्टवर चालते.
• एक मॉडेल प्रोव्हायडर: Codex लॉगिन, किंवा OPENAI_API_KEY, CODEX_API_KEY, ANTHROPIC_API_KEY किंवा OPENROUTER_API_KEY.
• GITHUB_TOKEN फक्त तेव्हाच आवश्यक आहे जर तुम्हाला खाजगी रिपॉझिटरीज स्कॅन करायच्या असतील. सोबत दिलेले .env.example हे स्पष्टपणे नमूद करते: केवळ GitHub टोकन वापरून स्कॅन चालवता येत नाही.

प्रथम Docker आणि Node 20 इंस्टॉल करा

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

नवीन ग्रुप मेंबरशिप लागू होण्यासाठी लॉग आउट करून पुन्हा लॉग इन करा, त्यानंतर Compose प्लगइन उपलब्ध असल्याची खात्री करा.

docker compose version

व्हर्जन स्ट्रिंगचा अर्थ असा आहे की Compose एक प्लगइन म्हणून इंस्टॉल केलेले आहे. docker: 'compose' is not a docker command चा अर्थ असा आहे की तुमच्याकडे जुनी स्टँडअलोन docker-compose बायनरी आहे, आणि open-kritt ला docker compose ची आवश्यकता आहे. docker ग्रुपचे सदस्यत्व हे होस्टवर root असण्यासारखेच आहे, म्हणून फक्त open-kritt चालवणारे खातेच त्यात समाविष्ट करा. या सेटअपच्या सविस्तर माहितीसाठी, VPS वर Docker चालवणे पहा.

Ubuntu 24.04 त्याच्या स्वतःच्या रिपॉझिटरीमध्ये Node 18 देते, आणि CLI 20 पेक्षा कमी असलेल्या कोणत्याही व्हर्जनवर बंद (exit) होते. NodeSource वापरा.

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

node -v ने v20. किंवा त्यापेक्षा जास्त व्हर्जन दर्शवले पाहिजे. Rocky Linux 9 वर यासाठी sudo dnf module enable nodejs:20 -y आणि त्यानंतर sudo dnf install -y nodejs वापरणे आवश्यक आहे.

open-kritt क्लोन करा आणि एका टॅग केलेल्या रिलीजला पिन करा

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

main तुमच्या अंतर्गत हलते. टॅग हलत नाही. ऑगस्ट 2026 पर्यंत सर्वात नवीन टॅग v1.3.0 आहे, जो 4 ऑगस्ट 2026 रोजी प्रकाशित झाला होता, आणि git tag --list तुम्ही क्लोन करता त्या दिवशी काय अस्तित्वात आहे ते दर्शवते. टॅग चेकआउट केल्यामुळे रिपॉझिटरी detached HEAD स्थितीत येते, जे येथे योग्य आहे: तुम्ही या क्लोनला पिन केलेले डिप्लॉयमेंट म्हणून हाताळत आहात, अशी शाखा म्हणून नाही जिथे तुम्ही कमिट करता. नंतर अपग्रेड करण्यासाठी, रिलीज नोट्स वाचा, त्यानंतर git fetch --tags चालवा, नवीन टॅग चेकआउट करा आणि पुन्हा ./kritt start चालवा, कारण start इमेज पुन्हा तयार (rebuild) करते.

./kritt ला sudo सह चालवू नका. दस्तऐवजीकरण याबद्दल स्पष्ट आहे. CLI हे .data/ अंतर्गत प्रोजेक्ट-लोकल क्रेडेंशियल डिरेक्टरीज व्यवस्थापित करते, त्यामुळे root म्हणून चालवल्यास त्या डिरेक्टरीजची मालकी root कडे जाते आणि पुढच्या सामान्य रनमध्ये त्यामध्ये लिहिता येत नाही.

./kritt setup सह मॉडेल ॲक्सेस कॉन्फिगर करा

./kritt setup

जेव्हा .env अस्तित्वात नसते, तेव्हा ही कमांड .env.example पासून ती तयार करते, प्रत्येक क्रेडेंशियलची स्थिती दर्शवते आणि तुम्हाला ती सेट किंवा अनसेट करण्याची परवानगी देते. ही कमांड कधीही क्रेडेंशियलची मूल्ये टर्मिनलवर प्रिंट करत नाही. .env आणि इंजिन क्रेडेंशियल फाईल दोन्ही 0600 मोडसह लिहिली जातात.

जर तुम्हाला हे काम स्वतः करायचे असेल तर:

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

त्यानंतर .env मध्ये प्रोव्हायडर की एडिट करा आणि फाईल 0600 मोडवर ठेवा. कोणत्याही पद्धतीने केले तरी, आता त्या सर्व्हरवर एक कार्यरत प्रोव्हायडर क्रेडेंशियल उपलब्ध आहे, आणि हेच एक कारण आहे की त्या सर्व्हरवर इतर कोणतीही महत्त्वाची माहिती नसावी. या प्रकल्पासाठी एक स्वतंत्र की तयार करा, जेणेकरून ती नंतर रद्द केल्यास तुमच्या इतर कोणत्याही कामात अडथळा येणार नाही. AI एजंट्सच्या आवाक्याबाहेर सिक्रेट्स ठेवणे या विषयावर अधिक सविस्तर माहिती दिली आहे.

पहिली स्कॅन करण्यापूर्वी प्रोव्हायडरवर खर्चाची मर्यादा (spending cap) सेट करा

open-kritt हे 'fan-out' (विस्तारित) पद्धतीने काम करण्यासाठी बनवले आहे आणि याच विस्तारामुळे तुम्हाला खर्च करावा लागतो. v1.3.0 मधील .env.example मधील डीफॉल्ट सेटिंग्ज सावधगिरीच्या आहेत: ENGINE_WORKER_COUNT=2, ज्याचे वर्णन फाईलमध्ये लहान 2-vCPU मशीनसाठी एक सुरक्षित डीफॉल्ट म्हणून केले आहे, आणि ENGINE_MAX_CONCURRENT_SCANS=1. याच्या वर ENGINE_WORKERS_PER_ACCOUNT=15 आहे, जी एका प्रोव्हायडर अकाउंटवर एकाच वेळी चालणाऱ्या रूट मॉडेल कॉल्सची कमाल मर्यादा आहे, आणि ENGINE_CODEX_MAX_SUBAGENTS_PER_SESSION=5, कारण एका Codex सेशनमध्ये पाच चाइल्ड एजंट्सपर्यंत काम चालू शकते. मोठ्या VPS वर वर्करची संख्या वाढवल्यास, एकाच वेळी होणाऱ्या मॉडेल कॉल्सची संख्याही वाढते.

रिपॉझिटरीमध्ये तुम्ही किती खर्च करता यावर कोणतीही मर्यादा नाही. .env.example मध्ये बजेट सेट करण्याची कोणतीही सोय नाही. इंजिनच्या स्वतःच्या थांबण्याच्या अटी म्हणजे त्या वर्करच्या मर्यादा आणि ENGINE_HARNESS_TIMEOUT_SECONDS, ज्याची डीफॉल्ट मर्यादा प्रति हार्नेस रन 7200 सेकंद आहे. येथे 'हार्नेस' म्हणजे तो लूप जो मॉडेलला टूल्स आणि संदर्भासह (context) तोपर्यंत कॉल करत राहतो जोपर्यंत रन थांबत नाही. त्यामुळे हा टाइमआउट मॉडेलभोवती असलेल्या प्रोग्रामच्या वेळेवर आधारित आहे, मॉडेलच्या खर्चावर नाही. म्हणून खर्चाची कमाल मर्यादा प्रोव्हायडरच्या स्तरावरच असावी. तुमच्या प्रोव्हायडरच्या कन्सोलमध्ये जा आणि पहिली स्कॅन करण्यापूर्वी, ती झाल्यानंतर नाही, एक निश्चित मासिक मर्यादा सेट करा. VPS वर AI एजंटचा खर्च कसा नियंत्रित करावा या मार्गदर्शिकेत प्रत्येक प्रोव्हायडरच्या सेटिंग्जची माहिती दिली आहे.

येथे एक स्थानिक 'ब्रेक' देखील आहे. ENGINE_WORKER_COUNT=0 सेट केल्यास नवीन जॉब्स घेणे थांबते आणि स्टॅक चालू असताना सेटिंग्ज स्क्रीनमध्ये वर्करची मूल्ये बदलता येतात.

या मार्गदर्शिकेत प्रति स्कॅन किती खर्च येईल हे दिलेले नाही, कारण तो खर्च रिपॉझिटरीचा आकार, तुम्ही तयार केलेला वर्कफ्लो आणि त्यामागील मॉडेलवर अवलंबून असतो. एका लहान रिपॉझिटरीवर एक स्कॅन चालवा आणि त्यानंतर मोठ्या रिपॉझिटरीवर स्कॅन करण्यापूर्वी तुमच्या प्रोव्हायडरच्या युसेज पेजवर जाऊन खर्चाची तपासणी करा.

स्टॅक सुरू करा आणि तो व्यवस्थित कार्यरत असल्याची खात्री करा

./kritt start

हे .env आणि किमान एक क्रेडेंशियल तपासते, त्यानंतर docker compose up --build चालवते. पहिली बिल्ड प्रक्रिया संथ असते, कारण ती frontend, backend, engine, executor view आणि database इमेजेस तयार करते. हे फॉरग्राउंडमध्ये चालते, त्यामुळे SSH सेशन बंद केल्यास स्टॅक थांबतो. ते tmux मध्ये सुरू करा, किंवा एकदा पहिली बिल्ड यशस्वी झाल्यावर ते detached मोडमध्ये सुरू करा. यापैकी कोणतीही पद्धत रीबूटनंतर आपोआप सुरू राहत नाही, त्यामुळे सर्व्हर रीस्टार्ट झाल्यावर स्टॅक पुन्हा सुरू ठेवण्यासाठी keeping a self-hosted agent running across reboots मधील systemd युनिट पॅटर्न थेट वापरता येतो.

docker compose up -d --build
docker compose ps

docker compose ps मध्ये open-kritt-frontend, open-kritt-backend, open-kritt-engine, open-kritt-executor-view आणि open-kritt-db दिसले पाहिजेत. त्यानंतर सर्व्हरवरच backend प्रतिसाद देत आहे का ते तपासा.

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

JSON प्रतिसाद मिळणे म्हणजे backend सुरू आहे. Failed to connect to 127.0.0.1 port 3002: Connection refused चा अर्थ ते सुरू नाही असा होतो आणि docker compose logs backend त्याचे कारण सांगेल. रिपॉझिटरी डिरेक्टरीमधून docker compose down वापरून सर्व काही थांबवा.

एक अतिरिक्त पर्याय: docker compose exec backend npm run seed डेमो डेटा लोड करते, जो प्रत्यक्ष स्कॅनवर खर्च करण्यापूर्वी इंटरफेस पाहण्याचा एक सोपा मार्ग आहे.

SSH टनेलद्वारे पोर्ट 5173 वर UI ॲक्सेस करणे

compose फाईलमधील प्रत्येक सेवा डीफॉल्टनुसार 127.0.0.1 वर बाइंड होते: फ्रंटएंड 5173 वर, बॅकएंड 3002 वर, एक्झिक्युटर व्ह्यू 8090 वर आणि Postgres 5432 वर. या बाइंडिंगमध्ये बदल करू नका, त्याऐवजी तुमच्या स्वतःच्या मशीनवरून SSH द्वारे पोर्ट फॉरवर्ड करा.

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

ही कमांड चालू असताना तुमच्या स्थानिक ब्राउझरमध्ये http://localhost:5173 उघडा. -N चा अर्थ असा की कनेक्शन फक्त फॉरवर्डिंग वाहून नेते आणि कोणतीही शेल देत नाही. जेव्हा तुम्हाला एक्झिक्युटर व्ह्यू देखील हवा असेल, तेव्हा त्याच कमांडमध्ये दुसरे -L 8090:127.0.0.1:8090 जोडा.

FRONTEND_BIND_ADDRESS=0.0.0.0 सेट करून टनेल टाळण्याची प्रवृत्ती होऊ शकते. असे करू नका. बॅकएंडला कोणतीही लॉगिन स्क्रीन नाही, त्यामुळे जो कोणी त्या पेजवर पोहोचेल तो स्कॅन सुरू करू शकतो आणि तुमचे प्रोव्हायडर क्रेडिट खर्च करू शकतो. याउलट, Vaultwarden हे इंटरनेटवर उघड राहण्यासाठी डिझाइन केलेले आहे आणि त्याचे हार्डनिंग हे ॲडमिन टोकन आणि बॅकअप फाईलवर अवलंबून असते, जे open-kritt मध्ये उपलब्ध नसलेले पर्याय आहेत. यामागे एक दुसरा धोका देखील आहे: पब्लिश केलेला कंटेनर पोर्ट ufw चे डीफॉल्ट धोरण लागू होण्यापूर्वीच हाताळला जातो, त्यामुळे ufw deny 5173 नियम योग्य वाटतो पण तो कशाचीही अडवणूक करत नाही. Docker ports that bypass ufw मध्ये ती नियम साखळी दर्शविली आहे ज्यामुळे हे घडते.

VPS चा आकार ठरवणे

ENGINE_MIN_FREE_STORAGE_GB चे डीफॉल्ट मूल्य 20 असते आणि मोकळी जागा त्यापेक्षा कमी झाल्यास इंजिन नवीन per-job scan कंटेनर सुरू करण्यास नकार देते. तयार केलेल्या इमेजेस, चेकआउट कॅशे, Postgres डेटा आणि जॉब वर्कस्पेस हे सर्व एकाच डिस्कवर असतात, त्यामुळे 20 GB च्या VPS वर स्कॅन कधीच सुरू होत नाही. 40 GB ला किमान मर्यादा (floor) माना आणि जर तुम्ही मोठ्या रिपॉझिटरीज स्कॅन करत असाल, तर अधिक जागा द्या. या सर्व्हरवर स्टोरेजचा जास्त वापर करणारी दुसरी सेवा ठेवण्याचा मोह टाळा, कारण PhotoPrism आणि Immich च्या या तुलनेत दर्शवलेली RAM आणि डिस्कची किमान गरज पाहता, मीडिया लायब्ररी स्कॅनसाठी आवश्यक असलेली जागा किती वेगाने संपवू शकते हे लक्षात येईल. स्कॅनरच्या बाजूला किरकोळ वाटणाऱ्या गोष्टींबाबतही हेच लागू होते: Jellyfin लायब्ररीला 90 च्या दशकातील रेंटल स्टोअरचे स्वरूप देणारे ब्राउझर फ्रंट-एंड देखील संपूर्ण मीडिया सर्व्हर आणि त्याचे ट्रान्सकोड्स डिस्कवर ओढते, त्यामुळे अशा सेवांसाठी वेगळा होस्ट वापरा.

मेमरीचे गणित साधे आहे. ENGINE_MEMORY_RESERVE_GB=2 इंजिन, डेटाबेस, API आणि अल्पकालीन ओव्हरहेडसाठी मेमरी राखून ठेवते आणि प्रत्येक स्कॅन रनरसाठी एक आरक्षण (reservation) आणि ENGINE_SCAN_RUNNER_MEMORY_MB=1536 ची हार्ड कॅप असते. त्यामुळे, इतर काहीही सुरू होण्यापूर्वी दोन वर्कर्सना सुमारे 5 GB मेमरीची आवश्यकता असते. इंजिन फक्त उरलेल्या बजेटमध्ये बसणारे रनर्सच स्वीकारते, त्यामुळे लहान सर्व्हरवर स्कॅन अयशस्वी होण्याऐवजी रांगेत (queue) राहतात, जे out-of-memory killer पेक्षा कितीतरी पटीने चांगले आहे. प्रत्येक कामाच्या युनिटसाठी स्वतंत्र कंटेनर वापरणाऱ्या कोणत्याही टूलसाठी हेच गणित लागू होते, म्हणूनच OpenBot चे प्रत्येक AI सहकाऱ्यासाठी एक कंटेनर आणि ब्राउझर हे CPU च्या मर्यादेपर्यंत पोहोचण्याआधीच RAM च्या मर्यादेत अडकते.

दोन prune सेटिंग्ज डीफॉल्टनुसार true असतात: ENGINE_AUTO_PRUNE_DOCKER_BUILD_CACHE आणि ENGINE_AUTO_PRUNE_UNUSED_DOCKER_IMAGES. एखादे काम पूर्ण झाल्यावर, इंजिन न वापरलेला बिल्ड कॅशे, न वापरलेल्या इमेजेस आणि थांबलेले स्कॅन कंटेनर काढून टाकते. चालू असलेल्या कंटेनरद्वारे संदर्भित इमेजेस, bind mounts, डेटाबेस डेटा, क्रेडेंशियल्स आणि व्हॉल्यूम्स जतन केले जातात. होस्ट शेअर न करण्याचे हे आणखी एक कारण आहे: तुम्ही कॉन्फिगर न केलेला प्रूनर (pruner) त्या Docker daemon वर चालत असतो.

स्थानिक रिपॉझिटरी स्कॅन करताना ती लीक होऊ नये याची काळजी घेणे

LOCAL_REPOS_PATH हे डीफॉल्टनुसार ./local_repos वर सेट केलेले असते आणि ते backend व engine कंटेनरमध्ये /local_repos येथे bind-mount केलेले असते. त्यामुळे तुम्ही होस्टवरील त्या फोल्डरमध्ये टाकलेली रिपॉझिटरी लगेच कंटेनरमध्ये दिसते. तुमच्या वर्किंग ट्रीऐवजी नेहमी नवीन clone वापरा. जॉब कंटेनरला एक writable प्रत मिळते, ज्यामध्ये तो स्वतः root असतो आणि त्याला इंटरनेटचा ॲक्सेस असतो. याचा अर्थ असा की त्या प्रतीमध्ये असलेली कोणतीही गोष्ट बदलली जाऊ शकते किंवा सर्व्हरच्या बाहेर पाठवली जाऊ शकते. प्रकल्प कॉपी करण्यापूर्वी त्यातील .env फाइल्स आणि खाजगी की (private keys) काढून टाका.

तुम्हाला काय मिळते आणि काय मिळत नाही

तुम्हाला उमेदवारांच्या निष्कर्षांची (candidate findings) क्रमवारी मिळते. तुम्हाला पडताळणी केलेल्या त्रुटी (verified vulnerabilities) मिळत नाहीत. क्रमवारी आणि डुप्लिकेट काढून टाकणे (de-duplication) यामुळे तुमच्या ट्रायज रांगेचा (triage queue) क्रम ठरतो. याचा अर्थ असा नाही की एखादी नोंद खरी आहे. पोस्ट-स्क्रिप्ट्स पडताळणी करण्याचा आणि 'प्रूफ ऑफ कन्सेप्ट' (proof of concept) तयार करण्याचा प्रयत्न करू शकतात, आणि हे टूलद्वारे मिळणारे सर्वात महत्त्वाचे संकेत आहेत, परंतु एखादी पोस्ट-स्क्रिप्ट अयशस्वी झाली म्हणजे तो निष्कर्ष खोटा आहे असे नाही. प्रत्येक उमेदवाराची तपासणी अजूनही एक व्यक्तीच करते. उमेदवार आणि पुरावा यातील फरकामुळेच तुम्ही स्वतः पुन्हा रन करू शकता असा पुरावा एजंटकडे मागणे येथे महत्त्वाचे ठरते: ज्या निष्कर्षाची तुम्ही मागणीनुसार पडताळणी करू शकता, त्याची किंमत केवळ क्रमवारी लावलेल्या आणि विश्वासावर आधारित निष्कर्षापेक्षा जास्त असते.

हे मार्गदर्शक open-kritt किती खऱ्या त्रुटी शोधते याबद्दल कोणताही दावा करत नाही, कारण आम्ही त्याचे मोजमाप केलेले नाही. जो कोणी तुमच्या कोडबेससाठी डिटेक्शन रेट सांगत असेल, त्याने तो तुमच्या कोडबेसवर रन केलेला नाही. प्रथम अशा रिपॉझिटरीवर स्कॅन करा जी तुम्हाला आधीच चांगली माहित आहे: ज्या निष्कर्षांचे मूल्यमापन तुम्ही स्वतः करू शकता, ते कॅलिब्रेशनसाठी सर्वात स्वस्त साधन आहे.

इतर बहुतांश self-hosted टूल्सच्या तुलनेत येथे अधिकृतता (authorization) अधिक महत्त्वाची आहे. एजंट्स कोड कंपाईल आणि एक्झिक्युट करतात तसेच नेटवर्कपर्यंत पोहोचतात, त्यामुळे 'प्रूफ ऑफ कन्सेप्ट'ची पायरी थेट सिस्टिम्सना स्पर्श करू शकते. हे टूल तुमच्या मालकीच्या किंवा ज्याची चाचणी घेण्यासाठी तुम्ही कंत्राट घेतले आहे अशा कोडवरच वापरा आणि काहीही रन करण्यापूर्वी लक्ष्य व्याप्ती (target scope) लिहून ठेवा. जर तुम्ही ANTHROPIC_API_KEY कॉन्फिगर केले असेल आणि Claude Code इंजिन वापरत असाल, तर Claude Code सुरक्षितपणे VPS वर रन करणे मधील सँडबॉक्सिंगच्या सवयी या एजंट्सनाही लागू होतात.

FAQ

open-kritt ला स्वतःचे VPS का आवश्यक आहे?

कारण याचे analysis agents रूट युजर म्हणून disposable job containers मध्ये चालतात. या कंटेनर्सना तुमच्या कोडच्या writable प्रतींचा ॲक्सेस असतो आणि त्यांना थेट इंटरनेट ॲक्सेस असतो. तसेच, इंजिन सर्व्हिस होस्टचा Docker socket माउंट करते, जेणेकरून ती प्रत्येक जॉबसाठी एक स्वतंत्र कंटेनर सुरू करू शकेल. जो प्रोसेस या सॉकेटपर्यंत पोहोचू शकतो, तो असा कंटेनर सुरू करू शकतो जो होस्टची फाईलसिस्टम माउंट करेल; त्यामुळे संपूर्ण स्टॅककडे होस्टवरील रूट ॲक्सेस असल्यासारखेच पाहावे लागते. एका समर्पित VPS वर हा धोका स्वीकारार्ह आहे आणि सर्व्हर पुन्हा तयार करणे सोपे असते. तुमच्या दैनंदिन वर्कस्टेशनवर हे केल्यास, तुमच्या SSH keys आणि ब्राउझर प्रोफाइल्स त्याच ट्रस्ट बाउंड्रीमध्ये येतात जिथे तुम्ही स्कॅन करत असलेला कोड असतो.

मी SSH टनेल वापरण्याऐवजी पोर्ट 5173 उघडू शकतो का?

तुम्ही असे करू नये. बॅकएंडमध्ये ॲप्लिकेशन-स्तरीय ऑथेंटिकेशन नसते, त्यामुळे इंटरनेट आणि तुमच्या फाईंडिंग्स किंवा प्रोव्हायडर क्रेडिट यांच्यामध्ये फक्त हा पोर्टच असतो. याच कारणास्तव compose फाईल प्रत्येक सर्व्हिसला 127.0.0.1 वर बाइंड करते. त्याऐवजी ssh -N -L 5173:127.0.0.1:5173 you@your-server-ip चालवा आणि स्थानिक पातळीवर http://localhost:5173 वर ब्राउझ करा. ufw नियम हा यावर उपाय नाही, कारण पब्लिश केलेला Docker पोर्ट ufw चे डीफॉल्ट धोरण लागू होण्यापूर्वीच हाताळला जातो.

open-kritt ने नियोजित बजेटपेक्षा जास्त खर्च करू नये म्हणून मी काय करावे?

पहिले स्कॅन करण्यापूर्वीच तुमच्या मॉडेल प्रोव्हायडरच्या कन्सोलमध्ये एक हार्ड लिमिट सेट करा, कारण open-kritt मध्ये बजेट सेट करण्याची स्वतःची सोय नाही. पहिल्या काही रनसाठी दिलेले डीफॉल्ट concurrency सेटिंग्ज तसेच ठेवा, जसे की ENGINE_WORKER_COUNT=2 आणि ENGINE_MAX_CONCURRENT_SCANS=1. हे लक्षात ठेवा की एका प्रोव्हायडर अकाउंटवर डीफॉल्टनुसार 15 पर्यंत एकाच वेळी रूट मॉडेल कॉल्स करता येतात, तर Codex सेशनमध्ये पाच पर्यंत चाइल्ड एजंट्स चालू शकतात. ENGINE_WORKER_COUNT=0 नवीन जॉब्स घेणे थांबवते आणि हे थांबवण्याचे सर्वात जलद स्थानिक साधन आहे.

मी कोणती आवृत्ती (version) चेक आउट करावी?

नेहमी टॅग वापरा, कधीही main वापरू नका. git fetch --tags आणि त्यानंतर git tag --list चालवल्यास उपलब्ध आवृत्त्या दिसतील. 4 ऑगस्ट 2026 रोजी प्रकाशित झालेली v1.3.0 ही या लेखनानुसार सर्वात नवीन आवृत्ती आहे. आवृत्ती पिन केल्यामुळे काही महिन्यांनंतर पुन्हा बिल्ड केल्यास तोच स्टॅक मिळतो. यामुळे अपग्रेड करणे हा एक विचारपूर्वक घेतलेला निर्णय ठरतो, जो तुम्ही रिलीज नोट्स वाचल्यानंतर घेता, केवळ वेगळ्या दिवशी क्लोन केल्यामुळे होणारा अनपेक्षित बदल नाही.

स्कॅन सुरूच होत नाही. मी काय तपासावे?

प्रथम मोकळी डिस्क स्पेस तपासा, कारण जेव्हा मोकळी जागा ENGINE_MIN_FREE_STORAGE_GB (डीफॉल्ट 20 GB) पेक्षा कमी असते, तेव्हा इंजिन प्रत्येक जॉबसाठी स्कॅन कंटेनर सुरू करत नाही. त्यानंतर तपासा की ENGINE_WORKER_COUNT ची किंमत 0 नाही, कारण ती किंमत नवीन जॉब्स घेणे थांबवते. त्यानंतर ./kritt setup चालवून खात्री करा की मॉडेल क्रेडेंशियल खरोखर कॉन्फिगर केले आहे, कारण केवळ GITHUB_TOKEN स्कॅन चालवू शकत नाही. docker compose logs engine जॉब का वगळला याचे कारण दर्शवते.