راهنمای نصب و میزبانی open-kritt روی VPS

چرا open-kritt را روی یک VPS میزبانی کنیم و نه لپ‌تاپ شخصی

سرویس open-kritt را روی سروری میزبانی کنید که بتوانید آن را تخریب و دوباره بازسازی کنید. این ابزار، agentهای تحلیل خود را با دسترسی root درون containerهای موقت (disposable) اجرا می‌کند، به هر کدام یک کپی قابل‌نوشتن از کد شما و دسترسی مستقیم به اینترنت می‌دهد و Docker socket میزبان را در سرویس engine خود mount می‌کند. این یک معامله منطقی برای سیستمی است که صرفاً به این کار اختصاص یافته است، اما برای دستگاهی که کلیدهای SSH شما را نگه می‌دارد، انتخابی بسیار خطرناک است.

چهار ویژگی در پیکربندی پیش‌فرض، این توصیه را ضروری می‌کنند و هر چهار مورد مستقیماً از README و فایل compose خود پروژه استخراج شده‌اند.

agentها برای قدرتمند بودن طراحی شده‌اند. طبق مستندات README، agentهای مجهز به ابزار، با دسترسی root درون containerهای موقت اجرا می‌شوند. آن‌ها به کپی‌های قابل‌نوشتن از مخزن کد و دسترسی مستقیم به اینترنت دسترسی دارند تا بتوانند ابزارها را نصب کنند، targetها را کامپایل کنند، تست‌ها را اجرا کنند و proof of concept بسازند. یک اسکن، صرفاً یک linter برای خواندن فایل‌ها نیست؛ بلکه اجرای کد دلخواه است که شما خودتان درخواست کرده‌اید. دسترسی به اینترنت دوطرفه است: هر چیزی که agent هنگام تحقیق روی یک target دریافت می‌کند، متنی غیرقابل‌اعتماد است که وارد prompt می‌شود؛ این همان ریسکی است که هنگام دادن دسترسی جستجوی وب به یک agent می‌پذیرید.

engine به Docker socket دسترسی دارد. docker-compose.yml سوکت Docker میزبان را درون سرویس engine mount می‌کند، زیرا engine برای هر job یک container اسکن جداگانه می‌سازد و اجرا می‌کند. هر فرآیندی که به این سوکت دسترسی داشته باشد، می‌تواند containerای را شروع کند که فایل‌سیستم میزبان را mount کرده است. بنابراین، engine عملاً در هر میزبانی که اجرا شود، دسترسی root دارد.

صفحه ورود وجود ندارد. backend این ابزار بدون هیچ‌گونه احراز هویت (authentication) عرضه می‌شود. دسترسی به پورت، به معنای دسترسی به یافته‌های شما و اعتبار (credit) حساب کاربری‌تان در سرویس‌دهنده است.

کدی که اسکن می‌کنید اغلب متعلق به شما نیست. اشاره دادن agentها به یک مخزن کد شخص ثالث، به معنای اجرای فرآیند build آن مخزن روی دستگاه شما، با دسترسی root و دسترسی به شبکه است.

اگر مطلب چرا agentهای برنامه‌نویسی باید در یک VM موقت باشند را خوانده باشید، متوجه می‌شوید که این همان مدل تهدید است، با این تفاوت که در اینجا ریسک بسیار بالاتر است. برای open-kritt یک VPS اختصاصی تهیه کنید که هیچ سرویس دیگری روی آن نباشد و آن VPS را به جای کاربر root، از طریق یک حساب کاربری جداگانه با حداقل دسترسی مدیریت کنید.

عملکرد واقعی open-kritt

ابزار open-kritt (مخزن آن در Kritt-ai/open-kritt قرار دارد و تحت مجوز AGPL-3.0 منتشر شده است) تحقیقات مربوط به آسیب‌پذیری‌ها را به وظایف کوچک تقسیم می‌کند، این وظایف را به‌صورت موازی توسط عامل‌های هوش مصنوعی اجرا کرده و سپس نتایج دریافتی را حذف تکراری (de-duplicate) و رتبه‌بندی می‌کند. شما یک گردش‌کار را به شکل زنجیره‌ای از پرامپت‌های متمرکز تعریف می‌کنید و هر مرحله، context ساختاریافته‌ای را از مراحل پیش از خود دریافت می‌کند. هدف اسکن، یک مخزن git محلی یا راه دور است. موتور تحلیل، Codex یا Claude Code می‌باشد. پس از شناسایی یک کاندیدای آسیب‌پذیری، اسکریپت‌های پس‌پردازش اختیاری می‌توانند برای اعتبارسنجی یا ساخت یک proof of concept تلاش کنند.

آنچه در نهایت دریافت می‌کنید، فهرستی رتبه‌بندی‌شده از کاندیداها است. با این خروجی به عنوان یک صف اولویت‌بندی (triage queue) برخورد کنید، نه به عنوان یک گزارش نهایی.

پیش‌نیازهای شروع کار

• یک سرور مجازی (VPS) با سیستم‌عامل Ubuntu 24.04، Debian 12 یا Rocky Linux 9. مستندات نصب، این توزیع‌ها را برای معماری‌های x86_64 و ARM64 تأیید کرده‌اند.
• Docker Engine به همراه افزونه Compose.
• نسخه 20 یا جدیدتر Node.js روی میزبان؛ زیرا رابط خط فرمان ./kritt به‌جای اجرا درون کانتینر، روی سیستم میزبان اجرا می‌شود.
• یک ارائه‌دهنده مدل: حساب کاربری 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 را اجرا می‌کند در این گروه قرار دهید. برای مطالعه نسخه کامل‌تر این تنظیمات، به اجرای Docker روی VPS مراجعه کنید.

اوبونتو 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 و قفل کردن روی یک نسخه تگ‌شده

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) یک تگ، مخزن را در وضعیت detached HEAD قرار می‌دهد که در اینجا صحیح است: شما با این کلون به عنوان یک deployment ثابت (pinned) رفتار می‌کنید، نه شاخه‌ای که در آن commit انجام می‌دهید. برای ارتقا در آینده، یادداشت‌های انتشار را بخوانید، سپس git fetch --tags را اجرا کنید، تگ جدید را checkout کنید و دوباره ./kritt start را اجرا نمایید، زیرا start تصاویر (images) را بازسازی می‌کند.

دستور ./kritt را با sudo اجرا نکنید. مستندات در این مورد صریح هستند. رابط خط فرمان (CLI)، دایرکتوری‌های اعتبارنامه‌های محلی پروژه را در .data/ مدیریت می‌کند؛ بنابراین اجرای آن با دسترسی root باعث می‌شود مالکیت آن دایرکتوری‌ها به root تغییر یابد و اجرای عادی بعدی نتواند در آن‌ها بنویسد.

پیکربندی دسترسی به مدل با ./kritt setup

./kritt setup

این دستور در صورتی که .env وجود نداشته باشد، آن را از .env.example ایجاد می‌کند، وضعیت هر اعتبارنامه را نمایش می‌دهد و به شما اجازه می‌دهد آن‌ها را تنظیم یا حذف کنید. این دستور هرگز مقادیر را در ترمینال چاپ نمی‌کند. هم .env و هم فایل اعتبارنامه موتور با مجوز 0600 نوشته می‌شوند.

اگر ترجیح می‌دهید این کار را به‌صورت دستی انجام دهید:

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

سپس کلید ارائه‌دهنده را در .env ویرایش کنید و مجوز فایل را روی 0600 قرار دهید. در هر صورت، اکنون یک اعتبارنامه معتبر ارائه‌دهنده روی آن سرور قرار دارد؛ این خود دلیلی دیگر است که چرا این سرور نباید میزبان هیچ چیز دیگری باشد. برای این پروژه یک کلید اختصاصی بسازید تا ابطال آن در آینده، هیچ‌کدام از سرویس‌های مهم شما را مختل نکند. دور نگه داشتن اسرار از دسترس عوامل هوش مصنوعی به بررسی عادت‌های گسترده‌تر در این زمینه می‌پردازد.

تعیین سقف هزینه برای ارائه‌دهنده پیش از اولین اسکن

ابزار open-kritt به‌گونه‌ای طراحی شده است که عملیات را به‌صورت موازی (fan-out) انجام دهد و هزینه شما دقیقاً بر اساس همین عملیات موازی محاسبه می‌شود. مقادیر پیش‌فرض در .env.example در نسخه v1.3.0 محافظه‌کارانه هستند: ENGINE_WORKER_COUNT=2 که در فایل به‌عنوان یک مقدار پیش‌فرض محافظه‌کارانه برای یک ماشین کوچک 2-vCPU توصیف شده است، و ENGINE_MAX_CONCURRENT_SCANS=1. بالاتر از این‌ها، ENGINE_WORKERS_PER_ACCOUNT=15 قرار دارد که حداکثر تعداد فراخوانی‌های همزمان مدل ریشه (root model) مجاز در یک حساب ارائه‌دهنده است، و همچنین ENGINE_CODEX_MAX_SUBAGENTS_PER_SESSION=5، زیرا یک نشست Codex ممکن است تا پنج عامل (agent) فرزند را اجرا کند. با افزایش تعداد workerها روی یک VPS بزرگ‌تر، تعداد فراخوانی‌های مدل در حال اجرا نیز به همان نسبت افزایش می‌یابد.

هیچ بخشی در مخزن (repository) وجود ندارد که هزینه‌های شما را محدود کند. هیچ تنظیمات بودجه‌ای در .env.example وجود ندارد. شرایط توقف خودِ موتور، همان محدودیت‌های worker به اضافه ENGINE_HARNESS_TIMEOUT_SECONDS است که مقدار پیش‌فرض آن 7200 ثانیه برای هر اجرای harness است. بنابراین، سقف هزینه باید در سمت ارائه‌دهنده تعیین شود. کنسول ارائه‌دهنده خود را باز کنید و یک سقف ماهانه قطعی (hard limit) را پیش از اولین اسکن تعیین کنید، نه پس از آن. مقاله کنترل هزینه‌های عامل هوش مصنوعی روی یک VPS مراحل تنظیمات مربوط به هر ارائه‌دهنده را توضیح می‌دهد.

یک ترمز محلی نیز وجود دارد. تنظیم ENGINE_WORKER_COUNT=0 باعث توقف دریافت کارهای جدید می‌شود و همین مقادیر worker را می‌توان پس از راه‌اندازی stack، از طریق صفحه Settings تغییر داد.

این راهنما هیچ قیمتی برای هر اسکن ارائه نمی‌دهد، زیرا هزینه به اندازه مخزن، گردش کاری که می‌سازید و مدلی که پشت آن قرار دارد بستگی دارد. ابتدا یک اسکن روی یک مخزن کوچک اجرا کنید، سپس پیش از آنکه ابزار را به سمت پروژه‌های بزرگ هدایت کنید، صفحه میزان مصرف (usage) در پنل ارائه‌دهنده خود را بررسی کنید.

راه‌اندازی پشته و بررسی سلامت آن

./kritt start

این دستور .env و حداقل یک اعتبارنامه را بررسی کرده و سپس docker compose up --build را اجرا می‌کند. اولین build زمان‌بر است، زیرا imageهای مربوط به frontend، backend، engine، executor view و database را می‌سازد. این فرآیند در foreground اجرا می‌شود، بنابراین بستن نشست SSH باعث توقف پشته خواهد شد. آن را درون tmux اجرا کنید، یا پس از موفقیت‌آمیز بودن اولین build، آن را در حالت detached بالا بیاورید. هیچ‌کدام از این روش‌ها به‌تنهایی پس از reboot باقی نمی‌مانند؛ بنابراین اگر می‌خواهید پشته پس از راه‌اندازی مجدد سرور دوباره بالا بیاید، الگوی unit در systemd که در نگهداری یک agent خودمیزبان در طول rebootها توضیح داده شده، مستقیماً قابل استفاده است.

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 از داخل دایرکتوری repository متوقف کنید.

یک مورد اختیاری اضافی: docker compose exec backend npm run seed داده‌های نمونه را بارگذاری می‌کند که روشی کم‌هزینه برای مشاهده رابط کاربری پیش از صرف هرگونه هزینه برای یک اسکن واقعی است.

دسترسی به رابط کاربری روی پورت 5173 از طریق تونل SSH

هر سرویس در فایل compose به‌طور پیش‌فرض به 127.0.0.1 متصل می‌شود: فرانت‌اند روی 5173، بک‌اند روی 3002، نمای executor روی 8090 و Postgres روی 5432. این اتصالات را تغییر ندهید و پورت را از طریق SSH از روی ماشین خودتان فوروارد کنید.

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

در حالی که دستور در حال اجراست، http://localhost:5173 را در مرورگر محلی خود باز کنید. -N به این معناست که اتصال فقط فوروارد را حمل می‌کند و شل (shell) باز نمی‌شود. هنگامی که به نمای executor نیز نیاز دارید، یک -L 8090:127.0.0.1:8090 دوم به همان دستور اضافه کنید.

وسوسه می‌شوید که FRONTEND_BIND_ADDRESS=0.0.0.0 را تنظیم کنید و از تونل صرف‌نظر کنید. این کار را نکنید. بک‌اند هیچ صفحه ورودی ندارد، بنابراین هر کسی که به آن صفحه برسد می‌تواند اسکن‌ها را شروع کند و اعتبار ارائه‌دهنده شما را مصرف کند. تله دومی نیز در زیر آن وجود دارد: پورت کانتینر منتشر شده (published) پیش از اعمال سیاست پیش‌فرض ufw مدیریت می‌شود، بنابراین یک قانون ufw deny 5173 درست به نظر می‌رسد اما عملاً چیزی را مسدود نمی‌کند. پورت‌های Docker که ufw را دور می‌زنند زنجیره قوانینی را نشان می‌دهد که باعث این اتفاق می‌شود.

تعیین اندازه VPS

ENGINE_MIN_FREE_STORAGE_GB به‌طور پیش‌فرض روی 20 تنظیم شده است و اگر فضای ذخیره‌سازی آزاد به کمتر از این مقدار برسد، موتور از اجرای container جدید برای اسکن هر job خودداری می‌کند. ایمیج‌های ساخته‌شده، کش checkout، داده‌های Postgres و فضای کاری jobها همگی روی یک دیسک قرار دارند، بنابراین یک VPS با 20 گیگابایت فضا هرگز اسکن را شروع نمی‌کند. عدد 40 گیگابایت را به عنوان حداقل در نظر بگیرید و اگر مخازن (repositories) بزرگ را اسکن می‌کنید، فضای بیشتری اختصاص دهید.

حافظه از یک محاسبه ساده پیروی می‌کند. ENGINE_MEMORY_RESERVE_GB=2 بخشی از حافظه را برای موتور، پایگاه داده، API و سربار کوتاه‌مدت رزرو می‌کند و هر runner اسکن، یک مقدار رزرو و یک سقف سخت (hard cap) به میزان ENGINE_SCAN_RUNNER_MEMORY_MB=1536 دارد. بنابراین، دو worker پیش از اجرای هر چیز دیگری به حدود 5 گیگابایت حافظه نیاز دارند. موتور فقط runnerهایی را می‌پذیرد که در بودجه باقی‌مانده جای بگیرند؛ بنابراین در یک سیستم کوچک، اسکن‌ها به جای شکست خوردن، در صف قرار می‌گیرند که حالت شکست بسیار بهتری نسبت به کشته شدن توسط OOM (Out-of-Memory Killer) است.

دو تنظیم پاک‌سازی (prune) به‌طور پیش‌فرض روی true هستند: ENGINE_AUTO_PRUNE_DOCKER_BUILD_CACHE و ENGINE_AUTO_PRUNE_UNUSED_DOCKER_IMAGES. پس از تکمیل یک task، موتور کش ساخت (build cache) استفاده‌نشده، ایمیج‌های استفاده‌نشده و containerهای اسکن متوقف‌شده را حذف می‌کند. ایمیج‌هایی که توسط یک container در حال اجرا ارجاع داده شده‌اند، bind mountها، داده‌های پایگاه داده، اعتبارنامه‌ها و volumeها حفظ می‌شوند. این همچنان دلیلی دیگر برای عدم اشتراک‌گذاری میزبان (host) است: یک ابزار پاک‌سازی که شما پیکربندی نکرده‌اید، در حال اجرا روی آن Docker daemon است.

اسکن یک مخزن محلی بدون نشت اطلاعات

LOCAL_REPOS_PATH به‌صورت پیش‌فرض روی ./local_repos تنظیم شده است و از طریق bind-mount در کانتینرهای backend و engine در مسیر /local_repos در دسترس قرار می‌گیرد؛ بنابراین مخزنی که در آن پوشه روی میزبان (host) قرار می‌دهید، بلافاصله درون کانتینرها ظاهر می‌شود. از یک clone تازه استفاده کنید، نه از working tree خود. کانتینر job یک کپی قابل‌نوشتن دریافت می‌کند، دسترسی root درون خود دارد و به اینترنت خروجی متصل است؛ این یعنی هر چیزی که در آن کپی وجود داشته باشد، می‌تواند تغییر یابد یا از سرور خارج شود. پیش از کپی کردن پروژه، فایل‌های .env و کلیدهای خصوصی را حذف کنید.

آنچه دریافت می‌کنید و آنچه دریافت نمی‌کنید

شما یافته‌های نامزدی رتبه‌بندی‌شده را دریافت می‌کنید. شما آسیب‌پذیری‌های تأییدشده دریافت نمی‌کنید. رتبه‌بندی و حذف موارد تکراری، ترتیب صف رسیدگی (triage) شما را تعیین می‌کند. این موارد ثابت نمی‌کنند که یک ورودی واقعی است. اسکریپت‌های پس‌پردازش (post-scripts) می‌توانند برای اعتبارسنجی و ساخت یک نمونه اولیه (proof of concept) تلاش کنند، و این قوی‌ترین سیگنالی است که ابزار ارائه می‌دهد، اما شکست یک اسکریپت پس‌پردازش به معنای کاذب بودن یافته نیست. یک انسان همچنان باید تک‌تک نامزدها را بررسی کند.

این راهنما هیچ ادعایی در مورد تعداد باگ‌های واقعی که open-kritt پیدا می‌کند ندارد، زیرا ما آن را اندازه‌گیری نکرده‌ایم. هر کسی که نرخ شناسایی برای کدبیس شما اعلام می‌کند، آن را روی کدبیس شما اجرا نکرده است. ابتدا مخزنی را اسکن کنید که از قبل به‌خوبی می‌شناسید: یافته‌هایی که خودتان می‌توانید قضاوت کنید، ارزان‌ترین روش کالیبراسیون موجود هستند.

در اینجا مجوزها بیش از اکثر ابزارهای self-hosted اهمیت دارند. عامل‌ها (agents) کد را کامپایل و اجرا می‌کنند و به شبکه دسترسی دارند، بنابراین مرحله ساخت نمونه اولیه می‌تواند سیستم‌های زنده را تحت تأثیر قرار دهد. ابزار را به سمت کدی بگیرید که مالک آن هستید یا قرارداد تست آن را دارید، و پیش از اجرای هر چیزی، محدوده هدف (target scope) را یادداشت کنید. اگر ANTHROPIC_API_KEY را پیکربندی کرده‌اید و از موتور Claude Code استفاده می‌کنید، اصول sandbox در اجرای ایمن Claude Code روی یک VPS برای این عامل‌ها نیز صدق می‌کند.

FAQ

چرا open-kritt به VPS اختصاصی خود نیاز دارد؟

زیرا عامل‌های تحلیل آن به‌عنوان root در داخل کانتینرهای کاری یک‌بارمصرف با کپی‌های قابل‌نوشتن از کد شما و دسترسی مستقیم به اینترنت اجرا می‌شوند و سرویس موتور، Docker socket میزبان را mount می‌کند تا بتواند برای هر کار یک کانتینر جداگانه راه‌اندازی کند. هر فرآیندی که به آن socket دسترسی پیدا کند، می‌تواند کانتینری را اجرا کند که فایل‌سیستم میزبان را mount می‌کند؛ بنابراین کل این پشته (stack) باید در سطح root میزبان در نظر گرفته شود. در یک VPS اختصاصی، این یک مصالحهٔ قابل‌قبول است و بازسازی سرور هزینه‌ای برای شما ندارد. اما روی ایستگاه کاری روزمره، این کار کلیدهای SSH و پروفایل‌های مرورگر شما را در همان محدودهٔ اعتماد (trust boundary) کدی قرار می‌دهد که در حال اسکن آن هستید.

آیا می‌توانم به‌جای استفاده از SSH tunnel، پورت 5173 را در معرض اینترنت قرار دهم؟

نباید این کار را انجام دهید. بخش backend بدون احراز هویت داخلی عرضه می‌شود، بنابراین آن پورت تنها مانع بین اینترنت و یافته‌ها و اعتبار (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 جلوگیری کنم؟

پیش از اولین اسکن، یک محدودیت سخت (hard limit) در کنسول ارائه‌دهندهٔ مدل خود تنظیم کنید، زیرا open-kritt تنظیمات بودجهٔ داخلی ندارد. برای چند اجرای اول، مقادیر پیش‌فرض concurrency یعنی ENGINE_WORKER_COUNT=2 و ENGINE_MAX_CONCURRENT_SCANS=1 را حفظ کنید و به یاد داشته باشید که یک حساب کاربری ارائه‌دهنده به‌طور پیش‌فرض اجازهٔ حداکثر 15 فراخوانی همزمان مدل ریشه را می‌دهد، در حالی که یک نشست Codex ممکن است تا پنج عامل فرزند را اجرا کند. دستور ENGINE_WORKER_COUNT=0 دریافت کارهای جدید را متوقف می‌کند و سریع‌ترین راه برای توقف محلی است.

کدام نسخه را باید دریافت (checkout) کنم؟

همیشه از یک tag استفاده کنید و هرگز از main استفاده نکنید. دستور git fetch --tags به همراه git tag --list نسخه‌های موجود را نشان می‌دهد و v1.3.0 که در تاریخ 4 اوت 2026 منتشر شده، جدیدترین نسخه در زمان نگارش این متن است. استفاده از نسخهٔ ثابت (pinning) باعث می‌شود که بازسازی پشته پس از ماه‌ها دقیقاً همان نتیجه را بدهد و ارتقا به تصمیمی تبدیل شود که پس از خواندن یادداشت‌های انتشار (release notes) می‌گیرید، نه یک اثر جانبی از clone کردن در روزهای مختلف.

اسکن شروع نمی‌شود. چه چیزی را باید بررسی کنم؟

ابتدا فضای خالی دیسک را بررسی کنید، زیرا اگر فضای ذخیره‌سازی کمتر از ENGINE_MIN_FREE_STORAGE_GB باشد (که به‌صورت پیش‌فرض 20 گیگابایت است)، موتور کانتینر اسکن برای هر کار را اجرا نمی‌کند. سپس بررسی کنید که ENGINE_WORKER_COUNT برابر با 0 نباشد، زیرا این مقدار دریافت کارهای جدید را متوقف می‌کند. سپس با اجرای ./kritt setup تأیید کنید که اعتبارنامهٔ مدل واقعاً پیکربندی شده است، زیرا GITHUB_TOKEN به‌تنهایی نمی‌تواند اسکن‌ها را اجرا کند. دستور docker compose logs engine دلیل نادیده گرفتن کار را اعلام می‌کند.