VPS पर open-kritt को self-host कैसे करें

अपने लैपटॉप के बजाय VPS पर open-kritt को self-host क्यों करें

open-kritt को ऐसे सर्वर पर self-host करें जिसे आप नष्ट और पुनः निर्मित (rebuild) कर सकें। यह टूल अपने analysis agents को disposable job containers के अंदर root के रूप में चलाता है, प्रत्येक को आपके कोड की एक writable copy और सीधा इंटरनेट एक्सेस देता है, और host Docker socket को अपनी engine service में mount करता है। इस काम के लिए समर्पित मशीन पर यह एक उचित समझौता है। लेकिन जिस मशीन में आपकी SSH keys मौजूद हों, उस पर यह एक बुरा निर्णय है।

default setup के चार गुण इस सलाह को प्रेरित करते हैं, और ये चारों गुण प्रोजेक्ट के अपने README और compose file से आते हैं।

Agents शक्तिशाली होने के लिए बनाए गए हैं। README कहता है कि tool-enabled agents disposable job containers के अंदर root के रूप में चलते हैं, जिन्हें writable repository copies और सीधा इंटरनेट एक्सेस मिलता है, ताकि वे tools install कर सकें, targets compile कर सकें, tests चला सकें और proofs of concept बना सकें। एक scan केवल files पढ़ने वाला linter नहीं है। यह मनमाना code execution (arbitrary code execution) है जिसे आपने स्वयं करने के लिए कहा है। वह इंटरनेट एक्सेस दोनों तरफ काम करता है: एक agent target पर शोध करते समय जो कुछ भी fetch करता है, वह untrusted text के रूप में उसके prompt में आता है, वही जोखिम जो आप तब उठाते हैं जब आप किसी agent को उसका अपना web search सौंपते हैं।

Engine के पास Docker socket होता है। docker-compose.yml host Docker socket को engine service में mount करता है, क्योंकि engine प्रति job एक scan container बनाता और launch करता है। जो भी process उस socket तक पहुँच सकती है, वह ऐसा container शुरू कर सकती है जो host filesystem को mount कर ले। इसलिए, engine प्रभावी रूप से उस host पर root है जिस पर वह चलता है।

इसमें कोई login screen नहीं है। backend बिना किसी application authentication के आता है। port तक पहुँच का अर्थ है आपके findings और आपके provider credit तक पहुँच।

आप जिस कोड को scan करते हैं, वह अक्सर आपका नहीं होता। agents को किसी third-party repository की ओर इंगित करने का अर्थ है उस repository के build को अपनी मशीन पर, root के रूप में, network access के साथ चलाना।

यदि आपने coding agents को disposable VM में क्यों रखना चाहिए पढ़ा है, तो यह वही threat model है, बस और अधिक शक्तिशाली। open-kritt को एक ऐसा VPS दें जिस पर कुछ और न हो, और उस VPS को root के बजाय एक अलग least-privilege user account से संचालित करें।

open-kritt वास्तव में क्या करता है

open-kritt (repository Kritt-ai/open-kritt है, जो AGPL-3.0 लाइसेंस के अंतर्गत है) भेद्यता अनुसंधान (vulnerability research) को छोटे कार्यों में विभाजित करता है, इन कार्यों को AI agents पर समानांतर (parallel) रूप से चलाता है, और फिर प्राप्त परिणामों को de-duplicate करके रैंक करता है। आप एक workflow को केंद्रित prompts की एक श्रृंखला के रूप में परिभाषित करते हैं, और प्रत्येक चरण को पिछले चरणों से संरचित संदर्भ (structured context) प्राप्त होता है। स्कैन का लक्ष्य एक remote या local git repository होता है। विश्लेषण इंजन Codex या Claude Code है। उम्मीदवार (candidate) मिलने के बाद, वैकल्पिक post-scripts उसे validate करने या proof of concept बनाने का प्रयास कर सकती हैं। उस श्रृंखला को डिज़ाइन करना सुरक्षा कार्य के बजाय सामान्य agent कार्य है, इसलिए यदि prompts, tools और context passing अभी भी आपके लिए अपरिचित हैं, तो agents को एक साथ कैसे रखा जाता है, यह सीखना इस गाइड की किसी भी सेटिंग की तुलना में आपके परिणामों के लिए अधिक प्रभावी होगा।

अंत में आपको उम्मीदवारों की एक रैंक की गई सूची मिलती है। इसे एक रिपोर्ट के रूप में नहीं, बल्कि triage queue के रूप में देखें।

शुरू करने से पहले आपकी आवश्यकताएं

• Ubuntu 24.04, Debian 12 या Rocky Linux 9 पर चलने वाला एक VPS। इंस्टॉलेशन दस्तावेज़ x86_64 और ARM64 पर इन वितरित संस्करणों को ही टेस्ट किया हुआ बताते हैं।
• 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

नया group membership लागू करने के लिए log out करके पुनः log in करें, फिर पुष्टि करें कि Compose plugin मौजूद है।

docker compose version

एक version string का मतलब है कि Compose एक plugin के रूप में इंस्टॉल है। docker: 'compose' is not a docker command का मतलब है कि आपके पास पुराना standalone docker-compose binary है, और open-kritt docker compose को कॉल करता है। docker group की सदस्यता host पर root के बराबर है, इसलिए केवल उस account को इसमें रखें जो open-kritt चलाता है। उस setup के विस्तृत संस्करण के लिए, VPS पर Docker चलाना देखें।

Ubuntu 24.04 अपने repository में 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. या उससे अधिक print करना चाहिए। Rocky Linux 9 पर इसके समकक्ष sudo dnf module enable nodejs:20 -y है, जिसके बाद sudo dnf install -y nodejs आता है।

open-kritt को clone करें और एक tagged release को pin करें

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

main आपके अधीन move हो जाता है। एक tag ऐसा नहीं करता। अगस्त 2026 तक, सबसे नया tag v1.3.0 है, जिसे 4 अगस्त 2026 को publish किया गया था, और git tag --list यह दिखाता है कि clone करने के दिन क्या मौजूद है। किसी tag को checkout करने पर repository detached HEAD state में आ जाती है, जो यहाँ सही है: आप इस clone को एक pinned deployment के रूप में उपयोग कर रहे हैं, न कि ऐसी branch के रूप में जिसमें आप commit करते हैं। बाद में upgrade करने के लिए, release notes पढ़ें, फिर git fetch --tags चलाएँ, नए tag को checkout करें, और फिर से ./kritt start चलाएँ, क्योंकि start images को rebuild करता है।

./kritt को sudo के साथ न चलाएँ। documentation में इसके बारे में स्पष्ट निर्देश दिए गए हैं। CLI, .data/ के अंतर्गत project-local credential directories को manage करता है, इसलिए root के रूप में चलाने पर उन directories का ownership root के पास चला जाता है और अगली सामान्य run उन्हें write नहीं कर पाती।

./kritt setup के साथ model access कॉन्फ़िगर करें

./kritt setup

यह कमांड मौजूद न होने पर .env.example से .env बनाती है, प्रत्येक credential की स्थिति प्रिंट करती है, और आपको उन्हें सेट या अनसेट करने की सुविधा देती है। यह कभी भी मानों (values) को टर्मिनल पर प्रिंट नहीं करती है। .env और इंजन क्रेडेंशियल फ़ाइल दोनों को 0600 मोड के साथ लिखा जाता है।

यदि आप इसे मैन्युअल रूप से करना चाहते हैं:

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

फिर प्रदाता की key को .env में एडिट करें और फ़ाइल को 0600 मोड पर ही रहने दें। किसी भी तरीके से, अब उस सर्वर पर एक कार्यशील प्रदाता क्रेडेंशियल मौजूद है, जो एक और कारण है कि इस बॉक्स में कुछ और नहीं होना चाहिए। केवल इस प्रोजेक्ट के लिए एक key बनाएँ, ताकि बाद में इसे रद्द करने पर आपकी किसी महत्वपूर्ण चीज़ पर असर न पड़े। AI agents की पहुँच से secrets को दूर रखना इस व्यापक आदत को कवर करता है।

पहली स्कैन से पहले प्रोवाइडर स्पेंडिंग कैप सेट करें

open-kritt को fan-out के लिए बनाया गया है, और आप इसी 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 पर वर्कर काउंट बढ़ाने से इन-फ़्लाइट मॉडल कॉल की संख्या भी बढ़ जाती है।

Repository में आपके खर्च की कोई अधिकतम सीमा तय नहीं है। .env.example में budget setting नहीं है। Engine की अपनी stop conditions में worker limits और ENGINE_HARNESS_TIMEOUT_SECONDS शामिल हैं, जो प्रति harness run डिफ़ॉल्ट रूप से 7200 seconds है। यहाँ harness उस loop को कहते हैं जो tools और context के साथ model को बार-बार call करता है, जब तक run समाप्त न हो जाए। इसलिए यह timeout model के चारों ओर चल रहे program पर लागू wall clock सीमा है, न कि उसके भीतर model द्वारा किए जाने वाले खर्च की सीमा। इसलिए खर्च की अधिकतम सीमा provider स्तर पर तय करनी होगी। पहला scan शुरू करने से पहले अपने provider console में hard monthly limit सेट करें, scan के बाद नहीं। VPS पर AI agent की लागत नियंत्रित करना में प्रत्येक provider की settings का तरीका बताया गया है।

यहाँ एक लोकल ब्रेक भी है। ENGINE_WORKER_COUNT=0 सेट करने से नए जॉब्स का पिकअप रुक जाता है, और स्टैक चलने के बाद सेटिंग्स स्क्रीन में उन्हीं वर्कर मानों को बदला जा सकता है।

यह गाइड प्रति स्कैन किसी मूल्य का उल्लेख नहीं करती है, क्योंकि लागत रिपॉजिटरी के आकार, आपके द्वारा बनाए गए वर्कफ़्लो और उसके पीछे के मॉडल पर निर्भर करती है। किसी भी बड़ी चीज़ पर इसे पॉइंट करने से पहले, एक छोटी रिपॉजिटरी पर एक स्कैन चलाएँ और फिर अपने प्रोवाइडर का यूसेज पेज देखें।

स्टैक शुरू करें और इसकी स्थिति की जाँच करें

./kritt start

यह कमांड .env और कम से कम एक क्रेडेंशियल की जाँच करता है, और फिर docker compose up --build चलाता है। पहला बिल्ड धीमा होता है, क्योंकि यह frontend, backend, engine, executor view और database इमेजेस को बिल्ड करता है। यह foreground में भी चलता है, इसलिए 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 tunnel के माध्यम से port 5173 पर UI तक पहुँचें

compose file में प्रत्येक service डिफ़ॉल्ट रूप से 127.0.0.1 पर bind होती है: frontend 5173 पर, backend 3002 पर, executor view 8090 पर और Postgres 5432 पर। इन bindings को न बदलें और अपनी मशीन से SSH के जरिए port को forward करें।

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

जब वह command चल रही हो, तो अपने स्थानीय browser में http://localhost:5173 खोलें। -N का अर्थ है कि connection केवल forward को ले जाता है और कोई shell नहीं देता। जब आपको executor view की भी आवश्यकता हो, तो उसी command में एक दूसरा -L 8090:127.0.0.1:8090 जोड़ें।

प्रलोभन यह होता है कि FRONTEND_BIND_ADDRESS=0.0.0.0 सेट कर दिया जाए और tunnel को छोड़ दिया जाए। ऐसा न करें। backend में कोई login screen नहीं है, इसलिए जो कोई भी उस page तक पहुँचता है, वह scan शुरू कर सकता है और आपके provider credit खर्च कर सकता है। इसके विपरीत, Vaultwarden को internet का सामना करने के लिए डिज़ाइन किया गया है, और इसे सुरक्षित करना अभी भी admin token और backup file पर निर्भर करता है, जो कि open-kritt आपको नहीं देता है। इसके नीचे एक दूसरा जाल भी है: एक published container port को ufw की डिफ़ॉल्ट policy लागू होने से पहले ही handle कर लिया जाता है, इसलिए एक ufw deny 5173 rule सही दिखता है लेकिन कुछ भी block नहीं करता है। Docker ports जो ufw को bypass करते हैं उस rule chain को दिखाता है जो इसका कारण बनती है।

VPS का आकार निर्धारित करना

ENGINE_MIN_FREE_STORAGE_GB का default मान 20 है। Free storage इससे कम होने पर engine नया per-job scan container शुरू नहीं करता। Built images, checkout cache, Postgres data और job workspaces सभी एक ही disk पर रहते हैं। इसलिए 20 GB VPS पर scan कभी शुरू नहीं होता। 40 GB को न्यूनतम मानें। बड़े repositories scan करने पर इससे अधिक storage दें। केवल host की लागत निकालने के लिए उसके साथ storage-hungry service चलाने से बचें। PhotoPrism और Immich की इस तुलना में मापी गई RAM और disk की न्यूनतम आवश्यकताएँ दिखाती हैं कि media library scan के लिए जरूरी headroom कितनी जल्दी खत्म कर सकती है। यही बात उन अतिरिक्त सुविधाओं पर भी लागू होती है जो scanner के पास देखने में हल्की लगती हैं। Jellyfin library को 90s rental store जैसा रूप देने वाला browser front end भी पूरा media server और उसके transcodes disk पर रखता है। इसलिए उसे किसी अलग host पर चलाएँ।

मेमोरी का हिसाब सरल गणित पर आधारित है। ENGINE_MEMORY_RESERVE_GB=2 इंजन, डेटाबेस, API और अल्पकालिक ओवरहेड के लिए मेमोरी सुरक्षित रखता है, और प्रत्येक scan runner के लिए ENGINE_SCAN_RUNNER_MEMORY_MB=1536 का reservation और hard cap होता है। इसलिए, किसी भी अन्य चीज़ के चलने से पहले दो workers को लगभग 5 GB की आवश्यकता होती है। इंजन केवल उन्हीं runners को अनुमति देता है जो शेष बजट में फिट होते हैं, इसलिए छोटे बॉक्स पर स्कैन विफल होने के बजाय कतार (queue) में लग जाते हैं, जो out-of-memory killer की तुलना में कहीं बेहतर failure mode है। यही गणित उन सभी टूल्स के लिए न्यूनतम सीमा निर्धारित करता है जो काम की प्रत्येक इकाई के लिए अपना स्वयं का container देते हैं, यही कारण है कि OpenBot का प्रति AI coworker एक container और browser CPU सीमा तक पहुँचने से बहुत पहले ही RAM की सीमा तक पहुँच जाता है।

दो prune सेटिंग्स डिफ़ॉल्ट रूप से true पर सेट होती हैं: ENGINE_AUTO_PRUNE_DOCKER_BUILD_CACHE और ENGINE_AUTO_PRUNE_UNUSED_DOCKER_IMAGES। कार्य पूरा होने के बाद, इंजन unused build cache, unused images और रुके हुए scan containers को हटा देता है। चल रहे container द्वारा संदर्भित images, bind mounts, डेटाबेस डेटा, क्रेडेंशियल्स और volumes सुरक्षित रहते हैं। यह होस्ट को साझा न करने का एक और कारण है: एक pruner जिसे आपने कॉन्फ़िगर नहीं किया है, वह उस Docker daemon पर चल रहा है।

किसी लोकल रिपॉजिटरी को लीक किए बिना स्कैन करना

LOCAL_REPOS_PATH डिफ़ॉल्ट रूप से ./local_repos पर सेट होता है और इसे backend तथा engine कंटेनर्स में /local_repos पर bind-mount किया जाता है, इसलिए जिस रिपॉजिटरी को आप होस्ट पर उस फ़ोल्डर में डालते हैं, वह तुरंत कंटेनर्स के अंदर दिखाई देने लगती है। अपने वर्किंग ट्री के बजाय एक फ्रेश क्लोन का उपयोग करें। जॉब कंटेनर को एक writable कॉपी मिलती है, जिसके अंदर उसे root एक्सेस प्राप्त होता है और उसे इंटरनेट का आउटबाउंड एक्सेस भी मिलता है, जिसका अर्थ है कि उस कॉपी में मौजूद कोई भी चीज़ बदली जा सकती है या बॉक्स से बाहर भेजी जा सकती है। किसी प्रोजेक्ट को कॉपी करने से पहले उसमें से .env फ़ाइलों और प्राइवेट कीज़ (private keys) को हटा दें।

आपको क्या मिलता है, और क्या नहीं मिलता

आपको रैंक किए गए संभावित निष्कर्ष (candidate findings) मिलते हैं। आपको सत्यापित कमजोरियां (verified vulnerabilities) नहीं मिलती हैं। रैंकिंग और डी-डुप्लीकेशन आपकी ट्राइएज कतार (triage queue) का क्रम तय करते हैं। वे यह साबित नहीं करते कि कोई प्रविष्टि वास्तविक है। पोस्ट-स्क्रिप्ट सत्यापन का प्रयास कर सकते हैं और एक प्रूफ-ऑफ-कांसेप्ट तैयार कर सकते हैं, और यह टूल द्वारा दिया जाने वाला सबसे मजबूत संकेत है, लेकिन यदि कोई पोस्ट-स्क्रिप्ट विफल हो जाती है, तो यह इस बात का प्रमाण नहीं है कि निष्कर्ष गलत है। हर संभावित निष्कर्ष को अभी भी एक व्यक्ति ही पढ़ता है। एक संभावित निष्कर्ष और प्रमाण के बीच का यही अंतर कारण है कि किसी एजेंट से ऐसे प्रमाण मांगना जिन्हें आप स्वयं फिर से चला सकें यहाँ उपयोगी है: एक ऐसा निष्कर्ष जिसे आप मांग पर पुनरुत्पादित (reproduce) कर सकते हैं, उस रैंक किए गए निष्कर्ष से अधिक मूल्यवान है जिसे आपको केवल विश्वास पर लेना पड़ता है।

यह गाइड इस बारे में कोई दावा नहीं करती है कि open-kritt कितने वास्तविक बग ढूंढता है, क्योंकि हमने इसे मापा नहीं है। जो कोई भी आपके कोडबेस के लिए डिटेक्शन रेट का दावा करता है, उसने इसे आपके कोडबेस पर नहीं चलाया है। सबसे पहले उस रिपॉजिटरी को स्कैन करें जिसे आप पहले से अच्छी तरह जानते हैं: जिन निष्कर्षों का आप स्वयं मूल्यांकन कर सकते हैं, वे उपलब्ध सबसे किफायती कैलिब्रेशन हैं।

यहाँ अधिकांश self-hosted टूल्स की तुलना में ऑथराइजेशन अधिक मायने रखता है। एजेंट कोड को कंपाइल और निष्पादित (execute) करते हैं और नेटवर्क तक पहुँचते हैं, इसलिए प्रूफ-ऑफ-कांसेप्ट चरण लाइव सिस्टम को प्रभावित कर सकता है। इसे उस कोड पर पॉइंट करें जिसे आप ओन करते हैं या जिसे टेस्ट करने के लिए आप अनुबंधित हैं, और कुछ भी चलाने से पहले टारगेट स्कोप को लिख लें। यदि आप ANTHROPIC_API_KEY को कॉन्फ़िगर करते हैं और Claude Code इंजन का उपयोग करते हैं, तो Claude Code को VPS पर सुरक्षित रूप से चलाने की सैंडबॉक्सिंग आदतें इन एजेंटों पर भी लागू होती हैं।

FAQ

open-kritt को अपने स्वयं के VPS की आवश्यकता क्यों है?

क्योंकि इसके analysis agents आपके कोड की writable प्रतियों के साथ और सीधे इंटरनेट एक्सेस के साथ disposable job containers के अंदर root के रूप में चलते हैं, और क्योंकि engine service होस्ट Docker socket को माउंट करती है ताकि वह प्रति जॉब एक container लॉन्च कर सके। जो भी process उस socket तक पहुँचती है, वह ऐसा container शुरू कर सकती है जो होस्ट filesystem को माउंट करता है, इसलिए पूरे stack को उसके होस्ट पर root के समान माना जाना चाहिए। एक समर्पित VPS पर यह एक स्वीकार्य समझौता है, और सर्वर को फिर से बनाने में आपकी कोई लागत नहीं आती। आपके दैनिक वर्कस्टेशन पर, यह आपकी SSH keys और browser profiles को उसी trust boundary के अंदर रखता है जहाँ वह कोड है जिसे आप स्कैन कर रहे हैं।

क्या मैं SSH tunnel का उपयोग करने के बजाय port 5173 को expose कर सकता हूँ?

आपको ऐसा नहीं करना चाहिए। यह backend बिना application authentication के आता है, इसलिए यह port ही इंटरनेट और आपके findings तथा provider credit के बीच एकमात्र सुरक्षा है। इसी कारण से compose file हर service को 127.0.0.1 पर bind करती है। ssh -N -L 5173:127.0.0.1:5173 you@your-server-ip चलाएँ और स्थानीय रूप से http://localhost:5173 पर ब्राउज़ करें। एक ufw rule इसका विकल्प नहीं है, क्योंकि एक प्रकाशित Docker port को ufw की डिफ़ॉल्ट नीति लागू होने से पहले ही handle कर लिया जाता है।

मैं open-kritt को मेरी योजना से अधिक खर्च करने से कैसे रोकूँ?

पहले स्कैन से पहले अपने model provider के कंसोल में एक hard limit सेट करें, क्योंकि open-kritt की अपनी कोई बजट सेटिंग नहीं है। पहले कुछ runs के लिए डिफ़ॉल्ट concurrency सेटिंग्स रखें, ENGINE_WORKER_COUNT=2 और ENGINE_MAX_CONCURRENT_SCANS=1, और याद रखें कि एक provider account डिफ़ॉल्ट रूप से 15 concurrent root model calls की अनुमति देता है, जबकि एक Codex session पाँच child agents तक चला सकता है। ENGINE_WORKER_COUNT=0 नई जॉब्स को लेना बंद कर देता है और यह सबसे तेज़ स्थानीय स्टॉप है।

मुझे कौन सा version चेक आउट करना चाहिए?

हमेशा एक tag, कभी भी main नहीं। git fetch --tags के बाद git tag --list चलाने से उपलब्ध विकल्प दिखते हैं, और v1.3.0, जिसे 4 August 2026 को प्रकाशित किया गया था, इस लेखन के समय सबसे नया है। पिनिंग का अर्थ है कि महीनों बाद फिर से निर्माण करने पर भी वही stack प्राप्त होगा, और यह अपग्रेड को एक ऐसा निर्णय बनाता है जिसे आप release notes पढ़ने के बाद लेते हैं, न कि किसी अलग दिन क्लोन करने का एक दुष्प्रभाव।

स्कैन कभी शुरू नहीं होता। मुझे क्या चेक करना चाहिए?

सबसे पहले खाली डिस्क स्पेस चेक करें, क्योंकि जब खाली स्टोरेज ENGINE_MIN_FREE_STORAGE_GB से कम होती है, तो engine प्रति-जॉब स्कैन container लॉन्च नहीं करेगा, जो डिफ़ॉल्ट रूप से 20 GB है। फिर चेक करें कि ENGINE_WORKER_COUNT शून्य (0) तो नहीं है, क्योंकि वह मान नई जॉब्स को लेना रोक देता है। फिर पुष्टि करें कि model credential वास्तव में कॉन्फ़िगर है, इसके लिए ./kritt setup चलाएँ, क्योंकि केवल एक GITHUB_TOKEN स्कैन नहीं चला सकता। docker compose logs engine उस कारण का नाम बताता है कि उसने जॉब को क्यों छोड़ दिया।