VPS वर open-kritt self-host करण्याची सुरक्षित पद्धत

लॅपटॉपवर नव्हे, तर VPS वर self-host open-kritt का करावे

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

Default setup मधील चार गुणधर्म या सल्ल्यामागे आहेत. हे चारही गुणधर्म project's README आणि compose file मधून येतात.

Agents शक्तिशाली असण्यासाठीच तयार केलेले आहेत. README नुसार tool-enabled agents disposable job containers मध्ये root म्हणून चालतात. त्यांच्याकडे writable repository copies आणि direct internet access असतो. त्यामुळे ते tools install करू शकतात, targets compile करू शकतात, tests चालवू शकतात आणि proofs of concept तयार करू शकतात. Scan म्हणजे files वाचणारा linter नाही. तुम्ही मागितलेले arbitrary code execution म्हणजे scan आहे. हा internet access दोन्ही बाजूंनी धोकादायक आहे. Target चा अभ्यास करताना agent जे काही fetch करतो ते untrusted text असते आणि ते त्याच्या prompt मध्ये येते. agent ला स्वतःचे web search देताना तुम्ही स्वीकारता तीच exposure येथेही असते.

Engine कडे Docker socket असतो. docker-compose.yml host Docker socket ला engine service मध्ये mount करते, कारण engine प्रत्येक job साठी एक scan container build करून launch करते. त्या socket पर्यंत पोहोचणारी कोणतीही process host filesystem mount करणारा container सुरू करू शकते. त्यामुळे हे engine ज्या host वर चालते, त्या host वर ते प्रभावीपणे root असते.

Login screen नाही. Backend कोणतेही application authentication घेऊन येत नाही. Port पर्यंतचा access म्हणजे तुमच्या findings आणि provider credit पर्यंतचा access.

तुम्ही scan करत असलेला code अनेकदा तुमचा नसतो. 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 चे काम लहान tasks मध्ये विभागते. त्यानंतर ते tasks अनेक AI agents वर parallel पद्धतीने चालवते आणि मिळालेल्या निष्कर्षांमधील duplicates काढून त्यांना rank करते. तुम्ही focused prompts ची chain म्हणून workflow define करता. प्रत्येक step ला त्यापूर्वीच्या steps कडून structured context मिळतो. Scan target remote किंवा local git repository असू शकतो. Analysis engine Codex किंवा Claude Code असतो. एखादा candidate आढळल्यानंतर optional post-scripts त्याची पडताळणी करण्याचा किंवा proof of concept तयार करण्याचा प्रयत्न करू शकतात.

शेवटी तुम्हाला candidates ची ranked list मिळते. तिच्याकडे report म्हणून नव्हे, तर triage queue म्हणून पाहा.

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

• Ubuntu 24.04, Debian 12 किंवा Rocky Linux 9 चालणारा VPS. x86_64 आणि ARM64 वर या वितरणांची चाचणी घेण्यात आली आहे, असे install दस्तऐवजांमध्ये नमूद आहे.
• Compose plugin सह Docker Engine.
• Host वर Node.js 20 किंवा त्याहून नवीन आवृत्ती, कारण ./kritt CLI container च्या आत न चालता host वर चालते.
• एक model provider: Codex login किंवा OPENAI_API_KEY, CODEX_API_KEY, ANTHROPIC_API_KEY किंवा OPENROUTER_API_KEY.
• Private repositories scan करायचे असल्यासच GITHUB_TOKEN आवश्यक आहे. उपलब्ध .env.example मध्ये हे स्पष्टपणे नमूद आहे: केवळ GitHub token वापरून scans चालवता येत नाहीत.

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 चे membership host वरील root इतकेच अधिकार देते. त्यामुळे open-kritt चालवणारे accountच या group मध्ये समाविष्ट करा. या setup ची अधिक विस्तृत आवृत्ती VPS वर Docker चालवणे येथे पहा.

Ubuntu 24.04 च्या स्वतःच्या repository मध्ये Node 18 उपलब्ध आहे. CLI 20 पेक्षा कमी आवृत्तीवर बंद होते. 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 वापरा.

टॅग केलेले release clone करा आणि त्याची आवृत्ती निश्चित करा

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

main तुमच्यासोबत पुढे बदलते. Tag बदलत नाही. August 2026 पर्यंत सर्वात नवीन tag v1.3.0 आहे. तो 4 August 2026 रोजी प्रकाशित झाला. तुम्ही clone करता त्या दिवशी उपलब्ध असलेली स्थिती git tag --list दाखवते. Tag checkout केल्यावर repository detached HEAD state मध्ये राहते. या परिस्थितीत ते योग्य आहे. हा clone तुम्ही निश्चित केलेले deployment म्हणून वापरत आहात; त्यावर commit करण्यासाठी branch म्हणून नाही. पुढे upgrade करायचे असल्यास release notes वाचा. त्यानंतर git fetch --tags चालवा, नवीन tag checkout करा आणि पुन्हा ./kritt start चालवा, कारण start images पुन्हा build करते.

sudo सोबत ./kritt चालवू नका. Documentation मध्ये याबाबत स्पष्ट सूचना आहे. CLI .data/ अंतर्गत project-local credential directories व्यवस्थापित करते. त्यामुळे root म्हणून चालवल्यास त्या directories root च्या मालकीच्या होतात आणि पुढील सामान्य run त्यामध्ये लिहू शकत नाही.

./kritt setup वापरून model access configure करा

./kritt setup

ही command .env अस्तित्वात नसल्यास ती .env.example पासून तयार करते, प्रत्येक credential ची स्थिती दाखवते आणि ती set किंवा unset करू देते. ती credential ची values terminal वर कधीही दाखवत नाही. .env आणि engine credential file या दोन्ही mode 0600 सह लिहिल्या जातात.

हे काम manually करायचे असल्यास:

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

त्यानंतर provider key .env मध्ये लिहा आणि file mode 0600 ठेवा. कोणतीही पद्धत वापरली तरी त्या server वर आता कार्यरत provider credential साठवलेले आहे. त्यामुळे त्या server वर इतर कोणतीही माहिती ठेवू नये, याचे हे आणखी एक कारण आहे. हा project वगळता इतर कशासाठीही वापरली जाणार नाही अशी key तयार करा. त्यामुळे ती नंतर revoke केल्यास महत्त्वाच्या कोणत्याही गोष्टीवर परिणाम होणार नाही. AI agents च्या आवाक्याबाहेर secrets ठेवणे या व्यापक पद्धतीचे स्पष्टीकरण देते.

पहिल्या scan पूर्वी provider spending cap सेट करा

open-kritt ची रचना अनेक कामे समांतरपणे पाठवण्यासाठी केली आहे आणि या प्रक्रियेसाठीच खर्च होतो. v1.3.0 मधील .env.example चे default मूल्ये मितव्ययी आहेत: ENGINE_WORKER_COUNT=2, ज्याचे वर्णन फाइलमध्ये लहान 2-vCPU मशीनसाठी conservative default असे केले आहे, आणि ENGINE_MAX_CONCURRENT_SCANS=1. यापेक्षा मोठी मर्यादा ENGINE_WORKERS_PER_ACCOUNT=15 आहे. एका provider account वर एकाच वेळी सुरू असलेल्या root model calls ची ही कमाल संख्या आहे. ENGINE_CODEX_MAX_SUBAGENTS_PER_SESSION=5 देखील लागू आहे, कारण Codex session एकावेळी पाच child agents पर्यंत चालवू शकते. मोठ्या VPS वर worker count वाढवल्यास एकाच वेळी सुरू असलेल्या model calls ची संख्या त्यानुसार वाढते.

Repository मधील कोणतीही सेटिंग तुमचा खर्च मर्यादित करत नाही. .env.example मध्ये budget setting नाही. Engine च्या स्वतःच्या stop conditions म्हणजे worker limits आणि ENGINE_HARNESS_TIMEOUT_SECONDS. प्रत्येक harness run साठी याचे default मूल्य 7200 seconds आहे. त्यामुळे खर्चाची कमाल मर्यादा provider कडेच सेट करावी लागते. Provider console उघडा आणि पहिल्या scan पूर्वी hard monthly limit सेट करा. Scan पूर्ण झाल्यानंतर ते करू नका. VPS वरील AI agent चा खर्च नियंत्रित करणे या मार्गदर्शिकेत प्रत्येक provider साठीच्या settings स्पष्ट केल्या आहेत.

स्थानिक पातळीवरही एक नियंत्रण आहे. ENGINE_WORKER_COUNT=0 सेट केल्यास नवीन jobs उचलणे थांबते. Stack सुरू झाल्यानंतर Settings screen मधून त्याच worker values बदलता येतात.

प्रत्येक scan साठीची किंमत या मार्गदर्शिकेत दिलेली नाही, कारण खर्च repository चा आकार, तुम्ही तयार केलेला workflow आणि त्यामागील model यांवर अवलंबून असतो. एका लहान repository वर एक scan चालवा. त्यानंतर मोठ्या repository वर scan सुरू करण्यापूर्वी provider चे usage page तपासा.

स्टॅक सुरू करा आणि तो निरोगी स्थितीत आहे का ते तपासा

./kritt start

यामुळे .env आणि किमान एक credential तपासले जाते. त्यानंतर docker compose up --build चालवले जाते. पहिला build धीमा असतो, कारण frontend, backend, engine, executor view आणि database images तयार केल्या जातात. हे foreground मध्येही चालते. त्यामुळे SSH session बंद केल्यास stack थांबतो. ते tmux मध्ये सुरू करा किंवा पहिला build यशस्वी झाल्यानंतर detached mode मध्ये सुरू करा. यापैकी कोणतीही पद्धत reboot नंतर stack आपोआप सुरू ठेवत नाही. सर्व्हर restart झाल्यानंतर stack पुन्हा सुरू हवा असल्यास, reboot नंतर self-hosted agent चालू ठेवणे मधील systemd unit pattern थेट वापरता येतो.

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 response मिळाल्यास backend सुरू आहे. Failed to connect to 127.0.0.1 port 3002: Connection refused मिळाल्यास backend सुरू नाही आणि docker compose logs backend कारण सांगेल. Repository directory मधून docker compose down वापरून सर्वकाही थांबवा.

एक पर्यायी कृती: docker compose exec backend npm run seed demo data लोड करते. वास्तविक scan साठी खर्च करण्यापूर्वी interface पाहण्याचा हा सोपा मार्ग आहे.

SSH tunnel द्वारे port 5173 वरील UI पर्यंत पोहोचा

compose file मधील प्रत्येक service defaultनुसार 127.0.0.1 ला bind होते: frontend 5173 वर, backend 3002 वर, executor view 8090 वर आणि Postgres 5432 वर. हे bindings बदलू नका. त्याऐवजी आपल्या स्वतःच्या machine वरून SSH द्वारे port forward करा.

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

ही command सुरू असताना आपल्या local browser मध्ये http://localhost:5173 उघडा. -N म्हणजे connection मध्ये port forwarding असेल आणि shell उघडला जाणार नाही. executor view देखील हवा असल्यास त्याच command मध्ये दुसरे -L 8090:127.0.0.1:8090 जोडा.

FRONTEND_BIND_ADDRESS=0.0.0.0 सेट करून tunnel टाळण्याचा मोह होतो. तसे करू नका. backend वर login screen नाही. त्यामुळे त्या page पर्यंत पोहोचणारी कोणतीही व्यक्ती scans सुरू करू शकते आणि आपल्या provider चे credit खर्च करू शकते. याखाली आणखी एक अडचण आहे: published container port वर ufw ची default policy लागू होण्यापूर्वीच प्रक्रिया होते. त्यामुळे ufw deny 5173 rule योग्य दिसत असला तरी तो काहीही block करत नाही. ufw ला bypass करणारे Docker ports मध्ये हे घडवणारी rule chain दाखवली आहे.

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

ENGINE_MIN_FREE_STORAGE_GB चे default मूल्य 20 आहे. उपलब्ध storage यापेक्षा कमी झाल्यावर engine नवीन per-job scan container सुरू करण्यास नकार देतो. Built images, checkout cache, Postgres data आणि job workspaces हे सर्व एकाच disk वर असतात. त्यामुळे 20 GB VPS वर scan कधीही सुरू होत नाही. 40 GB हे किमान आकार मानावा. मोठ्या repositories scan करत असल्यास त्यापेक्षा अधिक storage द्यावे.

Memory चे गणित सोपे आहे. ENGINE_MEMORY_RESERVE_GB=2 engine, database, API आणि अल्पकाळासाठी लागणाऱ्या अतिरिक्त प्रक्रियांसाठी memory राखून ठेवते. प्रत्येक scan runner साठी ENGINE_SCAN_RUNNER_MEMORY_MB=1536 इतकी reservation आणि hard cap असते. त्यामुळे इतर कोणतीही प्रक्रिया सुरू होण्यापूर्वीच दोन workers साठी सुमारे 5 GB memory आवश्यक असते. उरलेल्या budget मध्ये बसतील तेवढेच runners engine स्वीकारते. त्यामुळे लहान मशीनवर scans अयशस्वी होण्याऐवजी queue मध्ये थांबतात. Out-of-memory killer मुळे होणाऱ्या अपयशापेक्षा ही स्थिती बरी आहे.

दोन prune settings चे default मूल्य true आहे: ENGINE_AUTO_PRUNE_DOCKER_BUILD_CACHE आणि ENGINE_AUTO_PRUNE_UNUSED_DOCKER_IMAGES. Task पूर्ण झाल्यावर engine वापरात नसलेला build cache, वापरात नसलेल्या images आणि थांबलेले scan containers काढून टाकते. Running container कडून reference केलेल्या images, bind mounts, database data, credentials आणि volumes जतन केले जातात. Host share न करण्याचे हे आणखी एक कारण आहे. तुम्ही configure न केलेला pruner त्या Docker daemon वर काम करत असतो.

स्थानिक repository लीक न करता त्याचे scanning

LOCAL_REPOS_PATH चे default मूल्य ./local_repos आहे आणि ते backend व engine containers मध्ये /local_repos येथे bind-mount केले जाते. त्यामुळे host वरील त्या folder मध्ये ठेवलेले repository containers मध्ये त्वरित दिसते. तुमचा working tree वापरू नका; fresh clone वापरा. Job container मध्ये writable copy, त्याच्या स्वतःच्या आत root access आणि outbound internet access असतो. त्यामुळे त्या copy मधील कोणतीही सामग्री बदलली जाऊ शकते किंवा server बाहेर पाठवली जाऊ शकते. Project copy करण्यापूर्वी .env files आणि private keys काढून टाका.

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

तुम्हाला क्रमवारी लावलेले संभाव्य निष्कर्ष मिळतात. सत्यापित vulnerabilities मिळत नाहीत. Ranking आणि de-duplication तुमच्या triage queue चा क्रम ठरवतात. एखादी entry खरी आहे हे त्यातून सिद्ध होत नाही. Post-scripts validation करण्याचा आणि proof of concept तयार करण्याचा प्रयत्न करू शकतात. हे tool देत असलेला सर्वात मजबूत signal आहे. मात्र एखादा post-script अयशस्वी झाला, म्हणून finding खोटी आहे असे सिद्ध होत नाही. प्रत्येक संभाव्य निष्कर्ष माणसाने तपासणे आवश्यक आहे.

open-kritt ला किती खरे bugs सापडतात, याबाबत या guide मध्ये कोणताही दावा केलेला नाही, कारण आम्ही त्याचे मोजमाप केलेले नाही. तुमच्या codebase साठी detection rate सांगणाऱ्या व्यक्तीने ते tool तुमच्या codebase वर चालवलेले नाही. तुम्हाला आधीपासून चांगला परिचित असलेला repository प्रथम scan करा. स्वतः तपासता येणारे findings हे उपलब्ध असलेले सर्वात स्वस्त calibration आहेत.

इतर बहुतांश self-hosted tools पेक्षा येथे authorization अधिक महत्त्वाचे आहे. Agents code compile आणि execute करतात आणि network पर्यंत पोहोचतात. त्यामुळे proof-of-concept step मुळे live systems वर परिणाम होऊ शकतो. ज्या code चे तुम्ही मालक आहात किंवा ज्याची चाचणी करण्यासाठी तुम्हाला contract मिळाले आहे, त्यावरच ते चालवा. काहीही चालवण्यापूर्वी target scope लेखी नोंदवा. तुम्ही ANTHROPIC_API_KEY configure करून Claude Code engine वापरत असल्यास, VPS वर Claude Code सुरक्षितपणे चालवणे यामध्ये दिलेल्या sandboxing सवयी या agents साठीही लागू होतात.

FAQ

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

कारण त्याचे analysis agents writable code copies आणि direct internet access असलेल्या disposable job containers मध्ये root म्हणून चालतात. तसेच engine service host Docker socket mount करते, त्यामुळे प्रत्येक job साठी एक container सुरू करता येतो. त्या socket पर्यंत पोहोचणारी कोणतीही process host filesystem mount करणारा container सुरू करू शकते. त्यामुळे संपूर्ण stack ला त्याच्या host वर root म्हणूनच गृहीत धरावे. Dedicated VPS वर हा स्वीकारार्ह trade-off आहे आणि box पुन्हा build केल्याने तुमचे काही नुकसान होत नाही. तुमच्या दैनंदिन workstation वर मात्र तुम्ही scan करत असलेल्या code साठी SSH keys आणि browser profiles याच trust boundary मध्ये येतात.

SSH tunnel वापरण्याऐवजी port 5173 expose करू शकतो का?

तसे करू नये. Backend application authentication शिवाय release केलेले आहे. त्यामुळे 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 उघडा. ufw rule हा पर्याय पुरेसा नाही, कारण ufw ची default policy लागू होण्यापूर्वी published Docker port हाताळला जातो.

माझ्या नियोजित मर्यादेपेक्षा open-kritt अधिक खर्च करण्यापासून कसे थांबवू?

पहिला scan सुरू करण्यापूर्वी तुमच्या model provider च्या console मध्ये hard limit सेट करा, कारण open-kritt मध्ये स्वतःची budget setting नाही. पहिल्या काही runs साठी release सोबतचे concurrency defaults ठेवा, ENGINE_WORKER_COUNT=2 आणि ENGINE_MAX_CONCURRENT_SCANS=1, आणि लक्षात ठेवा की एका provider account मधून default स्थितीत जास्तीत जास्त 15 concurrent root model calls करता येतात, तर Codex session मध्ये जास्तीत जास्त five child agents चालू शकतात. ENGINE_WORKER_COUNT=0 नवीन jobs उचलणे थांबवते आणि स्थानिक पातळीवर सर्वात जलद stop आहे.

कोणती version checkout करावी?

Tag, main कधीही नाही. git fetch --tags नंतर git tag --list चालवल्यास उपलब्ध versions दिसतात. 4 August 2026 रोजी published केलेली v1.3.0 ही या लिखाणाच्या वेळी सर्वात नवीन version आहे. Pinning केल्याने काही महिन्यांनंतर केलेल्या rebuild मध्ये तोच stack तयार होतो. तसेच वेगळ्या दिवशी clone केल्यामुळे अनपेक्षित upgrade होण्याऐवजी release notes वाचून upgrade करण्याचा निर्णय तुम्ही घेऊ शकता.

Scan कधीच सुरू होत नाही. काय तपासावे?

सर्वप्रथम उपलब्ध disk space तपासा. Free storage ENGINE_MIN_FREE_STORAGE_GB पेक्षा कमी असल्यास engine प्रत्येक job साठी scan container सुरू करत नाही. याची default मर्यादा 20 GB आहे. त्यानंतर ENGINE_WORKER_COUNT ची value 0 नाही याची तपासणी करा, कारण त्या value मुळे नवीन jobs उचलणे थांबते. पुढे ./kritt setup चालवून model credential खरोखर configure केलेले आहे याची खात्री करा, कारण फक्त GITHUB_TOKEN असल्यास scans चालू शकत नाहीत. Job का skip झाला याचे कारण docker compose logs engine दाखवते.