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

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

open-kritt को ऐसे सर्वर पर self-host करें जिसे आप नष्ट करके दोबारा बना सकें। यह टूल अपने analysis agents को disposable job containers के अंदर root के रूप में चलाता है, प्रत्येक को आपके कोड की एक writable copy और सीधा internet access देता है, और 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 और सीधा internet access मिलता है, ताकि वे tools install कर सकें, targets compile कर सकें, tests चला सकें और proofs of concept बना सकें। एक scan केवल files पढ़ने वाला linter नहीं है। यह arbitrary code execution है जिसे आपने स्वयं करने के लिए कहा है। वह internet access दोनों तरफ काम करता है: एक 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) रूप से चलाता है, और फिर प्राप्त परिणामों से डुप्लिकेट हटाकर उन्हें रैंक करता है। आप एक workflow को केंद्रित prompts की एक श्रृंखला के रूप में परिभाषित करते हैं, और प्रत्येक चरण को पिछले चरणों से संरचित संदर्भ (structured context) प्राप्त होता है। स्कैन का लक्ष्य एक remote या local git repository होता है। विश्लेषण इंजन Codex या Claude Code है। एक candidate मिलने के बाद, वैकल्पिक post-scripts उसे validate करने या proof of concept बनाने का प्रयास कर सकती हैं।

अंत में आपको candidates की एक रैंक की गई सूची मिलती है। इसे एक 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 चलाता है। उस सेटअप के विस्तृत संस्करण के लिए, VPS पर Docker चलाना देखें।

Ubuntu 24.04 अपने repository में Node 18 प्रदान करता है, और CLI 20 से नीचे के किसी भी version पर 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 move नहीं होता है। अगस्त 2026 तक सबसे नया tag v1.3.0 है, जिसे 4 अगस्त 2026 को प्रकाशित किया गया था, और 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 को फिर से build करता है।

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

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

./kritt setup

जब .env मौजूद नहीं होता है, तो यह कमांड उसे .env.example से बनाती है, प्रत्येक 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 को दूर रखना इस व्यापक आदत को कवर करता है।

पहली स्कैन से पहले प्रोवाइडर स्पेंडिंग कैप (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 है, जो एक प्रोवाइडर अकाउंट पर अनुमत अधिकतम समवर्ती (concurrent) रूट मॉडल कॉल्स की संख्या है, और ENGINE_CODEX_MAX_SUBAGENTS_PER_SESSION=5 है, क्योंकि एक Codex सत्र में पांच चाइल्ड एजेंट्स तक चल सकते हैं। एक बड़े VPS पर वर्कर काउंट बढ़ाने से मॉडल कॉल्स की संख्या भी उसी अनुपात में बढ़ जाती है।

रिपॉजिटरी में ऐसा कुछ भी नहीं है जो आपके खर्च को सीमित करे। .env.example में कोई बजट सेटिंग नहीं है। इंजन की अपनी स्टॉप कंडीशंस केवल वे वर्कर लिमिट्स और ENGINE_HARNESS_TIMEOUT_SECONDS हैं, जो डिफ़ॉल्ट रूप से प्रति हार्नेस रन 7200 सेकंड पर सेट है। इसलिए, खर्च की अधिकतम सीमा आपको प्रोवाइडर के स्तर पर ही तय करनी होगी। अपना प्रोवाइडर कंसोल खोलें और पहली स्कैन के बाद नहीं, बल्कि उससे पहले एक हार्ड मंथली लिमिट सेट करें। VPS पर AI एजेंट की लागत को नियंत्रित करना लेख में प्रत्येक प्रोवाइडर के लिए उपलब्ध सेटिंग्स के बारे में विस्तार से बताया गया है।

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

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

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

./kritt start

यह .env और कम से कम एक क्रेडेंशियल की जाँच करता है, फिर docker compose up --build चलाता है। पहला बिल्ड धीमा होता है, क्योंकि यह frontend, backend, engine, executor view और database images को बनाता है। यह foreground में भी चलता है, इसलिए SSH session बंद करने से स्टैक रुक जाता है। इसे tmux के अंदर शुरू करें, या एक बार पहला बिल्ड सफल हो जाने पर इसे detached मोड में चलाएं। इनमें से कोई भी reboot के बाद अपने आप चालू नहीं रहता है, इसलिए यदि आप चाहते हैं कि सर्वर रीस्टार्ट होने के बाद स्टैक वापस चालू हो जाए, तो keeping a self-hosted agent running across reboots में दिया गया systemd unit पैटर्न सीधे लागू होता है।

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 खर्च कर सकता है। इसके नीचे एक दूसरा खतरा भी है: एक published container port को ufw की डिफ़ॉल्ट policy लागू होने से पहले ही handle कर लिया जाता है, इसलिए एक ufw deny 5173 rule सही दिखता है लेकिन कुछ भी block नहीं करता। Docker ports that bypass ufw उस rule chain को दिखाता है जो इसका कारण बनती है।

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

ENGINE_MIN_FREE_STORAGE_GB का डिफ़ॉल्ट मान 20 है, और जब खाली स्टोरेज इससे कम हो जाता है, तो इंजन नया per-job scan container शुरू करने से मना कर देता है। बिल्ड की गई इमेजेस, चेकआउट कैश, Postgres डेटा और जॉब वर्कस्पेस सभी एक ही डिस्क पर रहते हैं, इसलिए 20 GB का VPS कभी भी स्कैन शुरू नहीं कर पाता है। 40 GB को न्यूनतम सीमा मानें, और यदि आप बड़े रिपॉजिटरी स्कैन करते हैं तो अधिक स्टोरेज दें।

मेमोरी का हिसाब सरल गणित पर आधारित है। ENGINE_MEMORY_RESERVE_GB=2 इंजन, डेटाबेस, API और अल्पकालिक ओवरहेड के लिए मेमोरी सुरक्षित रखता है, और प्रत्येक स्कैन रनर के लिए ENGINE_SCAN_RUNNER_MEMORY_MB=1536 का रिज़र्वेशन और हार्ड कैप होता है। इसलिए, किसी भी अन्य चीज़ के चलने से पहले दो वर्कर्स को लगभग 5 GB मेमोरी की आवश्यकता होती है। इंजन केवल उन्हीं रनर्स को अनुमति देता है जो शेष बजट में फिट होते हैं, इसलिए छोटे सर्वर पर स्कैन फेल होने के बजाय कतार (queue) में लग जाते हैं, जो out-of-memory killer की तुलना में कहीं बेहतर स्थिति है।

दो प्रून (prune) सेटिंग्स डिफ़ॉल्ट रूप से true पर सेट होती हैं: ENGINE_AUTO_PRUNE_DOCKER_BUILD_CACHE और ENGINE_AUTO_PRUNE_UNUSED_DOCKER_IMAGES। कार्य पूरा होने के बाद, इंजन अप्रयुक्त बिल्ड कैश, अप्रयुक्त इमेजेस और रुके हुए स्कैन कंटेनर्स को हटा देता है। चल रहे कंटेनर द्वारा संदर्भित इमेजेस, बाइंड माउंट्स, डेटाबेस डेटा, क्रेडेंशियल्स और वॉल्यूम्स सुरक्षित रहते हैं। यह होस्ट को साझा न करने का एक और कारण है: एक ऐसा प्रूनर जो आपने कॉन्फ़िगर नहीं किया है, वह उस Docker daemon पर चल रहा है।

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

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

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

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

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

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

FAQ

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

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

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

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

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

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

मुझे कौन सा version check out करना चाहिए?

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

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

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