استضافة KiroCrew على VPS ليعمل دائماً

لماذا تستضيف KiroCrew ذاتياً على VPS بدلاً من حاسوب محمول

لا تحقق الاستضافة الذاتية لـKiroCrew فائدتها إلا على جهاز لا يدخل في وضع السكون مطلقاً. لذلك يكون VPS هو المكان المناسب لها، وليس الحاسوب المحمول. يحتفظ KiroCrew بسجل الجلسات، والذاكرة الدلالية، والمهام المجدولة، وقائمة الانتظار الخاصة بالموافقات على القرص. ويعيد تحميل كل ذلك عند إعادة تشغيل العملية. لا يفيد أي من ذلك إذا لم تكن العملية قيد التشغيل عند الساعة 03:00، موعد تنفيذ مهمة مجدولة. والحاسوب المحمول المغلق لا يشغّلها.

KiroCrew هو مساحة عمل مفتوحة المصدر للوكلاء من فريق Kiro، ومرخّصة بموجب Apache 2.0. صدرت إصداراته العامة الأولى في أوائل أغسطس 2026. تتولى عملية واحدة، تُسمى gateway، إدارة الحالة وتوفير لوحة ويب على المنفذ 5476. يمكنك الوصول إلى هذه البوابة من لوحة الويب، أو من kirocrew CLI، أو من قناة محادثة مثل Slack. البوابة هي المكوّن الوحيد الذي تستضيفه ذاتياً. لذلك يركّز هذا الدليل على إبقائها قيد التشغيل، وإبعادها عن الإنترنت العام، والتمكن من استعادتها بعد ترقية غير ناجحة.

هناك أمران يجب معرفتهما قبل البدء. يشغّل KiroCrew kiro-cli، الذي يتطلب تسجيل دخول لمرة واحدة باستخدام حساب Kiro. كما تُحتسب تكلفة استدلال الوكيل ضمن خطة Kiro. لذلك، حتى أغسطس 2026، لا يُعد هذا إعداداً يعمل دون اتصال. المشروع عمره أسابيع قليلة أيضاً. افترض أنك ستحتاج إلى التراجع عن ترقية في مرحلة ما، وثبّته بطريقة تتيح لك ذلك. إذا لم يسبق لك تشغيل وكيل على خادم، يشرح تشغيل وكيل برمجي على VPS القواعد الأساسية التي يعتمد عليها هذا الدليل. وإذا كانت جهة الوكلاء أحدث عهداً لك من جهة الخوادم، فابدأ بـتعلّم ماهية حلقة الوكيل وأدواتها وذاكرته فعلياً؛ فهذا سيجعل الخيارات أدناه تبدو قرارات واضحة، لا أوامر غامضة.

ما يحتاج إليه KiroCrew ومكان تخزين حالته

يتطلب التثبيت الأصلي Python 3.10 أو إصداراً أحدث، ويوصي المشروع بالإصدار 3.12. ويتطلب أيضاً Node.js 18 أو إصداراً أحدث إذا أنشأت لوحة المعلومات من المصدر، إضافة إلى kiro-cli، الذي يثبّته التشغيل الأول ويسجّل دخولك إليه نيابةً عنك. لا يحتاج تثبيت الحاوية إلى أي من ذلك على المضيف. بل يحتاج إلى Docker. وهذا هو السبب الرئيسي لتفضيله.

تُخزَّن الحالة في ~/.kiro/crew، وينقل متغير البيئة KIROCREW_HOME هذه الحالة إلى موقع آخر. ويتضمن هذا المجلد ما يلي:

• config.json: إعدادات البوابة وبيانات اعتماد قنوات الدردشة.
• .env: الأسرار.
• workspace/memory/: التفضيلات وملاحظات المشروع وسجل الدردشة.
• memory.db وmemory_index.db: الفهارس الدلالية وفهارس البحث النصي الكامل.
• models/: نموذج التضمين، الذي يُنزَّل عند التشغيل الأول.
• gateway.log وsecurity_events.jsonl: سجل التشغيل وسجل الأحداث الأمنية.

هذا المجلد هو التثبيت. انسخه إلى VPS جديد، وستكون قد نقلت وكيلك. لذلك يهم قسم النسخ الاحتياطي أدناه أكثر من قسم التثبيت.

خطط لاستخدام مساحة القرص بدلاً من التركيز على RAM. البوابة عملية Python؛ وما يحمّل الخادم فعلياً هو ما يشغّله الوكيل، مثل عملية بناء أو مجموعة اختبارات. يزداد حجم مجلد الحالة مع سجل الدردشة، ويصل نموذج التضمين عند التشغيل الأول. لذلك قِس الحجم على خادمك باستخدام du -sh ~/.kiro/crew بعد بضعة أسابيع، بدلاً من الاعتماد على أي رقم نُشر خلال الشهر الأول من المشروع. قارن ذلك ببيئة تشغيل تمنح كل عامل حاويته ومتصفحه الخاص، حيث يجعل استضافة زملاء OpenBot في الذكاء الاصطناعي ذاتياً تحديد الحجم مسألة RAM قبل أن تكون مسألة مساحة قرص.

أي مسار من مسارات التثبيت الثلاثة ينبغي استخدامه

ينشر المشروع ثلاثة مسارات. يجلب المثبّت المؤلف من سطر واحد حزمة wheel ويضع kirocrew في متغير PATH لديك:

curl -fsSL https://download.crew.kiro.dev/cli.sh | sh

يقبل الخيار الخاص بالقناة والخيار الخاص بالإصدار:

curl -fsSL https://download.crew.kiro.dev/cli.sh | sh -s -- --channel insider
curl -fsSL https://download.crew.kiro.dev/cli.sh | sh -s -- --version 0.1.3

تُنشر صورة الحاوية في ghcr.io/kirodotdev/kirocrew، وتدعم linux/amd64 وlinux/arm64 ضمن كل وسم. يتطلب البناء من المصدر git clone بالإضافة إلى make build، وهو مخصص لمن يغيّرون الشيفرة، وليس لمن يشغّلونها.

استخدم الحاوية. يضع التثبيت الأصلي حزم Python وNode وkiro-cli على المضيف نفسه الذي يشغّل خدماتك الأخرى، لذلك قد يتركك التحديث الفاشل مضطراً إلى معالجة آثاره يدوياً. تحفظ الحاوية بيئة التشغيل في صورة واحدة والحالة في volume واحد، وبذلك تصبح عملية التراجع تغييراً للوسم وإعادة تشغيل.

ثبّت الصورة على وسم إصدار، وليس على stable

يستخدم المثال الخاص بالمشروع وسم stable:

docker run -d --name kirocrew \
  -p 127.0.0.1:5476:5476 \
  -v kirocrew-home:/home/kirocrew \
  ghcr.io/kirodotdev/kirocrew:stable

stable وسم متغير. ويشير إلى أحدث إصدار مستقر في كل مرة، لذلك قد يؤدي السحب التالي إلى تغيير الإصدار الذي تشغّله من دون أن تختاره، كما أن الوسم لا يوضح الإصدار الذي كان مستخدماً. أما وسوم الإصدارات فهي غير قابلة للتغيير، لذا ثبّت أحدها. أحدث إصدار حتى 6 August 2026 هو 0.1.3، وقد نُشر في 5 August 2026. ويوجد أيضاً وسم nightly، لكن وجوده في مشروع حديث إلى هذا الحد يعني أن الشيفرة تغيّرت هذا الصباح.

اكتب /opt/kirocrew/compose.yaml:

services:
  kirocrew:
    image: ghcr.io/kirodotdev/kirocrew:0.1.3
    container_name: kirocrew
    restart: unless-stopped
    ports:
      - "127.0.0.1:5476:5476"
    volumes:
      - kirocrew-home:/home/kirocrew

volumes:
  kirocrew-home:

شغّله، ثم تحقّق من نقطة نهاية health التي تستخدمها الصورة أيضاً من أجل HEALTHCHECK الخاص بها:

cd /opt/kirocrew
docker compose up -d
docker compose ps
curl -s http://127.0.0.1:5476/api/health

يجب أن يبلغ docker compose ps عن أن الحاوية سليمة خلال دقيقة تقريباً، وتستجيب /api/health من دون token، وكذلك /api/live و/api/ready، وهذا ما يجعلها صالحة للاستخدام كـprobes. إذا بقيت الحالة عند starting، فاقرأ docker logs kirocrew قبل تغيير أي شيء. ينزّل التشغيل الأول نموذج embedding، لذلك قد يجعل الاتصال البطيء عملية البدء طويلة.

أبقِه قيد التشغيل باستخدام systemd

يعيد restart: unless-stopped تشغيل الحاوية بعد تعطلها وبعد إعادة التشغيل، ما دام Docker نفسه يبدأ عند الإقلاع. يوضّح ملف الوحدة هذه التبعية صراحةً، ويوفّر أمراً واحداً يوقف الحزمة كاملة قبل إجراء نسخة احتياطية. يشرح بدء حزمة Docker Compose عند الإقلاع النمط العام. هذا هو الشكل المستخدم مع KiroCrew في /etc/systemd/system/kirocrew.service:

[Unit]
Description=KiroCrew gateway
Requires=docker.service
After=docker.service

[Service]
Type=oneshot
RemainAfterExit=yes
WorkingDirectory=/opt/kirocrew
ExecStart=/usr/bin/docker compose up -d
ExecStop=/usr/bin/docker compose down
TimeoutStartSec=0

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now kirocrew
systemctl status kirocrew

يجب أن يعرض systemctl status kirocrew القيمة active (exited)، وهي النتيجة السليمة لهذه الوحدة. استخدام Type=oneshot مع RemainAfterExit=yes صحيح هنا لأن docker compose up -d يعيد النتيجة فور بدء الحاوية: يتتبع systemd حقيقة أن الحزمة تعمل، وليس عملية تعمل في المقدمة. إذا كتبت Type=simple بدلاً من ذلك، فسيرى systemd أن الأمر انتهى فوراً، ويضع علامة على أن الخدمة متوقفة، ثم يستسلم أو يدخل في حلقة إعادة تشغيل، بحسب إعداد Restart=. عند التثبيت الأصلي، يوفّر المشروع البديل الخاص به، kirocrew service install، الذي يكتب /etc/systemd/system/kirocrew.service ويشغّل البوابة بصلاحيات مستخدمك. لا تشغّل الوحدتين معاً. يتناول خدمات systemd والمؤقتات على VPS هذا الموضوع بتفصيل أوسع. تكون الوحدة التي تفشل في العودة صامتة ما لم تجعلها ترسل تنبيهاً، لذلك أضف معالج OnFailure= الذي يرسل تنبيهاً إلى خادم ntfy الخاص بك، وستعرف من هاتفك أن البوابة متوقفة بدلاً من اكتشاف ذلك عبر مهمة مجدولة لم تُشغَّل مطلقاً.

التشغيل الأول: سجّل الدخول واحصل على رمز مميز للوحة المعلومات

تبدأ الحاوية تشغيل البوابة، لكن بيئة تشغيل الوكيل لم تُسجّل الدخول بعد. سجّل الدخول داخل الحاوية:

docker exec -it kirocrew kiro-cli login

يعرض ذلك رمز جهاز وعنوان URL تفتحه في متصفحك. بعد ذلك، أنشئ رمزاً مميزاً للوحة المعلومات:

docker exec kirocrew kirocrew token --ttl 2h

عنوان URL للوحة المعلومات هو http://localhost:5476/?token=<the token>. تنتهي صلاحية الرموز المميزة؛ وتكون الجلسات مضبوطة افتراضياً على ساعة واحدة، بينما يبلغ الحد الأقصى الموثق عشرين ساعة. إذا حمّلت لوحة المعلومات صفحة فارغة أو أعادتك مباشرة إلى صفحة تسجيل الدخول، فغالباً ما يكون السبب انتهاء صلاحية الرمز المميز. أنشئ رمزاً آخر. لا تلصق الرمز المميز في تذكرة أو رسالة دردشة مطلقاً، لأن من يملكه يملك الوكيل لديك.

الوصول إلى لوحة المعلومات عبر SSH، وعدم نشر المنفذ 5476 مطلقاً

أعد النظر في عنوان الربط في المثال الوارد في المشروع: -p 127.0.0.1:5476:5476. يستمع البوابة داخل الحاوية على 0.0.0.0، لأن الوصول إليها يجب أن يكون ممكناً عبر تعيين المنفذ، لكن التعيين نفسه ينشر المنفذ على loopback في الخادم فقط. احذف البادئة 127.0.0.1:، وستصبح البوابة متاحة على الإنترنت العام لأي شخص يفحص ذلك المنفذ. ولن تحميك قاعدة جدار ناري أيضاً: ينشر Docker المنافذ بكتابة قواعد DNAT تُقيَّم قبل ترشيح ufw، لذلك لا يؤدي ufw deny 5476 أي وظيفة مع منفذ منشور. يشرح تجاوز منافذ Docker لـ ufw هذه الآلية بالتفصيل.

أعد توجيه المنفذ عبر SSH من حاسوبك المحمول:

ssh -N -L 5476:127.0.0.1:5476 you@your-server.example.com

اترك هذا الأمر قيد التشغيل وافتح http://localhost:5476/?token=<the token> محلياً. لجعل إعادة التوجيه تلقائية مع كل اتصال، أضفها إلى ~/.ssh/config:

Host your-server.example.com
    LocalForward 5476 127.0.0.1:5476

إذا كان المنفذ 5476 مستخدماً بالفعل على حاسوبك المحمول، فغيّر الرقم الموجود على اليسار فقط: ssh -N -L 45476:127.0.0.1:5476 you@your-server.example.com، ثم انتقل إلى http://localhost:45476/?token=... في المتصفح. ستستخدم إعادة توجيه متعددة بهذه الطريقة بمجرد أن يشارك وكيل ثانٍ الخادم، لأن الاستضافة الذاتية لـ open-kritt لفحص الأمان تضيف لوحة معلومات أخرى تقتصر على loopback على الخادم نفسه، على المنفذ 5173.

هناك سلوك موثّق يجب توقّعه عند استخدام نفق: يقرأ gateway الطلبات المُعاد توجيهها على أنها صادرة عن remote، ولذلك ترفض نقاط النهاية الخاصة بكتابة الإعدادات وكشف الأسرار في لوحة المعلومات هذه الطلبات. إذا لم يُحفَظ تغيير في الإعدادات عبر SSH، فذلك هو السبب وليس خطأً. عدّل الإعدادات على الخادم مباشرة:

docker cp kirocrew:/home/kirocrew/.kiro/crew/config.json .
# edit config.json here
docker cp config.json kirocrew:/home/kirocrew/.kiro/crew/config.json
docker exec -u 0 kirocrew chown kirocrew:kirocrew /home/kirocrew/.kiro/crew/config.json
docker restart kirocrew

للوصول من الهاتف، يشير المشروع إلى tailscale serve الخاص بـTailscale، ما يُبقي لوحة المعلومات داخل tailnet الخاص بك بدلاً من إتاحتها على اسم مضيف عام. فضّل ذلك على استخدام reverse proxy عام. ينتقل الرمز المميز ضمن URL، ويُكتب URL في كل سجل وصول يمر عبره. تتعلق هذه القاعدة بما يوجد خلف المنفذ، لا بالمنفذ نفسه: فشيء مثل Halcyon، الذي يعيد بناء مكتبة Jellyfin على هيئة متجر فيديوهات من حقبة التسعينيات يمكن تصفحه متاح ليفتحه أشخاص آخرون، ويُعد مرشحاً مناسباً لـreverse proxy، بينما لا تكون البوابة التي يمكنها تشغيل أوامر على خادمك مناسبة لذلك.

امنح الوكيل أصغر نطاق تأثير ممكن

يفحص الحاوي دعم العزل عند بدء التشغيل للمرة الأولى، وتحدد النتيجة ما إذا كان بإمكان الوكلاء تنفيذ أي شيء. إذا كان عزل مساحات الأسماء متاحاً، تُشغَّل العمليات الفرعية للوكيل معزولة. وإذا لم يكن متاحاً ولم يكن KIROCREW_ALLOW_UNSANDBOXED=1 مضبوطاً، يُرفض التنفيذ بدلاً من تشغيله دون عزل. لذلك تكون هذه عادةً حالة بوابة تبدو سليمة بينما تتعطل كل مهمة. يُحفظ القرار في docker logs kirocrew منذ عملية التشغيل الأولى. ينشر المشروع أيضاً ملف تعريف seccomp (وضع الحوسبة الآمنة) يمكنك تطبيقه:

curl -fsSL https://raw.githubusercontent.com/kirodotdev/KiroCrew/main/docker/seccomp/kirocrew-seccomp.json \
  -o /opt/kirocrew/kirocrew-seccomp.json

    security_opt:
      - seccomp:./kirocrew-seccomp.json

إذا ضبطت KIROCREW_ALLOW_UNSANDBOXED=1، فكن واضحاً بشأن ما تغيّر: أصبح الحاوي الآن الحد الفاصل الوحيد بين الوكيل وخادمك. يستحق تحذير المشروع التكرار كاملاً. لا تربط مسارات من المضيف لن تسلّمها مباشرةً إلى الوكيل. عملياً، يستبعد ذلك Docker socket، وأي bind mount لـ/، وأي مجلد يحتوي على بيانات خدمة أخرى.

أما بقية الإطار، فينطبق على كل وكيل مسموح له بتشغيل الأوامر. قيّد صلاحيات بيانات الاعتماد الخاصة به بالمستودع الواحد أو بالحاوية الواحدة التي يحتاج إليها، ولا تستخدم أبداً token شخصياً يملك صلاحيات على مستوى الحساب بالكامل. شغّله كمستخدم مخصص لا يحتوي مجلد home الخاص به على أي شيء آخر. وهذا هو الغرض من المستخدمين ذوي أقل الصلاحيات على VPS. عندما يكتب الوكيل التعليمات البرمجية ثم يشغّلها، امنحه جهازاً يُسمح له بإتلافه: تُعد آلة VM مؤقتة لوكلاء البرمجة حداً فاصلاً أقوى من أي flag في ملف compose هذا، لأنك تحذفها بدلاً من تنظيفها. وينطبق المنطق نفسه على تشغيل OpenClaw بأمان على VPS وعلى استضافة وكيل Hermes ذاتياً على VPS. تُعد الأدوات جزءاً من نطاق التأثير أيضاً: فعند منح الوكيل إمكانية البحث على الويب، تصبح كل صفحة يجلبها إدخالاً غير موثوق، لذلك فإن توجيهه إلى نسخة SearXNG الخاصة بك قرار يتعلق بحقن التعليمات بقدر ما هو قرار يتعلق بالتوصيل. كما تستهلك المهام المجدولة المال أثناء نومك، لأن تكاليف الاستدلال تُحمّل على خطة Kiro الخاصة بك. لذلك اضبط الحدود الموضحة في التحكم في تكلفة وكيل ذكاء اصطناعي على VPS قبل إضافة مهمة ليلية.

انسخ نسخة احتياطية من وحدة الحالة قبل كل ترقية

اعثر على اسم الوحدة الفعلي أولاً. تضيف Compose اسم المشروع إلى أسماء الوحدات المسماة، ويكون اسم المشروع افتراضياً هو اسم الدليل. لذلك تُنشأ الوحدة المعلنة باسم kirocrew-home في /opt/kirocrew/compose.yaml باسم kirocrew_kirocrew-home:

docker volume ls

أوقف البوابة قبل نسخ أي شيء. memory.db وmemory_index.db هما قاعدتا بيانات SQLite، ونسخ قاعدة بيانات أثناء الكتابة إليها قد يلتقط معاملة مكتوبة جزئياً، فتُستعاد كملف تالف. تذكر تعليمات الترحيل الخاصة بالمشروع القاعدة نفسها: انقل الذاكرة فقط عندما تكون البوابات متوقفة. ولا تقتصر قاعدة الإيقاف أولاً على KiroCrew. وإذا كان خادم صور يستخدم الخادم نفسه، فإن مقارنة PhotoPrism وImmich تعرض أوامر النسخ الاحتياطي الدقيقة التي يحتاج إليها كل منهما.

sudo systemctl stop kirocrew
docker run --rm -v kirocrew_kirocrew-home:/data:ro -v "$PWD":/backup \
  alpine tar czf /backup/kirocrew-2026-08-06.tgz -C /data .
sudo systemctl start kirocrew

انسخ الأرشيف إلى خارج الخادم. وتستخدم الاستعادة الأمر نفسه بعد إيقاف الحاوية، مع وضع tar xzf بدلاً من tar czf:

sudo systemctl stop kirocrew
docker run --rm -v kirocrew_kirocrew-home:/data -v "$PWD":/backup \
  alpine tar xzf /backup/kirocrew-2026-08-06.tgz -C /data
sudo systemctl start kirocrew

الانتقال إلى مضيف جديد يختلف عن الاستعادة في مكانها، وقد حدد المشروع متطلباته بدقة. تنتقل سجلات المحادثات وملاحظات المشروع الموجودة ضمن workspace/memory/، وكذلك ملفا قاعدة البيانات وconfig.json. أما ملفات PID وسجل الأحداث الأمنية و.env فمرتبطة بالمضيف القديم، لذلك اتركها وانقل الأسرار مرة أخرى إلى الخادم الجديد.

كيفية التراجع عن ترقية سيئة

الترقية قصيرة، وهي آمنة فقط لأنك ثبّتَّ إصداراً محدداً. خذ النسخة الاحتياطية أولاً، ثم غيّر الوسم:

sudo systemctl stop kirocrew
# take the backup here, as above
sudo nano /opt/kirocrew/compose.yaml   # set the new image tag
sudo systemctl start kirocrew
docker compose -f /opt/kirocrew/compose.yaml ps
curl -s http://127.0.0.1:5476/api/health

يسحب docker compose up -d الصورة إذا لم تكن موجودة على الخادم، لذلك يكفي تعديل الوسم لإجراء الترقية بالكامل. التراجع هو التسلسل نفسه مع الرقم القديم، ويمنحك الصورة نفسها التي كانت لديك قبل الترقية، لأن وسوم الإصدارات غير قابلة للتغيير.

يُجرى التراجع عن البرنامج الثنائي دون مشكلات. أما الحالة فقد لا تتراجع بالطريقة نفسها. يمكن لبوابة أحدث إعادة كتابة config.json أو ترحيل قواعد بيانات الذاكرة إلى بنية لا تستطيع بوابة أقدم قراءتها، ولا يوجد مسار موثّق للرجوع إلى إصدار أقدم حتى August 2026. لذلك، إذا بدأت الصورة الأقدم ثم تصرفت بطريقة غريبة، فلا تحاول تصحيح المشكلة. أوقفها، واستعد النسخة الاحتياطية التي أخذتها قبل الترقية، ثم ابدأ من جديد. هذا هو السبب الكامل لتقديم النسخة الاحتياطية، وهو سبب فشل عادة الترقية الآن وأخذ نسخة احتياطية لاحقاً في مشروع حديث إلى هذا الحد.

ما لم يثبت هنا

كن صريحاً بشأن حداثة هذا البرنامج. الإصدار 0.1.3 صدر قبل أيام من وقت كتابة هذا النص، وملاحظات الإصدار الخاصة به ليست سوى روابط آلية إلى سجل التغييرات، وليست ملاحظات للترقية. ولا يوجد حتى الآن سجل عملي للترقيات. لا يوجد في هذا الدليل ما يثبت نتائج طويلة الأمد، لذلك تعامل مع نمو الذاكرة، وحجم قاعدة البيانات، وموثوقية جدولة المهام على أنها أمور يجب قياسها على خادمك، لا أموراً يمكنك افتراضها.

هناك سلوكان يستحقان الاختبار بنفسك قبل الاعتماد عليهما. أولاً، اختبر ما إذا كانت عملية الرجوع إلى إصدار أقدم تقرأ الحالة التي كتبها إصدار أحدث. نفّذ الاختبار على نسخة من volume عندما لا تكون النتيجة مهمة، وليس أثناء انقطاع الخدمة. ثانياً، اختبر ما يفعله gateway عندما تنتهي صلاحية تسجيل الدخول إلى Kiro بينما يحين موعد مهمة مجدولة. كلاهما من المشكلات الطرفية التي يعالجها مشروع حديث بهدوء بين الإصدارات، والتحقق منهما الآن لا يستغرق وقتاً أو جهداً كبيراً.

FAQ

لماذا لا تفتح لوحة KiroCrew عند استخدام عنوان IP العام لخادمي؟

لأن المثال المنشور يربط المنفذ بعنوان loopback. يربط -p 127.0.0.1:5476:5476 منفذ الحاوية بعنوان loopback الخاص بالمضيف فقط، وهذا مقصود. للوصول إليها، مرّر المنفذ عبر SSH باستخدام ssh -N -L 5476:127.0.0.1:5476 you@your-server، ثم افتح http://localhost:5476/?token=<token> على جهازك المحمول. تؤدي إزالة البادئة 127.0.0.1: لجعل الخدمة قابلة للوصول إلى وضع البوابة على الإنترنت العام. ولن تحتويها قاعدة جدار ناري، لأن قواعد DNAT الخاصة بالمنافذ المنشورة في Docker تُقيَّم قبل أن يرشّح ufw حركة الشبكة.

أين يخزّن KiroCrew بياناته، وما الذي يجب أن أنسخه احتياطياً؟

توجد جميع البيانات ضمن ~/.kiro/crew، وهو /home/kirocrew/.kiro/crew داخل صورة الحاوية، وينقلها KIROCREW_HOME إلى موقع آخر. انسخ الدليل بالكامل، أو وحدة Docker بالكامل، بعد إيقاف البوابة. إن memory.db وmemory_index.db قاعدتا بيانات SQLite، لذلك قد تكون النسخة المنسوخة أثناء كتابة البوابة غير متسقة. عند النقل إلى مضيف جديد، تنتقل workspace/memory/ وملفا قاعدة البيانات وconfig.json، بينما تنتمي ملفات PID وسجل الأحداث الأمنية و.env إلى المضيف القديم.

هل أستخدم الوسم stable أم وسم إصدار؟

استخدم وسم إصدار. يتغير stable كلما صدر إصدار جديد، لذلك قد يتغير الإصدار الذي تشغّله عند تنفيذ عملية pull التالية، كما أن الوسم نفسه لا يخبرك بما يعمل فعلياً. أما وسوم الإصدارات مثل 0.1.3 فهي ثابتة، وهذا ما يجعل التراجع إلى إصدار سابق ممكناً: تعيد الرقم القديم فتحصل على الصورة نفسها تماماً. حتى 6 August 2026، أحدث إصدار هو 0.1.3.

لماذا يرفض الوكيل تنفيذ أي أوامر؟

تتحقق الحاوية من دعم sandbox عند تشغيلها لأول مرة. إذا تعذر عليها عزل العمليات الفرعية للوكيل ولم يكن KIROCREW_ALLOW_UNSANDBOXED=1 مضبوطاً، فإنها ترفض تنفيذها بدلاً من تشغيلها دون عزل، ولذلك تبدو البوابة سليمة بينما تتوقف كل مهمة. يعرض docker logs kirocrew قرار sandbox الناتج عن التشغيل الأول. يؤدي ضبط المتغير إلى جعل الحاوية الحد الفاصل الوحيد بين الوكيل والمضيف. لذلك، إذا ضبطته، فلا تربط أي شيء لن تسلّمه إلى الوكيل مباشرة.

هل أحتاج إلى حساب Kiro لاستضافة KiroCrew ذاتياً؟

نعم، اعتباراً من August 2026. KiroCrew برنامج حر مرخّص بموجب Apache 2.0، لكنه يشغّل kiro-cli، الذي يتطلب تسجيل الدخول مرة واحدة، كما تُحتسب استدلالات الوكيل ضمن خطة Kiro. داخل الحاوية، شغّل docker exec -it kirocrew kiro-cli login ووافق على رمز الجهاز في متصفحك. إلى أن يكتمل تسجيل الدخول، تبدأ البوابة وتُحمَّل لوحة المعلومات، لكن لا يملك الوكيل نموذجاً يتصل به.