VPSలో open-kritt ను self-host చేయడం ఎలా

మీ ల్యాప్‌టాప్‌లో కాకుండా VPSలో open-kritt ను ఎందుకు self-host చేయాలి

మీరు ఎప్పుడైనా తొలగించి, తిరిగి నిర్మించగల సర్వర్‌లో open-kritt ను self-host చేయండి. ఈ సాధనం తన analysis agents ను root వినియోగదారుగా, తాత్కాలిక job containers లో నడుపుతుంది. ఇది ప్రతి ఏజెంట్‌కు మీ కోడ్ యొక్క writable కాపీని, నేరుగా ఇంటర్నెట్ యాక్సెస్‌ను ఇస్తుంది మరియు హోస్ట్ యొక్క Docker socket ను దాని engine service లోకి మౌంట్ చేస్తుంది. ఈ పని కోసం కేటాయించిన సర్వర్‌లో ఇది సమంజసమైన పద్ధతి. కానీ మీ SSH keys ఉన్న మెషీన్‌లో ఇది చాలా ప్రమాదకరమైనది.

ఈ సూచనకు కారణం డిఫాల్ట్ సెటప్‌లోని నాలుగు లక్షణాలు. ఇవన్నీ ప్రాజెక్ట్ యొక్క README మరియు compose ఫైల్ నుండి తీసుకున్నవే.

ఏజెంట్లు శక్తివంతమైనవి. సాధనాలతో కూడిన ఏజెంట్లు root వినియోగదారుగా, తాత్కాలిక job containers లో నడుస్తాయని README చెబుతోంది. వీటికి కోడ్ రిపోజిటరీలపై writable యాక్సెస్ మరియు నేరుగా ఇంటర్నెట్ యాక్సెస్ ఉంటాయి. తద్వారా అవి టూల్స్‌ను ఇన్‌స్టాల్ చేయడం, కోడ్‌ను కంపైల్ చేయడం, పరీక్షలు నిర్వహించడం మరియు proof of concept లను రూపొందించడం చేయగలవు. స్కాన్ అంటే కేవలం ఫైళ్లను చదివే linter కాదు. ఇది మీరు కోరిన arbitrary code execution.

ఇంజిన్ Docker socket ను కలిగి ఉంటుంది. docker-compose.yml హోస్ట్ యొక్క Docker socket ను ఇంజిన్ సర్వీస్‌లోకి మౌంట్ చేస్తుంది, ఎందుకంటే ఇంజిన్ ప్రతి జాబ్‌కు ఒక స్కాన్ కంటైనర్‌ను నిర్మించి, ప్రారంభిస్తుంది. ఆ socket ను చేరుకోగల ఏ ప్రాసెస్ అయినా, హోస్ట్ ఫైల్‌సిస్టమ్‌ను మౌంట్ చేయగల కంటైనర్‌ను ప్రారంభించగలదు. కాబట్టి, ఈ ఇంజిన్ ఏ హోస్ట్‌లో నడిస్తే, ఆ హోస్ట్‌పై దానికి root స్థాయి అధికారాలు ఉన్నట్లే.

లాగిన్ స్క్రీన్ లేదు. ఈ బ్యాకెండ్‌లో అప్లికేషన్ అథెంటికేషన్ లేదు. పోర్ట్‌కు యాక్సెస్ ఉంటే, మీ ఫలితాలకు మరియు మీ ప్రొవైడర్ క్రెడిట్‌లకు యాక్సెస్ ఉన్నట్లే.

మీరు స్కాన్ చేసే కోడ్ తరచుగా మీది కాదు. ఏజెంట్లను థర్డ్-పార్టీ రిపోజిటరీలకు పాయింట్ చేయడం అంటే, ఆ రిపోజిటరీ యొక్క బిల్డ్ ప్రాసెస్‌ను మీ మెషీన్‌లో, root గా, నెట్‌వర్క్ యాక్సెస్‌తో నడపడమే.

మీరు కోడింగ్ ఏజెంట్లు ఎందుకు తాత్కాలిక VM లో ఉండాలి అనే వ్యాసాన్ని చదివి ఉంటే, ఇది అదే తరహా ముప్పు (threat model), కానీ ఇంకా తీవ్రమైనది. open-kritt కోసం వేరే ఏమీ లేని ఒక ప్రత్యేక VPS ను కేటాయించండి. ఆ VPS ను root కాకుండా, తక్కువ అధికారాలు కలిగిన ప్రత్యేక వినియోగదారు ఖాతా ద్వారా నిర్వహించండి.

open-kritt వాస్తవానికి ఏమి చేస్తుంది

open-kritt (దీని రిపోజిటరీ Kritt-ai/open-kritt, ఇది AGPL-3.0 లైసెన్స్ కలిగి ఉంది) వల్నరబిలిటీ పరిశోధనను చిన్న చిన్న పనులుగా విభజిస్తుంది. ఈ పనులను AI ఏజెంట్ల ద్వారా సమాంతరంగా (parallel) రన్ చేస్తుంది, ఆపై వచ్చిన ఫలితాల నుండి డూప్లికేట్లను తొలగించి, వాటిని ర్యాంక్ చేస్తుంది. మీరు ఒక వర్క్‌ఫ్లోను కేంద్రీకృత ప్రాంప్ట్‌ల గొలుసుగా నిర్వచించవచ్చు, ప్రతి దశకు అంతకుముందు జరిగిన దశల నుండి నిర్మాణాత్మక సందర్భం (structured context) అందుతుంది. స్కాన్ చేయాల్సిన లక్ష్యం (target) ఒక రిమోట్ లేదా లోకల్ git రిపోజిటరీ. దీని విశ్లేషణ ఇంజిన్ Codex లేదా Claude Code. ఒక అభ్యర్థి (candidate) కనిపించిన తర్వాత, దానిని ధృవీకరించడానికి లేదా ప్రూఫ్ ఆఫ్ కాన్సెప్ట్ (proof of concept) రూపొందించడానికి ఐచ్ఛిక పోస్ట్-స్క్రిప్ట్‌లను ఉపయోగించవచ్చు.

చివరికి మీకు లభించేది ర్యాంక్ చేయబడిన అభ్యర్థుల జాబితా. దీనిని ఒక రిపోర్టుగా కాకుండా, ప్రాధాన్యత క్రమంలో ఉన్న తనిఖీ క్యూ (triage queue) గా పరిగణించండి.

ప్రారంభించడానికి ముందు మీకు కావాల్సినవి

• Ubuntu 24.04, Debian 12 లేదా Rocky Linux 9 నడుస్తున్న ఒక VPS. ఇన్‌స్టాలేషన్ డాక్యుమెంట్లు x86_64 మరియు ARM64 ఆర్కిటెక్చర్‌లపై ఈ డిస్ట్రిబ్యూషన్లను పరీక్షించినట్లు పేర్కొన్నాయి.
• Compose ప్లగిన్‌తో కూడిన Docker Engine.
• హోస్ట్‌లో 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 ని రన్ చేసే అకౌంట్‌ను మాత్రమే ఇందులో చేర్చండి. ఆ సెటప్ గురించి మరింత సమాచారం కోసం, running Docker on a VPS చూడండి.

Ubuntu 24.04 తన సొంత రిపోజిటరీలో 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 ని ఉపయోగించడం.

open-kritt ను క్లోన్ చేసి, ఒక నిర్దిష్ట ట్యాగ్ ఉన్న release ను పిన్ చేయడం

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 చూపిస్తుంది. ఒక ట్యాగ్‌ను checkout చేసినప్పుడు repository 'detached HEAD' స్థితిలోకి వెళ్తుంది, ఇది ఇక్కడ సరైనదే: మీరు ఈ క్లోన్‌ను ఒక పిన్ చేయబడిన deployment గా పరిగణిస్తున్నారు, మీరు commit చేసే branch గా కాదు. తర్వాత upgrade చేయడానికి, release notes చదివి, ఆపై git fetch --tags రన్ చేసి, కొత్త ట్యాగ్‌ను checkout చేసి, మళ్ళీ ./kritt start రన్ చేయండి, ఎందుకంటే start ఇమేజ్‌లను మళ్ళీ నిర్మిస్తుంది (rebuild).

./kritt ను sudo తో రన్ చేయవద్దు. డాక్యుమెంటేషన్ దీని గురించి స్పష్టంగా చెబుతోంది. CLI అనేది .data/ కింద ప్రాజెక్ట్-స్థానిక క్రెడెన్షియల్ డైరెక్టరీలను నిర్వహిస్తుంది. కాబట్టి root గా రన్ చేస్తే, ఆ డైరెక్టరీల యాజమాన్యం root కి వెళ్తుంది, దీనివల్ల తర్వాత సాధారణ వినియోగదారుగా రన్ చేసినప్పుడు వాటిలో రాయడం సాధ్యపడదు.

./kritt setup తో మోడల్ యాక్సెస్‌ను కాన్ఫిగర్ చేయడం

./kritt setup

ఈ కమాండ్ .env.example ఫైల్ లేనప్పుడు దాని నుండి .env ను సృష్టిస్తుంది, ప్రతి క్రెడెన్షియల్ స్థితిని ప్రింట్ చేస్తుంది మరియు వాటిని సెట్ చేయడానికి లేదా అన్‌సెట్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది. ఇది ఎప్పుడూ విలువలను టెర్మినల్‌లో ప్రింట్ చేయదు. .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 సెకన్లుగా ఉంటుంది. కాబట్టి, గరిష్ట పరిమితిని ప్రొవైడర్ వద్దే సెట్ చేయాలి. మీ ప్రొవైడర్ కన్సోల్‌ను ఓపెన్ చేసి, మొదటి స్కాన్ తర్వాత కాకుండా, దానికి ముందే నెలవారీ ఖర్చు పరిమితిని సెట్ చేయండి. VPSలో AI ఏజెంట్ ఖర్చును నియంత్రించడం అనే గైడ్ ప్రతి ప్రొవైడర్ సెట్టింగ్‌ల గురించి వివరిస్తుంది.

స్థానికంగా కూడా ఒక బ్రేక్ ఉంది. ENGINE_WORKER_COUNT=0 ని సెట్ చేయడం ద్వారా కొత్త జాబ్‌ల స్వీకరణను తాత్కాలికంగా నిలిపివేయవచ్చు. స్టాక్ రన్ అవుతున్నప్పుడు సెట్టింగ్స్ స్క్రీన్‌లో కూడా అదే వర్కర్ విలువలను మార్చుకోవచ్చు.

ఈ గైడ్‌లో ప్రతి స్కాన్‌కు అయ్యే ఖర్చును పేర్కొనలేదు, ఎందుకంటే ఆ ఖర్చు రిపోజిటరీ పరిమాణం, మీరు రూపొందించే వర్క్‌ఫ్లో మరియు దాని వెనుక ఉన్న మోడల్‌పై ఆధారపడి ఉంటుంది. ఒక చిన్న రిపోజిటరీపై ఒక స్కాన్ రన్ చేయండి, ఆపై ఏదైనా పెద్ద దానిపై ప్రయోగించే ముందు మీ ప్రొవైడర్ యొక్క వినియోగ పేజీని (usage page) తనిఖీ చేయండి.

స్టాక్‌ను ప్రారంభించి అది ఆరోగ్యంగా ఉందో లేదో తనిఖీ చేయండి

./kritt start

ఇది .env మరియు కనీసం ఒక క్రెడెన్షియల్‌ను తనిఖీ చేస్తుంది, ఆపై docker compose up --buildని రన్ చేస్తుంది. మొదటి బిల్డ్ నెమ్మదిగా ఉంటుంది, ఎందుకంటే ఇది frontend, backend, engine, executor view మరియు database ఇమేజ్‌లను బిల్డ్ చేస్తుంది. ఇది ఫోర్‌గ్రౌండ్‌లో కూడా రన్ అవుతుంది, కాబట్టి SSH సెషన్‌ను క్లోజ్ చేస్తే స్టాక్ ఆగిపోతుంది. దీన్ని tmux లోపల ప్రారంభించండి, లేదా మొదటి బిల్డ్ విజయవంతమైన తర్వాత దీన్ని డిటాచ్డ్ మోడ్‌లో రన్ చేయండి. వీటిలో ఏదీ రీబూట్ తర్వాత స్వయంచాలకంగా ప్రారంభం కాదు, కాబట్టి సర్వర్ రీస్టార్ట్ అయిన తర్వాత స్టాక్ మళ్లీ అందుబాటులోకి రావాలంటే, 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కి బైండ్ అవుతుంది: frontend 5173లో, backend 3002లో, executor view 8090లో మరియు Postgres 5432లో ఉంటాయి. ఆ బైండింగ్‌లను మార్చవద్దు, మీ సొంత మెషీన్ నుండి SSH ద్వారా పోర్ట్‌ను ఫార్వర్డ్ చేయండి.

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

ssh -L 5173:localhost:5173 user@your-server-ip -N

ఆ కమాండ్ రన్ అవుతున్నప్పుడు మీ లోకల్ బ్రౌజర్‌లో http://localhost:5173ని తెరవండి. -N అంటే కనెక్షన్ ఫార్వర్డ్‌ను మాత్రమే తీసుకువెళుతుందని, షెల్ ఉండదని అర్థం. మీకు executor view కూడా కావాలంటే అదే కమాండ్‌కు రెండవ -L 8090:127.0.0.1:8090ని జోడించండి.

FRONTEND_BIND_ADDRESS=0.0.0.0ని సెట్ చేసి టన్నెల్‌ను దాటవేయాలనే ఆలోచన కలగవచ్చు. అలా చేయకండి. backendకు లాగిన్ స్క్రీన్ ఉండదు, కాబట్టి ఆ పేజీని చేరుకున్న ఎవరైనా స్కాన్‌లను ప్రారంభించగలరు మరియు మీ ప్రొవైడర్ క్రెడిట్‌ను ఖర్చు చేయగలరు. దీని కింద రెండవ ప్రమాదం ఉంది: పబ్లిష్ చేయబడిన కంటైనర్ పోర్ట్, ufw యొక్క డిఫాల్ట్ పాలసీ వర్తించకముందే హ్యాండిల్ చేయబడుతుంది, కాబట్టి ufw deny 5173 రూల్ సరైనదిగా అనిపించినా ఏదీ బ్లాక్ చేయదు. ufwని దాటవేసే Docker పోర్ట్‌లు దీనికి కారణమయ్యే రూల్ చైన్‌ను చూపుతుంది.

VPS పరిమాణాన్ని నిర్ణయించడం

ENGINE_MIN_FREE_STORAGE_GB డిఫాల్ట్‌గా 20కి సెట్ చేయబడి ఉంటుంది. అందుబాటులో ఉన్న స్టోరేజ్ దీనికంటే తక్కువకు పడిపోయినప్పుడు, కొత్త పర్-జాబ్ స్కాన్ కంటైనర్‌ను ప్రారంభించడానికి ఇంజిన్ నిరాకరిస్తుంది. బిల్డ్ చేసిన ఇమేజ్‌లు, చెకౌట్ క్యాచీ, Postgres డేటా మరియు జాబ్ వర్క్‌స్పేస్‌లు అన్నీ ఒకే డిస్క్‌లో ఉంటాయి, కాబట్టి 20 GB VPS లో స్కాన్ ఎప్పటికీ ప్రారంభం కాదు. కనీసం 40 GB స్టోరేజ్‌ను ప్రామాణికంగా పరిగణించండి, ఒకవేళ మీరు పెద్ద రిపోజిటరీలను స్కాన్ చేస్తుంటే అంతకంటే ఎక్కువ కేటాయించండి.

మెమరీ అవసరాలను సాధారణ గణితంతో లెక్కించవచ్చు. ENGINE_MEMORY_RESERVE_GB=2 ఇంజిన్, డేటాబేస్, API మరియు స్వల్పకాలిక ఓవర్‌హెడ్ కోసం కొంత మెమరీని కేటాయిస్తుంది. ప్రతి స్కాన్ రన్నర్ ఒక రిజర్వేషన్ మరియు ENGINE_SCAN_RUNNER_MEMORY_MB=1536 గరిష్ట పరిమితిని (hard cap) కలిగి ఉంటుంది. కాబట్టి, రెండు వర్కర్లు పనిచేయడానికి ఇతర పనులు ప్రారంభం కాకముందే సుమారు 5 GB మెమరీ అవసరమవుతుంది. మిగిలిన బడ్జెట్‌లో సరిపోయే రన్నర్లను మాత్రమే ఇంజిన్ అనుమతిస్తుంది. అందువల్ల, చిన్న సర్వర్లలో స్కాన్‌లు విఫలం కాకుండా క్యూలో ఉంటాయి; ఇది out-of-memory killer వల్ల సర్వర్ ఆగిపోవడం కంటే మెరుగైన పద్ధతి.

రెండు ప్రూన్ (prune) సెట్టింగ్‌లు డిఫాల్ట్‌గా true లో ఉంటాయి: ENGINE_AUTO_PRUNE_DOCKER_BUILD_CACHE మరియు ENGINE_AUTO_PRUNE_UNUSED_DOCKER_IMAGES. ఒక టాస్క్ పూర్తయిన తర్వాత, ఇంజిన్ ఉపయోగించని బిల్డ్ క్యాచీని, ఉపయోగించని ఇమేజ్‌లను మరియు ఆగిపోయిన స్కాన్ కంటైనర్‌లను తొలగిస్తుంది. రన్నింగ్‌లో ఉన్న కంటైనర్ ద్వారా రిఫర్ చేయబడిన ఇమేజ్‌లు, బైండ్ మౌంట్‌లు, డేటాబేస్ డేటా, క్రెడెన్షియల్స్ మరియు వాల్యూమ్‌లు భద్రపరచబడతాయి. హోస్ట్‌ను ఇతరులతో పంచుకోకూడదనడానికి ఇది కూడా ఒక కారణం: మీరు కాన్ఫిగర్ చేయని ప్రూనర్ మీ Docker డెమన్‌పై పనిచేస్తూ ఉంటుంది.

స్థానిక రిపోజిటరీని లీక్ చేయకుండా స్కాన్ చేయడం

LOCAL_REPOS_PATH డిఫాల్ట్‌గా ./local_repos కి సెట్ చేయబడుతుంది మరియు ఇది backend మరియు engine కంటైనర్‌లలో /local_repos వద్ద bind-mount చేయబడుతుంది. కాబట్టి, మీరు హోస్ట్ మెషీన్‌లోని ఆ ఫోల్డర్‌లో ఉంచిన రిపోజిటరీ వెంటనే కంటైనర్‌ల లోపల కనిపిస్తుంది. మీ వర్కింగ్ ట్రీని కాకుండా, కొత్తగా క్లోన్ చేసిన రిపోజిటరీని ఉపయోగించండి. జాబ్ కంటైనర్‌కు రైటబుల్ కాపీ లభిస్తుంది, అది తనలో తాను root గా ఉంటుంది మరియు ఇంటర్నెట్ యాక్సెస్‌ను కలిగి ఉంటుంది. అంటే ఆ కాపీలో ఉన్న ఏదైనా మార్చబడవచ్చు లేదా బాహ్యంగా పంపబడవచ్చు. ప్రాజెక్ట్‌ను కాపీ చేసే ముందు .env ఫైళ్లను మరియు ప్రైవేట్ కీలను తొలగించండి.

మీకు ఏమి లభిస్తుంది, ఏమి లభించదు

మీకు అభ్యర్థులైన లోపాల (candidate findings) ర్యాంకింగ్ జాబితా లభిస్తుంది. మీకు ధృవీకరించబడిన దుర్బలత్వాలు (verified vulnerabilities) లభించవు. ర్యాంకింగ్ మరియు డీ-డూప్లికేషన్ మీ ట్రయాజ్ క్యూ (triage queue) క్రమాన్ని నిర్ణయిస్తాయి. అవి ఒక ఎంట్రీ నిజమైనదని నిరూపించవు. పోస్ట్-స్క్రిప్ట్‌లు ధృవీకరణను ప్రయత్నించి, ప్రూఫ్ ఆఫ్ కాన్సెప్ట్‌ను రూపొందించగలవు; ఇది ఈ టూల్ అందించే అత్యంత బలమైన సంకేతం. అయితే, ఒక పోస్ట్-స్క్రిప్ట్ విఫలమైతే, ఆ ఫైండింగ్ తప్పు అని అర్థం కాదు. ప్రతి అభ్యర్థి లోపాన్ని ఒక వ్యక్తి ఇప్పటికీ చదవాల్సి ఉంటుంది.

open-kritt ఎన్ని నిజమైన బగ్‌లను గుర్తిస్తుందనే దానిపై ఈ గైడ్ ఎటువంటి క్లెయిమ్ చేయదు, ఎందుకంటే మేము దానిని కొలవలేదు. మీ కోడ్‌బేస్ కోసం డిటెక్షన్ రేటును ఎవరైనా చెబుతున్నారంటే, వారు మీ కోడ్‌బేస్‌పై దీనిని రన్ చేయలేదని అర్థం. ముందుగా మీకు బాగా తెలిసిన రిపోజిటరీని స్కాన్ చేయండి: మీరు స్వయంగా అంచనా వేయగలిగే ఫైండింగ్‌లే అందుబాటులో ఉన్న అత్యంత చౌకైన కాలిబ్రేషన్ పద్ధతులు.

చాలా వరకు self-hosted టూల్స్ కంటే ఇక్కడ ఆథరైజేషన్ (Authorization) చాలా ముఖ్యం. ఈ ఏజెంట్లు కోడ్‌ను కంపైల్ చేసి ఎగ్జిక్యూట్ చేస్తాయి మరియు నెట్‌వర్క్‌ను చేరుకోగలవు, కాబట్టి ప్రూఫ్-ఆఫ్-కాన్సెప్ట్ దశ లైవ్ సిస్టమ్‌లను తాకవచ్చు. మీరు సొంతంగా కలిగి ఉన్న లేదా పరీక్షించడానికి కాంట్రాక్ట్ పొందిన కోడ్‌పైనే దీనిని ఉపయోగించండి. ఏదైనా రన్ చేసే ముందు టార్గెట్ పరిధిని (target scope) రాసి పెట్టుకోండి. మీరు ANTHROPIC_API_KEYని కాన్ఫిగర్ చేసి Claude Code ఇంజిన్‌ను ఉపయోగిస్తుంటే, running Claude Code safely on a VPS లో పేర్కొన్న శాండ్‌బాక్సింగ్ పద్ధతులు ఈ ఏజెంట్లకు కూడా వర్తిస్తాయి.

FAQ

open-kritt కు ప్రత్యేకమైన VPS ఎందుకు అవసరం?

ఎందుకంటే దీని విశ్లేషణ ఏజెంట్లు (analysis agents) మీ కోడ్ యొక్క కాపీలను కలిగి ఉండి, నేరుగా ఇంటర్నెట్ యాక్సెస్‌తో, disposable job containers లో root యూజర్‌గా రన్ అవుతాయి. అంతేకాకుండా, ఇంజిన్ సర్వీస్ హోస్ట్ Docker socket ను మౌంట్ చేస్తుంది, తద్వారా ప్రతి జాబ్‌కు ఒక కంటైనర్‌ను ప్రారంభించగలదు. ఆ socket ను చేరుకోగలిగే ఏ ప్రాసెస్ అయినా హోస్ట్ ఫైల్‌సిస్టమ్‌ను మౌంట్ చేసే కంటైనర్‌ను ప్రారంభించగలదు, కాబట్టి ఈ మొత్తం స్టాక్‌ను హోస్ట్ స్థాయిలో root గానే పరిగణించాలి. ఒక ప్రత్యేక VPS లో ఇది ఆమోదయోగ్యమైన రాజీ, మరియు ఆ సర్వర్‌ను మళ్ళీ నిర్మించడం (rebuild) మీకు ఎటువంటి నష్టం కలిగించదు. మీ రోజువారీ వర్క్‌స్టేషన్‌లో అయితే, ఇది మీ SSH keys మరియు బ్రౌజర్ ప్రొఫైల్‌లను మీరు స్కాన్ చేస్తున్న కోడ్‌తో సమానమైన ట్రస్ట్ బౌండరీలో ఉంచుతుంది.

SSH tunnel కు బదులుగా నేను port 5173 ను నేరుగా ఎక్స్‌పోజ్ చేయవచ్చా?

మీరు అలా చేయకూడదు. ఈ బ్యాకెండ్ అప్లికేషన్ స్థాయిలో ఎటువంటి authentication లేకుండా వస్తుంది, కాబట్టి ఇంటర్నెట్‌కు మరియు మీ findings/provider credit కు మధ్య ఆ పోర్ట్ మాత్రమే రక్షణగా ఉంటుంది. అందుకే 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 ఏకకాలపు root మోడల్ కాల్‌లను అనుమతిస్తుందని, ఒక Codex సెషన్ ఐదు వరకు చైల్డ్ ఏజెంట్లను రన్ చేయగలదని గుర్తుంచుకోండి. ENGINE_WORKER_COUNT=0 కొత్త జాబ్‌లను తీసుకోవడాన్ని నిలిపివేస్తుంది, ఇది తక్షణమే ఆపడానికి వేగవంతమైన మార్గం.

నేను ఏ వెర్షన్‌ను చెక్ అవుట్ చేయాలి?

ఎల్లప్పుడూ ఒక tag ను మాత్రమే వాడాలి, ఎప్పటికీ main ను వాడకూడదు. git fetch --tags తర్వాత git tag --list రన్ చేస్తే అందుబాటులో ఉన్నవి కనిపిస్తాయి. ఈ వ్యాసం రాసే సమయానికి, 4 August 2026 న విడుదలైన v1.3.0 అత్యంత కొత్తది. వెర్షన్‌ను పిన్ చేయడం వల్ల, నెలల తర్వాత మళ్ళీ బిల్డ్ చేసినా అదే స్టాక్ వస్తుంది. దీనివల్ల అప్‌గ్రేడ్ అనేది మీరు రిలీజ్ నోట్స్ చదివిన తర్వాత తీసుకునే నిర్ణయం అవుతుంది తప్ప, ఏదో ఒక రోజు క్లోన్ చేసినప్పుడు జరిగే అనుకోని మార్పు కాదు.

స్కాన్ ప్రారంభం కావడం లేదు. నేను ఏమి తనిఖీ చేయాలి?

ముందుగా డిస్క్ ఖాళీ స్థలాన్ని తనిఖీ చేయండి, ఎందుకంటే ఖాళీ స్థలం ENGINE_MIN_FREE_STORAGE_GB (డిఫాల్ట్‌గా 20 GB) కంటే తక్కువగా ఉంటే ఇంజిన్ జాబ్ కంటైనర్‌ను ప్రారంభించదు. తర్వాత ENGINE_WORKER_COUNT విలువ 0 కాదని నిర్ధారించుకోండి, ఎందుకంటే ఆ విలువ ఉంటే కొత్త జాబ్‌లు తీసుకోవడం ఆగిపోతుంది. ఆ తర్వాత ./kritt setup రన్ చేసి మోడల్ క్రెడెన్షియల్ నిజంగా కాన్ఫిగర్ అయ్యిందో లేదో చూడండి, ఎందుకంటే కేవలం GITHUB_TOKEN తో స్కాన్‌లు రన్ కావు. docker compose logs engine ఆ జాబ్‌ను ఎందుకు స్కిప్ చేసిందో కారణాన్ని చూపుతుంది.