VPS-এ open-kritt সেলফ-হোস্ট করার নিয়ম

কেন আপনার ল্যাপটপের পরিবর্তে একটি VPS-এ open-kritt সেলফ-হোস্ট করবেন

এমন একটি সার্ভারে open-kritt সেলফ-হোস্ট করুন যা আপনি প্রয়োজনে ধ্বংস এবং পুনরায় তৈরি করতে পারেন। এই টুলটি তার অ্যানালাইসিস এজেন্টগুলোকে root হিসেবে ডিসপোজেবল জব কন্টেইনারের ভেতরে চালায়, প্রতিটি এজেন্টকে আপনার কোডের একটি রাইটেবল কপি এবং সরাসরি ইন্টারনেট অ্যাক্সেস দেয়, এবং হোস্টের Docker socket-কে তার ইঞ্জিন সার্ভিসে মাউন্ট করে। এই কাজের জন্য নিবেদিত একটি মেশিনে এটি একটি যৌক্তিক আপস। কিন্তু যে মেশিনে আপনার SSH keys সংরক্ষিত থাকে, সেখানে এটি একটি ঝুঁকিপূর্ণ সিদ্ধান্ত।

ডিফল্ট সেটআপের চারটি বৈশিষ্ট্য এই পরামর্শের কারণ, এবং এই চারটিই প্রকল্পের নিজস্ব README এবং compose ফাইল থেকে নেওয়া হয়েছে।

এজেন্টগুলো অত্যন্ত শক্তিশালী হওয়ার জন্য তৈরি। README অনুযায়ী, টুল-এনাবলড এজেন্টগুলো root হিসেবে ডিসপোজেবল জব কন্টেইনারের ভেতরে চলে, যেখানে রাইটেবল রিপোজিটরি কপি এবং সরাসরি ইন্টারনেট অ্যাক্সেস থাকে, যাতে তারা টুল ইনস্টল করতে, টার্গেট কম্পাইল করতে, টেস্ট চালাতে এবং প্রুফ অফ কনসেপ্ট তৈরি করতে পারে। একটি স্ক্যান কেবল ফাইল পড়া কোনো লিন্টার নয়। এটি আপনার অনুরোধ করা একটি নির্বিচারে কোড এক্সিকিউশন (arbitrary code execution)। সেই ইন্টারনেট অ্যাক্সেস উভয় দিকেই কাজ করে: একটি এজেন্ট টার্গেট নিয়ে গবেষণার সময় যা কিছু সংগ্রহ করে তা প্রম্পটের ভেতরে আসা আনট্রাস্টেড টেক্সট, যা আপনি যখন একটি এজেন্টকে তার নিজস্ব ওয়েব সার্চ করতে দেন, তখন একই ধরনের ঝুঁকির সম্মুখীন হন।

ইঞ্জিনটি Docker socket ধরে রাখে। docker-compose.yml হোস্টের Docker socket-কে ইঞ্জিন সার্ভিসে মাউন্ট করে, কারণ ইঞ্জিন প্রতিটি জবের জন্য একটি করে স্ক্যান কন্টেইনার তৈরি ও চালু করে। যে কোনো প্রসেস যা সেই সকেটে পৌঁছাতে পারে, তা এমন একটি কন্টেইনার শুরু করতে পারে যা হোস্ট ফাইলসিস্টেমকে মাউন্ট করে। তাই ইঞ্জিনটি কার্যকরভাবে সেই হোস্টের root হিসেবে কাজ করে যেখানে এটি চলে।

এখানে কোনো লগইন স্ক্রিন নেই। ব্যাকএন্ডটি কোনো অ্যাপ্লিকেশন অথেন্টিকেশন ছাড়াই আসে। পোর্টটিতে অ্যাক্সেস থাকা মানে আপনার ফলাফল এবং আপনার প্রোভাইডার ক্রেডিটে অ্যাক্সেস থাকা।

আপনি যে কোড স্ক্যান করেন তা প্রায়শই আপনার নয়। এজেন্টগুলোকে কোনো থার্ড-পার্টি রিপোজিটরির দিকে নির্দেশ করার অর্থ হলো সেই রিপোজিটরির বিল্ড আপনার মেশিনে, root হিসেবে এবং নেটওয়ার্ক অ্যাক্সেসসহ চালানো।

আপনি যদি কেন কোডিং এজেন্টগুলো একটি ডিসপোজেবল VM-এ থাকা উচিত পড়ে থাকেন, তবে এটি একই থ্রেট মডেল, কেবল আরও শক্তিশালী। open-kritt-কে এমন একটি VPS দিন যেখানে অন্য কিছু নেই, এবং সেই VPS-কে root-এর পরিবর্তে একটি আলাদা লিস্ট-প্রিভিলেজ ইউজার অ্যাকাউন্ট থেকে পরিচালনা করুন।

open-kritt আসলে যা করে

open-kritt (repository-টি হলো Kritt-ai/open-kritt, যা AGPL-3.0 লাইসেন্সের অধীনে) ভালনারেবিলিটি রিসার্চকে ছোট ছোট কাজে ভাগ করে, সেই কাজগুলো AI এজেন্টদের মাধ্যমে সমান্তরালভাবে (parallel) চালায় এবং সবশেষে প্রাপ্ত ফলাফল থেকে ডুপ্লিকেট সরিয়ে সেগুলোকে র‍্যাঙ্ক করে। আপনি একটি ওয়ার্কফ্লোকে নির্দিষ্ট প্রম্পটের চেইন হিসেবে সংজ্ঞায়িত করেন এবং প্রতিটি ধাপ তার আগের ধাপগুলো থেকে স্ট্রাকচার্ড কনটেক্সট গ্রহণ করে। স্ক্যান টার্গেট হিসেবে একটি রিমোট বা লোকাল git repository ব্যবহার করা হয়। এর অ্যানালাইসিস ইঞ্জিন হিসেবে Codex বা Claude Code কাজ করে। কোনো সম্ভাব্য ভালনারেবিলিটি পাওয়া গেলে, ঐচ্ছিক পোস্ট-স্ক্রিপ্টগুলো সেটিকে যাচাই করার বা একটি প্রুফ অফ কনসেপ্ট (PoC) তৈরি করার চেষ্টা করতে পারে।

সবশেষে আপনি সম্ভাব্য ভালনারেবিলিটির একটি র‍্যাঙ্ক করা তালিকা পাবেন। এটিকে একটি চূড়ান্ত রিপোর্ট হিসেবে না দেখে বরং একটি ট্রায়াজ কিউ (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

নতুন group membership কার্যকর করতে লগ আউট করে পুনরায় লগ ইন করুন, তারপর নিশ্চিত করুন যে 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-এর সদস্য হওয়া মানে হোস্ট মেশিনে root-এর সমান ক্ষমতা পাওয়া, তাই শুধুমাত্র যে account দিয়ে open-kritt চালানো হবে সেটিকে এই group-এ যুক্ত করুন। এই সেটআপের বিস্তারিত জানতে running Docker on a VPS দেখুন।

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।

open-kritt ক্লোন করুন এবং একটি নির্দিষ্ট ট্যাগ করা রিলিজ পিন করুন

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 ক্লোন করার দিন বিদ্যমান ফাইলগুলো প্রদর্শন করে। একটি ট্যাগ চেকআউট করলে রিপোজিটরি detached HEAD অবস্থায় চলে যায়, যা এখানে সঠিক: আপনি এই ক্লোনটিকে একটি পিন করা ডিপ্লয়মেন্ট হিসেবে ব্যবহার করছেন, কোনো ব্রাঞ্চ হিসেবে নয় যেখানে আপনি কমিট করবেন। পরবর্তীতে আপগ্রেড করতে রিলিজ নোটগুলো পড়ুন, তারপর git fetch --tags চালান, নতুন ট্যাগটি চেকআউট করুন এবং পুনরায় ./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 ফাইলে প্রোভাইডার কি (key) এডিট করে বসান এবং ফাইলটির পারমিশন 0600 রাখুন। যেভাবেই করুন না কেন, একটি কার্যকর প্রোভাইডার ক্রেডেনশিয়াল এখন সার্ভারে রয়েছে, যা এই সার্ভারে অন্য কোনো গুরুত্বপূর্ণ তথ্য না রাখার আরেকটি কারণ। শুধুমাত্র এই প্রজেক্টের জন্য একটি আলাদা কি তৈরি করুন, যাতে পরবর্তীতে এটি বাতিল করলে আপনার অন্য কোনো কাজের ক্ষতি না হয়। AI এজেন্টদের নাগালের বাইরে গোপন তথ্য রাখা বিষয়টি এই অভ্যাসের বিস্তারিত আলোচনা করে।

প্রথম স্ক্যান করার আগে প্রোভাইডার স্পেন্ডিং ক্যাপ সেট করুন

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-এ ওয়ার্কারের সংখ্যা বাড়ালে একই সাথে চলমান মডেল কলের সংখ্যাও বেড়ে যায়।

এই রিপোজিটরিতে আপনার খরচ সীমাবদ্ধ করার কোনো ব্যবস্থা নেই। .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 ইমেজগুলো তৈরি করে। এটি 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-এর মাধ্যমে 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

এই কমান্ডটি চলার সময় আপনার লোকাল ব্রাউজারে 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 রুল দেখতে সঠিক মনে হলেও তা আসলে কিছুই ব্লক করে না। Docker ports that bypass ufw-তে সেই রুল চেইনটি দেখানো হয়েছে যা এই সমস্যার কারণ।

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-এর একটি হার্ড ক্যাপ থাকে। তাই দুটি ওয়ার্কারের জন্য অন্য কিছু চলার আগেই প্রায় 5 GB মেমরির প্রয়োজন হয়। ইঞ্জিন শুধুমাত্র সেই রানারগুলোকেই অনুমতি দেয় যা অবশিষ্ট বাজেটের মধ্যে থাকে, তাই ছোট সার্ভারে স্ক্যানগুলো ব্যর্থ না হয়ে কিউতে (queue) জমা হয়, যা আউট-অফ-মেমরি কিলার (OOM 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 করা থাকে। তাই আপনি হোস্টের ওই ফোল্ডারে কোনো রিপোজিটরি রাখলে তা সাথে সাথেই কন্টেইনারের ভেতর দেখা যাবে। আপনার working tree ব্যবহার না করে নতুন একটি clone ব্যবহার করুন। জব কন্টেইনারটি একটি writable কপি পায়, যার ভেতরে root অ্যাক্সেস থাকে এবং ইন্টারনেট সংযোগ থাকে। এর মানে হলো, ওই কপির ভেতর যা কিছু থাকবে তা পরিবর্তন করা বা সার্ভারের বাইরে পাঠানো সম্ভব। কোনো প্রজেক্ট কপি করার আগে .env ফাইল এবং private key সরিয়ে ফেলুন।

আপনি যা পাবেন এবং যা পাবেন না

আপনি র‍্যাঙ্ক করা সম্ভাব্য ফলাফলগুলো পাবেন। আপনি যাচাইকৃত ভালনারেবিলিটি পাবেন না। র‍্যাঙ্কিং এবং ডি-ডুপ্লিকেশন আপনার ট্রায়াজ কিউ-এর ক্রম নির্ধারণ করে। এগুলো কোনো এন্ট্রি সঠিক কি না তা প্রমাণ করে না। পোস্ট-স্ক্রিপ্টগুলো ভ্যালিডেশন বা প্রুফ-অফ-কনসেপ্ট তৈরির চেষ্টা করতে পারে এবং এটিই টুলের দেওয়া সবচেয়ে শক্তিশালী সংকেত, তবে কোনো পোস্ট-স্ক্রিপ্ট ব্যর্থ হওয়া মানেই এই নয় যে ফলাফলটি ভুল। প্রতিটি সম্ভাব্য ফলাফল একজন মানুষই যাচাই করবেন।

এই নির্দেশিকাটি open-kritt কতগুলো প্রকৃত বাগ খুঁজে বের করে সে বিষয়ে কোনো দাবি করে না, কারণ আমরা তা পরিমাপ করিনি। কেউ যদি আপনার কোডবেসের জন্য কোনো ডিটেকশন রেট উল্লেখ করে, তবে সে আপনার কোডবেসে এটি চালিয়ে দেখেনি। প্রথমে এমন একটি রিপোজিটরি স্ক্যান করুন যা আপনি ভালো জানেন: যে ফলাফলগুলো আপনি নিজেই বিচার করতে পারেন, সেগুলোই ক্যালিব্রেশনের জন্য সবচেয়ে সাশ্রয়ী উপায়।

অধিকাংশ self-hosted টুলের তুলনায় এখানে অথরাইজেশন বা অনুমোদন অনেক বেশি গুরুত্বপূর্ণ। এজেন্টগুলো কোড কম্পাইল ও এক্সিকিউট করে এবং নেটওয়ার্কে পৌঁছাতে পারে, তাই প্রুফ-অফ-কনসেপ্ট ধাপটি লাইভ সিস্টেমে প্রভাব ফেলতে পারে। এটিকে এমন কোডে নির্দেশ করুন যা আপনার মালিকানাধীন বা যা পরীক্ষা করার জন্য আপনি চুক্তিবদ্ধ, এবং যেকোনো কিছু চালানোর আগে টার্গেট স্কোপ লিখে রাখুন। আপনি যদি ANTHROPIC_API_KEY কনফিগার করেন এবং Claude Code ইঞ্জিন ব্যবহার করেন, তবে running Claude Code safely on a VPS-এ উল্লিখিত স্যান্ডবক্সিং অভ্যাসগুলো এই এজেন্টগুলোর ক্ষেত্রেও প্রযোজ্য।

FAQ

open-kritt-এর জন্য কেন আলাদা VPS প্রয়োজন?

কারণ এর অ্যানালাইসিস এজেন্টগুলো রুট (root) হিসেবে ডিসপোজেবল জব কন্টেইনারের ভেতরে চলে, যেখানে আপনার কোডের রাইটেবল কপি থাকে এবং সরাসরি ইন্টারনেট অ্যাক্সেস থাকে। এছাড়া ইঞ্জিন সার্ভিসটি হোস্টের Docker সকেট মাউন্ট করে রাখে, যাতে প্রতিটি জবের জন্য একটি করে কন্টেইনার চালু করা যায়। যে কোনো প্রসেস যা এই সকেটে পৌঁছাতে পারে, তা এমন একটি কন্টেইনার শুরু করতে পারে যা হোস্টের ফাইলসিস্টেম মাউন্ট করে ফেলে; তাই পুরো স্ট্যাকটিকে হোস্টের রুট হিসেবে বিবেচনা করা উচিত। একটি ডেডিকেটেড VPS-এ এটি একটি গ্রহণযোগ্য ঝুঁকি এবং সার্ভারটি নতুন করে তৈরি করতে আপনার কোনো খরচ নেই। কিন্তু আপনার প্রতিদিনের কাজের কম্পিউটারে এটি আপনার SSH কি (keys) এবং ব্রাউজার প্রোফাইলগুলোকে সেই একই ট্রাস্ট বাউন্ডারির ভেতরে নিয়ে আসে, যেখানে আপনি কোড স্ক্যান করছেন।

আমি কি SSH টানেল ব্যবহার না করে সরাসরি 5173 পোর্ট এক্সপোজ করতে পারি?

আপনার এটি করা উচিত নয়। ব্যাকএন্ডটি কোনো অ্যাপ্লিকেশন অথেন্টিকেশন ছাড়াই রিলিজ করা হয়, তাই ইন্টারনেট এবং আপনার ফাইন্ডিংস বা প্রোভাইডার ক্রেডিটের মাঝে এই পোর্টটিই একমাত্র বাধা। এই কারণেই compose ফাইলটি প্রতিটি সার্ভিসকে 127.0.0.1-এ বাইন্ড করে। এর পরিবর্তে ssh -N -L 5173:127.0.0.1:5173 you@your-server-ip চালান এবং লোকালি http://localhost:5173-এ ব্রাউজ করুন। একটি ufw রুল এর বিকল্প হতে পারে না, কারণ ufw-এর ডিফল্ট পলিসি কার্যকর হওয়ার আগেই একটি পাবলিশড Docker পোর্ট হ্যান্ডেল করা হয়।

আমি কীভাবে open-kritt-এর খরচ আমার পরিকল্পনার মধ্যে রাখতে পারি?

প্রথম স্ক্যান শুরু করার আগেই আপনার মডেল প্রোভাইডারের কনসোলে একটি হার্ড লিমিট সেট করুন, কারণ open-kritt-এর নিজস্ব কোনো বাজেট সেটিং নেই। প্রথম কয়েকবার চালানোর জন্য ডিফল্ট কনকারেন্সি (concurrency) বজায় রাখুন, যেমন ENGINE_WORKER_COUNT=2 এবং ENGINE_MAX_CONCURRENT_SCANS=1। মনে রাখবেন, একটি প্রোভাইডার অ্যাকাউন্ট ডিফল্টভাবে 15টি পর্যন্ত কনকারেন্ট রুট মডেল কল অনুমোদন করে, যেখানে একটি Codex সেশন পাঁচটি পর্যন্ত চাইল্ড এজেন্ট চালাতে পারে। ENGINE_WORKER_COUNT=0 নতুন জব নেওয়া বন্ধ করে দেয় এবং এটিই সবচেয়ে দ্রুত লোকাল স্টপ।

আমার কোন ভার্সনটি চেক আউট করা উচিত?

সবসময় একটি ট্যাগ ব্যবহার করুন, কখনোই main নয়। git fetch --tags এর পর git tag --list চালালে কী কী ভার্সন পাওয়া যাচ্ছে তা দেখা যাবে। এই লেখাটি লেখার সময় v1.3.0, যা 4 আগস্ট 2026-এ রিলিজ হয়েছে, সেটিই সবচেয়ে নতুন। ভার্সন পিন করে রাখলে কয়েক মাস পরে পুনরায় বিল্ড করলেও একই স্ট্যাক পাওয়া যায়। এতে আপগ্রেড করার বিষয়টি আপনি রিলিজ নোট পড়ার পর সিদ্ধান্ত নিতে পারেন, যা ভিন্ন দিনে ক্লোন করার সময় কোনো অনাকাঙ্ক্ষিত পার্শ্বপ্রতিক্রিয়া তৈরি করে না।

স্ক্যান শুরু হচ্ছে না। আমার কী চেক করা উচিত?

প্রথমে ফ্রি ডিস্ক স্পেস চেক করুন, কারণ ফ্রি স্টোরেজ ENGINE_MIN_FREE_STORAGE_GB (ডিফল্ট 20 GB) এর নিচে থাকলে ইঞ্জিন প্রতি-জব স্ক্যান কন্টেইনার চালু করবে না। এরপর চেক করুন ENGINE_WORKER_COUNT যেন 0 না হয়, কারণ এই ভ্যালুটি নতুন জব নেওয়া বন্ধ করে দেয়। এরপর নিশ্চিত করুন যে মডেল ক্রেডেনশিয়াল সঠিকভাবে কনফিগার করা হয়েছে কিনা, এর জন্য ./kritt setup চালান। কারণ শুধুমাত্র একটি GITHUB_TOKEN স্ক্যান চালাতে পারে না। docker compose logs engine কমান্ডটি জবটি কেন স্কিপ করা হয়েছে তার কারণ জানিয়ে দেবে।