VPS-ல் open-kritt-ஐ self-host செய்வது எப்படி?

உங்கள் மடிக்கணினியில் அல்லாமல், VPS-ல் open-kritt-ஐ ஏன் self-host செய்ய வேண்டும்

நீங்கள் அழித்து மீண்டும் உருவாக்கக்கூடிய ஒரு server-ல் open-kritt-ஐ self-host செய்யுங்கள். இந்த கருவி தனது analysis agents-ஐ root பயனர் உரிமையுடன் தற்காலிக job containers-க்குள் இயக்குகிறது. இது உங்கள் code-ன் writable copy-ஐயும், நேரடி இணைய அணுகலையும் ஒவ்வொரு agent-க்கும் வழங்குகிறது. மேலும், host Docker socket-ஐ அதன் engine service-ல் mount செய்கிறது. இந்த வேலைக்காகவே பிரத்யேகமாக ஒதுக்கப்பட்ட ஒரு கணினியில் இது ஏற்றுக்கொள்ளக்கூடிய ஒரு சமரசம். ஆனால், உங்கள் SSH keys இருக்கும் கணினியில் இது மிகவும் ஆபத்தானது.

இயல்புநிலை அமைப்பின் நான்கு பண்புகள் இந்த ஆலோசனையை வலியுறுத்துகின்றன. இவை அனைத்தும் திட்டத்தின் சொந்த README மற்றும் compose file-லிருந்து பெறப்பட்டவை.

இந்த agents அதிக திறன் கொண்டவை. tool-enabled agents root உரிமையுடன் தற்காலிக job containers-க்குள் இயங்குவதாக README கூறுகிறது. அவற்றுக்கு writable repository copies மற்றும் நேரடி இணைய அணுகல் இருப்பதால், அவற்றால் கருவிகளை நிறுவவும், இலக்குகளை compile செய்யவும், சோதனைகளை இயக்கவும், proofs of concept-ஐ உருவாக்கவும் முடியும். ஒரு scan என்பது கோப்புகளை வாசிக்கும் linter மட்டுமல்ல. இது நீங்கள் கோரிய தன்னிச்சையான code execution ஆகும்.

Engine-ஆனது Docker socket-ஐக் கொண்டுள்ளது. docker-compose.yml host Docker socket-ஐ engine service-க்குள் mount செய்கிறது. ஏனெனில், ஒவ்வொரு job-க்கும் ஒரு scan container-ஐ engine உருவாக்கி இயக்குகிறது. அந்த socket-ஐ அணுகக்கூடிய எந்தவொரு process-ம், host filesystem-ஐ mount செய்யும் ஒரு container-ஐத் தொடங்க முடியும். எனவே, engine எந்த host-ல் இயங்குகிறதோ, அந்த host-ன் root உரிமையை அது effectively பெற்றுவிடுகிறது.

இதில் login திரை இல்லை. backend-ல் எந்தவொரு application authentication-ம் இல்லை. இந்த port-ஐ அணுகுவது என்பது, உங்கள் கண்டுபிடிப்புகளையும் உங்கள் provider credit-ஐயும் அணுகுவதற்குச் சமம்.

நீங்கள் scan செய்யும் code பெரும்பாலும் உங்களுடையது அல்ல. மூன்றாம் தரப்பு repository-ஐ agents-க்குக் காட்டுவது என்பது, அந்த repository-ன் build-ஐ உங்கள் கணினியில், root உரிமையுடன், இணைய அணுகலோடு இயக்குவதாகும்.

நீங்கள் coding agents ஏன் ஒரு disposable VM-ல் இருக்க வேண்டும் என்பதைப் படித்திருந்தால், இது அதே அச்சுறுத்தல் மாதிரி (threat model) என்பதை அறிவீர்கள், ஆனால் இது இன்னும் தீவிரமானது. open-kritt-க்கு வேறு எந்தப் பயன்பாடும் இல்லாத ஒரு தனி VPS-ஐ ஒதுக்குங்கள். மேலும், root-க்கு பதிலாக ஒரு தனிப்பட்ட குறைந்தபட்ச உரிமை கொண்ட பயனர் கணக்கிலிருந்து (least-privilege user account) அந்த VPS-ஐ இயக்குங்கள்.

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 ஆகும். இதற்கான analysis engine, Codex அல்லது Claude Code ஆகும். ஒரு candidate கண்டறியப்பட்ட பிறகு, விருப்பத்தேர்வாக உள்ள post-scripts மூலம் அதைச் சரிபார்க்கவோ அல்லது proof of concept-ஐ உருவாக்கவோ முடியும்.

இறுதியில் உங்களுக்குக் கிடைப்பது, தரவரிசைப்படுத்தப்பட்ட candidates-ன் பட்டியல் ஆகும். இதை ஒரு முழுமையான அறிக்கை (report) என்று கருதாமல், ஒரு triage queue என்று கருதி கையாளவும்.

தொடங்குவதற்கு முன் உங்களுக்குத் தேவையானவை

• Ubuntu 24.04, Debian 12 அல்லது Rocky Linux 9 இயங்கும் ஒரு VPS. x86_64 மற்றும் ARM64 கட்டமைப்புகளில் இவை சோதிக்கப்பட்ட விநியோகங்கள் என நிறுவல் ஆவணங்கள் குறிப்பிடுகின்றன.
• 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-ஐ ஸ்கேன் செய்யத் திட்டமிட்டால் மட்டுமே GITHUB_TOKEN தேவை. வழங்கப்பட்ட .env.example இதைத் தெளிவாகக் குறிப்பிடுகிறது: ஒரு GitHub token-ஐ மட்டும் வைத்துக்கொண்டு ஸ்கேன்களை இயக்க முடியாது.

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-க்கு சமமான அதிகாரத்தை வழங்கும். எனவே, open-kritt-ஐ இயக்கும் account-ஐ மட்டும் இதில் சேர்க்கவும். இந்த அமைப்பைப் பற்றிய விரிவான தகவலுக்கு, running Docker on a VPS என்பதைப் பார்க்கவும்.

Ubuntu 24.04 அதன் சொந்த repository-ல் Node 18-ஐ வழங்குகிறது. ஆனால், CLI 20-க்குக் குறைவான எந்தவொரு version-லும் இயங்காது. எனவே, NodeSource-ஐப் பயன்படுத்தவும்.

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

node -v கட்டளை v20. அல்லது அதற்கு மேற்பட்ட version-ஐக் காட்ட வேண்டும். 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 உங்களுக்குக் கீழே நகர்கிறது. ஆனால் tag நகர்வதில்லை. ஆகஸ்ட் 2026 நிலவரப்படி, புதிய tag v1.3.0 ஆகும், இது 4 ஆகஸ்ட் 2026 அன்று வெளியிடப்பட்டது. நீங்கள் clone செய்யும் நாளில் என்ன உள்ளது என்பதை git tag --list காட்டுகிறது. ஒரு tag-ஐ checkout செய்யும்போது repository detached HEAD நிலையில் இருக்கும்; இது சரியானதே. நீங்கள் இந்த clone-ஐ ஒரு branch-ஆகக் கருதாமல், pinned deployment-ஆகக் கருதுகிறீர்கள். பிற்காலத்தில் upgrade செய்ய, release notes-ஐப் படித்துவிட்டு, git fetch --tags-ஐ இயக்கி, புதிய tag-ஐ checkout செய்து, மீண்டும் ./kritt start-ஐ இயக்கவும். ஏனெனில் start images-ஐ மீண்டும் கட்டமைக்கும் (rebuild).

./kritt-ஐ sudo உடன் இயக்க வேண்டாம். ஆவணங்கள் இதைப் பற்றித் தெளிவாகக் குறிப்பிடுகின்றன. CLI ஆனது .data/-க்குக் கீழே உள்ள project-local credential directories-ஐ நிர்வகிக்கிறது. எனவே, root பயனராக இயக்கினால், அந்த directories-ன் உரிமை root-க்குச் சென்றுவிடும்; அதன் பிறகு சாதாரண பயனர் அதை எழுத முடியாது.

./kritt setup மூலம் model access-ஐ உள்ளமைத்தல்

./kritt setup

இந்தக் கட்டளை .env.example கோப்பு இல்லாதபோது அதிலிருந்து .env-ஐ உருவாக்குகிறது, ஒவ்வொரு credential-ன் நிலையையும் அச்சிடுகிறது, மேலும் அவற்றை அமைக்க அல்லது நீக்க அனுமதிக்கிறது. இது எந்தவொரு மதிப்பையும் terminal-ல் மீண்டும் அச்சிடுவதில்லை. .env மற்றும் engine credential கோப்பு ஆகிய இரண்டுமே 0600 mode-ல் எழுதப்படுகின்றன.

நீங்கள் இதை நீங்களே செய்ய விரும்பினால்:

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

பின்னர் .env கோப்பில் provider key-ஐ உள்ளிடவும், அந்தக் கோப்பை 0600 அனுமதியிலேயே வைத்திருக்கவும். எப்படிச் செய்தாலும், இப்போது அந்த server-ல் ஒரு செயல்படும் provider credential உள்ளது; அந்த server-ல் வேறு எதையும் வைத்திருக்கக்கூடாது என்பதற்கு இதுவும் ஒரு காரணம். இந்தத் திட்டத்திற்காக மட்டும் ஒரு தனி key-ஐ உருவாக்கவும், அப்போதுதான் அதைத் திரும்பப் பெறும்போது நீங்கள் முக்கியமாகக் கருதும் பிற சேவைகள் பாதிக்கப்படாது. AI agents-க்கு எட்டாதவாறு ரகசியங்களைப் பாதுகாத்தல் என்ற பகுதி இது குறித்த விரிவான பழக்கவழக்கங்களை விளக்குகிறது.

முதல் ஸ்கேனுக்கு முன்பே provider spending cap-ஐ அமைக்கவும்

open-kritt என்பது fan-out முறையில் செயல்படக்கூடியது, இந்த fan-out செயல்பாட்டிற்கே நீங்கள் கட்டணம் செலுத்துகிறீர்கள். v1.3.0-ல் .env.example-ன் இயல்புநிலை அமைப்புகள் கவனமாக நிர்ணயிக்கப்பட்டுள்ளன: ENGINE_WORKER_COUNT=2 என்பது சிறிய 2-vCPU இயந்திரங்களுக்கான இயல்புநிலை அமைப்பாகக் கோப்பில் விவரிக்கப்பட்டுள்ளது, மேலும் ENGINE_MAX_CONCURRENT_SCANS=1-ம் உள்ளது. இவற்றுக்கு மேலாக, ஒரு provider கணக்கில் அனுமதிக்கப்படும் அதிகபட்ச concurrent root model calls-ஐக் குறிக்கும் ENGINE_WORKERS_PER_ACCOUNT=15 மற்றும் ஒரு Codex session ஐந்து child agents வரை இயங்கக்கூடும் என்பதால் ENGINE_CODEX_MAX_SUBAGENTS_PER_SESSION=5 ஆகியவையும் உள்ளன. பெரிய VPS-ல் worker எண்ணிக்கையை உயர்த்தினால், ஒரே நேரத்தில் இயங்கும் model calls-ன் எண்ணிக்கையும் அதிகரிக்கும்.

இந்த repository-ல் நீங்கள் எவ்வளவு செலவு செய்கிறீர்கள் என்பதைக் கட்டுப்படுத்தும் வசதி எதுவும் இல்லை. .env.example-ல் budget அமைப்புகள் இல்லை. இந்த engine-ன் சொந்த நிறுத்த நிபந்தனைகள் (stop conditions) அந்த worker வரம்புகள் மற்றும் ஒரு harness run-க்கு 7200 வினாடிகள் என இயல்புநிலையாகக் கொண்ட ENGINE_HARNESS_TIMEOUT_SECONDS ஆகியவற்றை மட்டுமே சார்ந்துள்ளன. எனவே, செலவு வரம்பை provider தளத்திலேயே அமைக்க வேண்டும். உங்கள் provider console-ஐத் திறந்து, முதல் ஸ்கேனைத் தொடங்குவதற்கு முன்பே, அதற்குப் பிறகு அல்ல, ஒரு hard monthly limit-ஐ அமைக்கவும். VPS-ல் AI agent-ன் செலவைக் கட்டுப்படுத்துதல் என்ற பகுதி ஒவ்வொரு provider-க்கும் உரிய அமைப்புகளை விளக்குகிறது.

உள்ளூர் அளவிலும் ஒரு தடுப்பு வசதி உள்ளது. ENGINE_WORKER_COUNT=0-ஐ அமைப்பதன் மூலம் புதிய பணிகளை எடுப்பது தற்காலிகமாக நிறுத்தப்படும், மேலும் stack இயங்கத் தொடங்கிய பிறகு Settings திரையில் அதே worker மதிப்புகளை மாற்றிக்கொள்ளலாம்.

இந்த வழிகாட்டியில் ஒரு ஸ்கேனுக்கான விலை குறிப்பிடப்படவில்லை, ஏனெனில் செலவு என்பது repository-ன் அளவு, நீங்கள் உருவாக்கும் workflow மற்றும் அதற்குப் பின்னால் உள்ள model ஆகியவற்றைப் பொறுத்தது. ஒரு சிறிய repository-ல் ஒரு ஸ்கேனை இயக்கிப் பாருங்கள், அதன் பிறகு பெரிய எதிலாவது பயன்படுத்துவதற்கு முன்பு உங்கள் provider-ன் usage பக்கத்தைப் பார்த்து உறுதிப்படுத்திக்கொள்ளுங்கள்.

Stack-ஐத் தொடங்கி அதன் ஆரோக்கியத்தைச் சரிபார்த்தல்

./kritt start

இது .env மற்றும் குறைந்தபட்சம் ஒரு credential-ஐச் சரிபார்த்து, பின் docker compose up --build-ஐ இயக்குகிறது. முதல் build மெதுவாக இருக்கும், ஏனெனில் இது frontend, backend, engine, executor view மற்றும் database images ஆகியவற்றை உருவாக்குகிறது. இது foreground-ல் இயங்குவதால், SSH session-ஐ மூடினால் stack நின்றுவிடும். இதை tmux-க்குள் தொடங்கவும், அல்லது முதல் build வெற்றிகரமாக முடிந்ததும் detached முறையில் இயக்கவும். இவை எதுவுமே reboot-க்கு பின் தானாக இயங்காது, எனவே server restart ஆன பிறகும் stack இயங்க வேண்டுமெனில், 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 server-லேயே பதிலளிக்கிறதா என்று சரிபார்க்கவும்.

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 என்றால் அது இயங்கவில்லை என்று பொருள், docker compose logs backend அதற்கான காரணத்தைக் கூறும். repository directory-ல் இருந்து docker compose down மூலம் அனைத்தையும் நிறுத்தவும்.

கூடுதல் விருப்பம்: docker compose exec backend npm run seed demo தரவுகளை ஏற்றும், இது உண்மையான scan-க்கு செலவு செய்வதற்கு முன் interface-ஐப் பார்க்க எளிதான வழியாகும்.

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 திரை இல்லை, எனவே அந்தப் பக்கத்தை அணுகும் எவரும் scans-ஐத் தொடங்கி உங்கள் provider credit-ஐத் தீர்த்துவிட முடியும். இதில் மற்றொரு ஆபத்தும் உள்ளது: ஒரு container port-ஐ publish செய்தால், அது ufw-ன் இயல்புநிலை policy-க்கு முன்பே கையாளப்படும். எனவே, ஒரு ufw deny 5173 விதி சரியாகத் தெரிந்தாலும், அது எதையும் தடுக்காது. ufw-ஐத் தவிர்க்கும் Docker ports அந்த விதிச் சங்கிலியை விளக்குகிறது.

VPS-ன் அளவை நிர்ணயித்தல்

ENGINE_MIN_FREE_STORAGE_GB இயல்பாக 20 என அமைக்கப்பட்டுள்ளது. இலவச சேமிப்பு இடம் (free storage) இந்த அளவை விடக் குறையும் போது, புதிய per-job scan container-ஐத் தொடங்க engine மறுத்துவிடும். உருவாக்கப்பட்ட images, checkout cache, Postgres தரவுகள் மற்றும் job workspaces அனைத்தும் ஒரே வட்டில் (disk) இருப்பதால், 20 GB கொண்ட VPS-ல் எந்தவொரு scan-ம் தொடங்காது. குறைந்தபட்சம் 40 GB-ஐ அடிப்படை அளவாகக் கருதுங்கள்; பெரிய repositories-ஐ ஸ்கேன் செய்வதாக இருந்தால் கூடுதல் சேமிப்பு இடத்தை வழங்கவும்.

நினைவகத்தின் (memory) அளவு எளிய கணக்கீட்டைப் பின்பற்றும். ENGINE_MEMORY_RESERVE_GB=2 என்பது engine, database, API மற்றும் இதர குறுகிய கால செயல்பாடுகளுக்காக ஒதுக்கப்பட்ட நினைவகமாகும். ஒவ்வொரு scan runner-க்கும் ஒரு குறிப்பிட்ட ஒதுக்கீடும், ENGINE_SCAN_RUNNER_MEMORY_MB=1536 என்ற கடினமான உச்ச வரம்பும் (hard cap) உண்டு. எனவே, இரண்டு workers இயங்குவதற்கு முன்பே சுமார் 5 GB நினைவகம் தேவைப்படும். மீதமுள்ள நினைவகத்தில் எந்தெந்த runners-க்கு இடமுண்டோ அவற்றை மட்டுமே engine அனுமதிக்கும். இதனால், நினைவகம் போதாமல் process-கள் முடக்கப்படுவதற்கு (out-of-memory killer) பதிலாக, சிறிய கணினிகளில் scans வரிசையில் காத்திருக்கும்; இதுவே சிறந்த அணுகுமுறையாகும்.

இரண்டு prune அமைப்புகள் இயல்பாகவே true என இருக்கும்: ENGINE_AUTO_PRUNE_DOCKER_BUILD_CACHE மற்றும் ENGINE_AUTO_PRUNE_UNUSED_DOCKER_IMAGES. ஒரு பணி முடிந்ததும், பயன்படுத்தப்படாத build cache, images மற்றும் நிறுத்தப்பட்ட scan containers ஆகியவற்றை engine நீக்கிவிடும். இயங்கும் container-ஆல் பயன்படுத்தப்படும் images, bind mounts, database தரவுகள், credentials மற்றும் volumes ஆகியவை பாதுகாக்கப்படும். நீங்கள் கட்டமைக்காத ஒரு pruner உங்கள் Docker daemon-ல் இயங்குவதால், இந்த host-ஐ மற்றவர்களுடன் பகிராமல் இருப்பது நல்லது.

உள்ளூர் களஞ்சியத்தை (repository) கசியவிடாமல் ஸ்கேன் செய்தல்

LOCAL_REPOS_PATH இயல்பாக ./local_repos என அமையும், இது backend மற்றும் engine containers-ல் /local_repos என்ற பாதையில் bind-mount செய்யப்படுகிறது. எனவே, host-ல் உள்ள அந்த கோப்புறையில் நீங்கள் போடும் களஞ்சியம் உடனடியாக containers-க்குள் தெரியும். உங்கள் working tree-ஐப் பயன்படுத்தாமல், புதிய clone-ஐப் பயன்படுத்தவும். Job container-க்கு ஒரு writable நகல் கிடைக்கிறது; அதற்குள் அது root ஆகச் செயல்படும் மற்றும் இணைய அணுகலும் இருக்கும். எனவே, அந்த நகலில் இருக்கும் எதையும் மாற்றவோ அல்லது server-க்கு வெளியே அனுப்பவோ முடியும். ஒரு திட்டத்தை நகலெடுக்கும் முன் .env கோப்புகளையும் private keys-களையும் நீக்கிவிடவும்.

உங்களுக்குக் கிடைப்பவை மற்றும் கிடைக்காதவை

தரவரிசைப்படுத்தப்பட்ட candidate findings உங்களுக்குக் கிடைக்கும். சரிபார்க்கப்பட்ட vulnerabilities உங்களுக்குக் கிடைக்காது. உங்கள் triage வரிசையைத் தீர்மானிக்க தரவரிசைப்படுத்துதலும் (ranking) நகல் நீக்கமும் (de-duplication) உதவுகின்றன. இவை ஒரு பதிவு உண்மையானது என்பதை உறுதிப்படுத்தாது. Post-scripts மூலம் சரிபார்ப்பைச் செய்து ஒரு proof of concept-ஐ உருவாக்க முடியும்; இதுவே இந்த கருவி வழங்கும் மிக வலுவான சமிக்ஞையாகும். ஆனால், ஒரு post-script தோல்வியடைவது அந்த finding தவறானது என்பதற்கான ஆதாரம் அல்ல. ஒவ்வொரு candidate-ஐயும் ஒரு நபர் இன்னும் வாசிக்க வேண்டியுள்ளது.

open-kritt எத்தனை உண்மையான பிழைகளைக் கண்டறியும் என்பது குறித்து இந்த வழிகாட்டி எந்தக் கூற்றையும் முன்வைக்கவில்லை, ஏனெனில் நாங்கள் அதை அளவிடவில்லை. உங்கள் codebase-க்கு ஒரு detection rate-ஐக் குறிப்பிடும் எவரும் அதை உங்கள் codebase-ல் இயக்கிப் பார்த்திருக்க மாட்டார்கள். உங்களுக்கு ஏற்கனவே நன்கு தெரிந்த ஒரு repository-ஐ முதலில் scan செய்யுங்கள்: உங்களால் நீங்களே மதிப்பிடக்கூடிய findings-தான் மிகச் சிறந்த calibration முறையாகும்.

பெரும்பாலான self-hosted கருவிகளை விட இதில் Authorization மிக முக்கியமானது. இந்த agents குறியீட்டைத் தொகுத்து (compile) இயக்குவதோடு, network-ஐயும் அணுகுகின்றன. எனவே, ஒரு proof-of-concept படிநிலை நேரடி (live) அமைப்புகளைத் தொடக்கூடும். உங்களுக்குச் சொந்தமான அல்லது நீங்கள் சோதனை செய்ய ஒப்பந்தம் செய்யப்பட்ட குறியீட்டில் மட்டும் இதைச் செயல்படுத்துங்கள். எதையும் இயக்கும் முன் target scope-ஐக் குறித்துக்கொள்ளுங்கள். நீங்கள் ANTHROPIC_API_KEY-ஐ உள்ளமைத்து Claude Code engine-ஐப் பயன்படுத்தினால், running Claude Code safely on a VPS-ல் உள்ள sandboxing நடைமுறைகள் இந்த agents-க்கும் பொருந்தும்.

FAQ

open-kritt-க்கு ஏன் தனி VPS தேவை?

இதன் analysis agents, உங்கள் code-ன் நகல்களைக் கொண்டு, root அனுமதியுடன் disposable job containers-ல் இயங்குகின்றன. மேலும், engine service ஆனது host Docker socket-ஐ mount செய்வதால், ஒவ்வொரு job-க்கும் ஒரு container-ஐ உருவாக்க முடியும். அந்த socket-ஐ அணுகும் எந்தவொரு process-ம், host filesystem-ஐ mount செய்யும் container-ஐ உருவாக்க முடியும் என்பதால், முழு stack-ம் host-ன் root அனுமதியைக் கொண்டதாகவே கருதப்பட வேண்டும். ஒரு பிரத்யேக VPS-ல் இது ஏற்றுக்கொள்ளக்கூடிய ஒரு சமரசம், மேலும் அந்த server-ஐ மீண்டும் உருவாக்குவதில் பெரிய இழப்பு ஏதுமில்லை. உங்கள் அன்றாட workstation-ல் இதை இயக்கினால், உங்கள் SSH keys மற்றும் browser profiles ஆகியவை நீங்கள் scan செய்யும் code-ன் அதே பாதுகாப்பு எல்லைக்குள் வந்துவிடும்.

SSH tunnel-க்கு பதிலாக port 5173-ஐ நான் நேரடியாகத் திறக்கலாமா?

அவ்வாறு செய்யக்கூடாது. இந்த backend-ல் application authentication வசதி இல்லை. எனவே, இணையத்திற்கும் உங்கள் 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-ஐப் பயன்படுத்துவது இதற்கு மாற்றாகாது, ஏனெனில் Docker port-கள் ufw-ன் default policy-க்கு முன்பே கையாளப்படுகின்றன.

திட்டமிட்டதை விட அதிக செலவாகாமல் open-kritt-ஐ தடுப்பது எப்படி?

முதல் scan-க்கு முன்பே உங்கள் model provider-ன் console-ல் ஒரு hard limit-ஐ அமைக்கவும், ஏனெனில் open-kritt-ல் சொந்தமாக budget setting கிடையாது. முதல் சில முறை இயக்கும்போது, ஏற்கனவே உள்ள 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 புதிய job-களை எடுப்பதை நிறுத்திவிடும், இதுவே மிக வேகமான உள்ளூர் தடுப்பு முறையாகும்.

நான் எந்த version-ஐப் பயன்படுத்த வேண்டும்?

எப்போதும் ஒரு tag-ஐப் பயன்படுத்தவும், ஒருபோதும் main-ஐப் பயன்படுத்த வேண்டாம். git fetch --tags-ஐத் தொடர்ந்து git tag --list-ஐ இயக்கினால் என்னென்ன பதிப்புகள் உள்ளன என்பது தெரியும். இந்த ஆவணத்தை எழுதும் நேரத்தில், 4 August 2026 அன்று வெளியிடப்பட்ட v1.3.0 என்பதே புதிய பதிப்பாகும். ஒரு குறிப்பிட்ட பதிப்பைப் பயன்படுத்துவதன் மூலம், மாதங்கள் கழித்து மீண்டும் build செய்தாலும் அதே stack கிடைக்கும். மேலும், release notes-ஐப் படித்த பிறகு upgrade செய்வது உங்கள் முடிவாக இருக்குமே தவிர, வெவ்வேறு நாட்களில் clone செய்வதால் ஏற்படும் தற்செயலான மாற்றமாக இருக்காது.

scan தொடங்கவில்லை என்றால், எதைச் சரிபார்க்க வேண்டும்?

முதலில் disk space-ஐச் சரிபார்க்கவும், ஏனெனில் free storage ENGINE_MIN_FREE_STORAGE_GB-க்குக் குறைவாக இருந்தால் (இயல்பாக 20 GB), engine எந்தவொரு job container-ஐயும் தொடங்காது. பிறகு ENGINE_WORKER_COUNT-ன் மதிப்பு 0 இல்லை என்பதை உறுதிப்படுத்தவும், ஏனெனில் அந்த மதிப்பு புதிய job-களை எடுப்பதைத் தடுத்துவிடும். இறுதியாக, ./kritt setup-ஐ இயக்கி model credential சரியாக உள்ளமைக்கப்பட்டுள்ளதா என்று பார்க்கவும், ஏனெனில் GITHUB_TOKEN மட்டும் இருந்தால் scan-களை இயக்க முடியாது. docker compose logs engine அந்த job ஏன் தவிர்க்கப்பட்டது என்பதற்கான காரணத்தைக் காட்டும்.