VPS پر KiroCrew self-host کریں، agent ہمیشہ آن رکھیں

لیپ ٹاپ کے بجائے VPS پر KiroCrew کو self-host کیوں کریں

KiroCrew کو self-host کرنے کا فائدہ صرف ایسی مشین پر ہوتا ہے جو کبھی sleep نہ ہو۔ اس لیے VPS اس کے لیے موزوں ہے، لیپ ٹاپ نہیں۔ KiroCrew session history، semantic memory، scheduled jobs اور approval queue کو disk پر محفوظ رکھتا ہے، اور process restart ہونے پر یہ تمام data دوبارہ load کرتا ہے۔ اگر scheduled job کے وقت 03:00 پر process چل ہی نہ رہا ہو تو اس میں سے کوئی چیز مدد نہیں کرتی، اور بند لیپ ٹاپ پر process نہیں چل رہا ہوتا۔

KiroCrew، Kiro team کا open source agent workspace ہے۔ یہ Apache 2.0 کے تحت licensed ہے، اور اس کے پہلے public releases August 2026 کے شروع میں جاری ہوئے۔ ایک process، جسے gateway کہا جاتا ہے، state کا مالک ہوتا ہے اور port 5476 پر web dashboard فراہم کرتا ہے۔ آپ dashboard، kirocrew CLI، یا Slack جیسے chat channel سے اس gateway تک پہنچتے ہیں۔ آپ صرف gateway کو self-host کرتے ہیں۔ اس لیے یہ guide اسے چلتا رکھنے، public internet سے دور رکھنے، اور کسی خراب upgrade کے بعد دوبارہ بحال کرنے کے طریقے پر مرکوز ہے۔

شروع کرنے سے پہلے دو باتیں جان لیں۔ KiroCrew، kiro-cli چلاتا ہے، جس کے لیے Kiro account سے ایک بار sign-in کرنا ضروری ہے۔ Agent inference کے اخراجات Kiro plan میں شامل ہوتے ہیں۔ اس لیے August 2026 تک یہ offline setup نہیں ہے۔ یہ project بھی ابھی صرف چند ہفتے پرانا ہے۔ فرض کریں کہ کسی مرحلے پر آپ کو rollback کرنا پڑے گا، اور اسے ایسے طریقے سے install کریں جس سے rollback ممکن ہو۔ اگر آپ نے پہلے کسی server پر agent نہیں چلایا تو VPS پر coding agent چلانا ان بنیادی اصولوں کی وضاحت کرتا ہے جن پر یہ guide قائم ہے۔

KiroCrew کو کیا درکار ہے، اور اس کی state کہاں محفوظ ہوتی ہے

Native install کے لیے Python 3.10 یا اس کے بعد کا ورژن درکار ہے، جبکہ project Python 3.12 کی تجویز دیتا ہے۔ اگر آپ dashboard کو source سے build کریں تو Node.js 18 یا اس کے بعد کا ورژن بھی چاہیے، اور kiro-cli درکار ہے، جسے پہلی بار launch کرنے پر یہ خود install کر کے آپ کے لیے sign in کر دیتا ہے۔ Container install کے لیے host پر ان میں سے کسی چیز کی ضرورت نہیں۔ صرف Docker درکار ہے۔ اسے ترجیح دینے کی بنیادی وجہ یہی ہے۔

State ~/.kiro/crew میں محفوظ ہوتی ہے، اور KIROCREW_HOME environment variable اسے کسی دوسری جگہ منتقل کرتا ہے۔ اس کے اندر یہ چیزیں موجود ہوتی ہیں:

• config.json: gateway settings اور chat channel credentials۔
• .env: secrets۔
• workspace/memory/: preferences، project notes اور chat history۔
• memory.db اور memory_index.db: semantic اور full-text indexes۔
• models/: embedding model، جو پہلی بار run ہونے پر download ہوتا ہے۔
• gateway.log اور security_events.jsonl: runtime log اور security event log۔

یہ directory ہی مکمل install ہے۔ اسے نئے VPS پر copy کریں تو آپ کا agent منتقل ہو جاتا ہے۔ اسی لیے ذیل کا backup section، install section سے زیادہ اہم ہے۔

RAM کے بجائے disk کے لیے منصوبہ بندی کریں۔ Gateway ایک Python process ہے؛ سرور پر اصل load agent کے چلائے ہوئے کام، build یا test suite سے آتا ہے۔ State directory chat history کے ساتھ بڑھتی ہے، اور embedding model پہلی بار start ہونے پر download ہوتا ہے۔ اس لیے کسی project کے پہلے مہینے میں شائع کیے گئے اعداد و شمار پر بھروسا کرنے کے بجائے، چند ہفتوں بعد اپنے سرور پر du -sh ~/.kiro/crew سے اس کا سائز ناپیں۔

تین installation paths میں سے کون سا استعمال کریں

پروجیکٹ تین paths فراہم کرتا ہے۔ One-line installer ایک wheel حاصل کرتا ہے اور kirocrew کو آپ کے PATH میں شامل کر دیتا ہے:

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

یہ channel flag اور version flag لیتا ہے:

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

Container image ghcr.io/kirodotdev/kirocrew پر شائع کی جاتی ہے، اور ہر tag کے تحت linux/amd64 اور linux/arm64 کے لیے دستیاب ہوتی ہے۔ Source build میں git clone اور make build شامل ہیں، اور یہ code میں تبدیلیاں کرنے والوں کے لیے ہے، اسے چلانے والوں کے لیے نہیں۔

Container استعمال کریں۔ Native install میں Python packages، Node اور kiro-cli اسی host پر install ہوتے ہیں جہاں آپ کی دیگر services چل رہی ہوتی ہیں۔ اس لیے upgrade ناکام ہو جائے تو آپ کو یہ تبدیلیاں دستی طور پر واپس درست کرنی پڑتی ہیں۔ Container runtime کو ایک image اور state کو ایک volume میں رکھتا ہے۔ اس طرح rollback کے لیے صرف tag تبدیل کرکے service restart کرنا کافی ہوتا ہے۔

تصویر کو release tag پر pin کریں، stable پر نہیں

پروجیکٹ کی اپنی مثال میں stable tag استعمال ہوتا ہے:

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

stable ایک moving tag ہے۔ یہ اس وقت دستیاب تازہ ترین stable release کی طرف اشارہ کرتا ہے۔ اس لیے اگلی pull آپ کی اجازت کے بغیر چلنے والا version تبدیل کر سکتی ہے، اور tag یہ نہیں بتاتا کہ وہ version کون سا تھا۔ Version tags immutable ہوتے ہیں، اس لیے ایک version tag کو pin کریں۔ 6 August 2026 تک تازہ ترین release 0.1.3 ہے، جو 5 August 2026 کو publish ہوئی تھی۔ nightly tag بھی موجود ہے۔ اتنے نئے پروجیکٹ میں اس کا مطلب ہے کہ code آج صبح تبدیل ہوا ہے۔

/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:

اسے start کریں، پھر health endpoint کو check کریں جسے image اپنے HEALTHCHECK کے لیے بھی استعمال کرتی ہے:

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

docker compose ps کو تقریباً ایک منٹ کے اندر container کو healthy رپورٹ کرنا چاہیے، اور /api/health token کے بغیر جواب دیتا ہے۔ /api/live اور /api/ready بھی اسی طرح جواب دیتے ہیں، اسی لیے انہیں probes کے طور پر استعمال کیا جا سکتا ہے۔ اگر state starting پر برقرار رہے تو کچھ تبدیل کرنے سے پہلے docker logs kirocrew پڑھیں۔ پہلی run میں embedding model download ہوتا ہے، اس لیے سست link کی وجہ سے پہلی start میں کافی وقت لگ سکتا ہے۔

systemd کے ساتھ اسے چلتا رکھیں

restart: unless-stopped crash کے بعد اور reboot کے بعد container کو دوبارہ شروع کرتا ہے، بشرطیکہ Docker خود boot کے وقت شروع ہو۔ unit file اس dependency کو واضح بناتی ہے اور ایک ایسی command فراہم کرتی ہے جو backup سے پہلے پورے stack کو روک دیتی ہے۔ boot کے وقت Docker Compose stack شروع کرنا میں عمومی طریقہ بیان کیا گیا ہے۔ 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) دکھائی دینا چاہیے، جو اس unit کے لیے درست صحت مند نتیجہ ہے۔ یہاں Type=oneshot کو RemainAfterExit=yes کے ساتھ استعمال کرنا درست ہے، کیونکہ container شروع ہوتے ہی docker compose up -d واپس آ جاتا ہے: systemd اس حقیقت کو track کر رہا ہے کہ stack چل رہا ہے، نہ کہ کسی foreground process کو۔ اس کے بجائے Type=simple لکھیں تو systemd command کے فوراً exit ہونے کو دیکھتا ہے، service کو dead قرار دیتا ہے، اور پھر آپ کی Restart= setting کے مطابق یا تو کوشش چھوڑ دیتا ہے یا restart loop میں چلا جاتا ہے۔ native install کے لیے project اپنا مساوی unit، kirocrew service install، فراہم کرتا ہے، جو /etc/systemd/system/kirocrew.service لکھتا ہے اور gateway کو آپ کے user کے طور پر چلاتا ہے۔ دونوں units کو ایک ساتھ نہ چلائیں۔ اس موضوع کی مزید تفصیل VPS پر systemd services اور timers میں ہے۔

پہلی بار چلانا: سائن ان کریں اور dashboard token حاصل کریں

Container gateway شروع کرتا ہے، لیکن agent runtime ابھی سائن ان نہیں ہوا۔ Container کے اندر سائن ان کریں:

docker exec -it kirocrew kiro-cli login

یہ device code اور ایک URL دکھاتا ہے۔ اس URL کو اپنے browser میں کھولیں۔ پھر dashboard token بنائیں:

docker exec kirocrew kirocrew token --ttl 2h

Dashboard URL http://localhost:5476/?token=<the token> ہے۔ Tokens کی میعاد ختم ہو جاتی ہے: sessions کی default مدت ایک گھنٹہ ہے، اور دستاویزی زیادہ سے زیادہ مدت بیس گھنٹے ہے۔ اگر dashboard خالی لوڈ ہو یا آپ کو فوراً واپس باہر بھیج دے تو عموماً token کی میعاد ختم ہو چکی ہوتی ہے۔ ایسی صورت میں نیا token بنائیں۔ Token کو کبھی ticket یا chat message میں paste نہ کریں، کیونکہ جس کے پاس یہ ہو، وہ آپ کے agent کو کنٹرول کر سکتا ہے۔

SSH کے ذریعے dashboard تک پہنچیں، اور port 5476 کو کبھی public نہ کریں

project کی مثال میں bind address دوبارہ دیکھیں: -p 127.0.0.1:5476:5476۔ container کے اندر gateway 0.0.0.0 پر listen کرتا ہے، کیونکہ port mapping کے ذریعے اس تک پہنچنا ضروری ہے، لیکن mapping خود host پر صرف loopback کے لیے publish ہوتی ہے۔ 127.0.0.1: prefix حذف کرنے سے gateway اس port کو scan کرنے والے ہر شخص کے لیے public internet پر دستیاب ہو جاتا ہے۔ firewall rule بھی آپ کو نہیں بچائے گا: Docker DNAT rules لکھ کر ports publish کرتا ہے، اور یہ rules ufw کی filtering سے پہلے evaluate ہوتے ہیں، اس لیے ufw deny 5476 published port پر کوئی اثر نہیں ڈالتا۔ ufw کو bypass کرنے والے Docker ports اس طریقۂ کار کی وضاحت کرتا ہے۔

اس port کو اپنے laptop سے SSH کے ذریعے forward کریں:

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

یہ command چلتی رہنے دیں اور مقامی طور پر http://localhost:5476/?token=<the token> کھولیں۔ ہر connection پر forward خودکار بنانے کے لیے اسے ~/.ssh/config میں شامل کریں:

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

اگر port 5476 آپ کے laptop پر پہلے سے استعمال ہو رہا ہو تو صرف بائیں طرف کا number تبدیل کریں: ssh -N -L 45476:127.0.0.1:5476 you@your-server.example.com، پھر http://localhost:45476/?token=... پر جائیں۔

Tunnel کے ذریعے ایک documented رویے کی توقع رکھیں: gateway forwarded requests کو remote سمجھتا ہے، اس لیے dashboard میں config-write اور secret-reveal endpoints انہیں مسترد کرتے ہیں۔ SSH کے ذریعے settings کی جو تبدیلی save نہیں ہوتی، یہ متوقع رویہ ہے، bug نہیں۔ اس کے بجائے host پر config edit کریں:

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

phone access کے لیے project Tailscale کے tailscale serve کی طرف رہنمائی کرتا ہے۔ اس سے dashboard public hostname کے بجائے آپ کے اپنے tailnet کے اندر رہتا ہے۔ اسے public reverse proxy پر ترجیح دیں۔ token URL میں شامل ہوتا ہے، اور اس path پر ہر access log میں URL لکھا جاتا ہے۔

ایجنٹ کو ممکنہ حد تک محدود اثر و رسوخ دیں

container پہلی بار start ہونے پر sandbox support کی جانچ کرتا ہے، اور نتیجہ طے کرتا ہے کہ agents کوئی کام execute کر سکتے ہیں یا نہیں۔ اگر namespace isolation دستیاب ہو تو agent subprocesses isolated ماحول میں چلتے ہیں۔ اگر یہ دستیاب نہ ہو اور KIROCREW_ALLOW_UNSANDBOXED=1 set نہ ہو تو execution کو unconfined حالت میں چلانے کے بجائے مسترد کر دیا جاتا ہے۔ اسی وجہ سے gateway بظاہر healthy رہتا ہے، لیکن ہر task عموماً رک جاتا ہے۔ یہ فیصلہ پہلی run کے نتائج میں docker logs kirocrew کے اندر محفوظ ہوتا ہے۔ project ایک seccomp (secure computing mode) profile بھی فراہم کرتا ہے، جسے آپ apply کر سکتے ہیں:

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 set کرتے ہیں تو واضح طور پر سمجھیں کہ کیا تبدیل ہوا ہے: اب agent اور آپ کے server کے درمیان واحد boundary container ہے۔ project کی warning مکمل طور پر دہرانا ضروری ہے۔ ایسے host paths mount نہ کریں جنہیں آپ agent کے حوالے براہِ راست نہیں کریں گے۔ عملی طور پر اس میں Docker socket، / کا کوئی bind mount، اور کسی دوسری service کا data رکھنے والی ہر directory شامل ہے۔

باقی اصول ہر اس agent پر لاگو ہوتے ہیں جسے commands run کرنے کی اجازت ہو۔ اس کی credentials کو صرف اسی ایک repository یا bucket تک محدود رکھیں جس کی اسے ضرورت ہے۔ account-wide rights رکھنے والا ذاتی token کبھی استعمال نہ کریں۔ اسے ایک dedicated user کے طور پر چلائیں، جس کے home میں کوئی دوسری چیز موجود نہ ہو۔ اسی مقصد کے لیے VPS پر کم سے کم مراعات والے users استعمال کیے جاتے ہیں۔ جب agent code لکھ کر وہی code run کرتا ہے تو اسے ایسی machine دیں جسے خراب کرنے کی اجازت ہو: coding agents کے لیے disposable VM اس compose file کے کسی بھی flag سے زیادہ مضبوط boundary ہے، کیونکہ آپ اسے صاف کرنے کے بجائے delete کر دیتے ہیں۔ یہی اصول VPS پر OpenClaw کو محفوظ طریقے سے چلانے اور VPS پر Hermes agent کی self-hosting پر بھی لاگو ہوتا ہے۔ tools بھی blast radius کا حصہ ہیں: agent کو web search دینے سے fetch کیا جانے والا ہر page untrusted input بن جاتا ہے۔ اس لیے اپنے SearXNG instance کی طرف اسے point کرنا صرف plumbing کا فیصلہ نہیں، بلکہ prompt injection سے متعلق فیصلہ بھی ہے۔ Scheduled work آپ کے سوتے وقت بھی رقم خرچ کرتا ہے، کیونکہ inference کی لاگت آپ کے Kiro plan میں شامل ہوتی ہے۔ اس لیے nightly job شامل کرنے سے پہلے VPS پر AI agent کی لاگت کو کنٹرول کرنا میں بیان کردہ limits set کریں۔

ہر upgrade سے پہلے state volume کا backup لیں

پہلے volume کا اصل نام معلوم کریں۔ Compose، named volumes کے نام کے شروع میں project name شامل کرتا ہے۔ یہ نام پہلے سے طے نہ ہو تو directory name استعمال ہوتا ہے۔ اس لیے /opt/kirocrew/compose.yaml میں kirocrew-home کے طور پر declare کیا گیا volume، kirocrew_kirocrew-home کے نام سے create ہوتا ہے:

docker volume ls

کسی بھی چیز کو copy کرنے سے پہلے gateway کو stop کریں۔ memory.db اور memory_index.db SQLite databases ہیں۔ Database کے لکھے جانے کے دوران copy کرنے سے transaction کا نامکمل حصہ محفوظ ہو سکتا ہے، اور restore کے بعد file corrupt ہو سکتی ہے۔ Project کی migration instructions میں بھی یہی ہدایت ہے: memory کو صرف اس وقت منتقل کریں جب gateways stopped ہوں۔

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

Archive کو اس server سے باہر copy کریں۔ Restore کے لیے یہی command استعمال کریں، مگر container stopped ہو اور tar czf کی جگہ tar xzf موجود ہو:

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

نئے host پر منتقل ہونا، اسی host پر restore کرنے سے مختلف کام ہے۔ Project کی ہدایات اس بارے میں واضح ہیں۔ workspace/memory/ کے اندر chat history اور project notes منتقل ہو جاتے ہیں، اور دونوں database files اور config.json بھی منتقل ہوتے ہیں۔ PID files، security event log اور .env پرانے host سے وابستہ ہوتے ہیں۔ انہیں منتقل نہ کریں، اور نئے host پر secrets دوبارہ درج کریں۔

خراب upgrade کو واپس کیسے roll back کریں

Upgrade کا عمل مختصر ہے، اور یہ صرف اس لیے محفوظ ہے کہ آپ نے version pin کیا ہوا ہے۔ پہلے backup لیں، پھر tag تبدیل کریں:

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 image کو pull کرتا ہے اگر وہ پہلے سے box پر موجود نہ ہو، اس لیے tag میں ترمیم ہی مکمل upgrade ہے۔ Rollback بھی اسی ترتیب سے کیا جاتا ہے، لیکن پرانا number استعمال ہوتا ہے۔ اس سے آپ کو وہی exact image ملتی ہے جو پہلے موجود تھی، کیونکہ version tags immutable ہوتے ہیں۔

Binary صاف طور پر roll back ہو جاتی ہے۔ مسئلہ state میں پیدا ہو سکتا ہے۔ نیا gateway config.json کو دوبارہ لکھ سکتا ہے یا memory databases کو ایسی شکل میں migrate کر سکتا ہے جسے پرانا gateway پڑھ نہ سکے، اور August 2026 تک downgrade path دستاویزی طور پر موجود نہیں ہے۔ اس لیے اگر پرانی image start ہو کر غیر معمولی رویہ دکھائے تو اس کی debugging نہ کریں۔ اسے stop کریں، upgrade سے پہلے لیا گیا backup restore کریں، اور دوبارہ start کریں۔ backup پہلے لینے کی پوری وجہ یہی ہے۔ اسی لیے اس قدر نئے project میں پہلے upgrade کرنا اور بعد میں backup لینا ناکام طریقہ ہے۔

یہاں کیا ثابت نہیں ہوتا

اس software کی عمر کے بارے میں دیانت دار رہیں۔ تحریر کے وقت Version 0.1.3 کو جاری ہوئے صرف چند دن ہوئے ہیں، اس کے release notes migration notes کے بجائے خودکار changelog links ہیں، اور ابھی upgrades کا کوئی سابقہ ریکارڈ موجود نہیں۔ اس guide میں شامل کوئی بھی بات طویل مدت کے نتائج پر مبنی نہیں۔ اس لیے memory growth، database size اور scheduler reliability کو اپنے server پر ناپنے والی چیزیں سمجھیں، پہلے سے فرض کرنے والی نہیں۔

دو رویوں کو کسی اہم انحصار سے پہلے خود آزمانا ضروری ہے۔ اول، یہ جانچیں کہ کیا downgrade کسی newer version کے لکھے ہوئے state کو پڑھتا ہے۔ یہ آزمائش volume کی copy پر اس وقت کریں جب ناکامی کا کوئی نقصان نہ ہو، outage کے دوران نہیں۔ دوم، یہ معلوم کریں کہ scheduled job کے وقت Kiro sign-in expire ہونے پر gateway کیا کرتا ہے۔ نئے project میں ایسی دونوں rough edges releases کے درمیان خاموشی سے درست ہو سکتی ہیں، اور ابھی ان کی جانچ کرنا آسان ہے۔

FAQ

KiroCrew dashboard میرے سرور کے public IP پر کیوں نہیں کھلتا؟

کیونکہ شائع کردہ مثال port کو loopback سے bind کرتی ہے۔ -p 127.0.0.1:5476:5476 container کے port کو صرف host کے loopback address سے map کرتا ہے، اور یہ دانستہ ہے۔ ssh -N -L 5476:127.0.0.1:5476 you@your-server کے ذریعے SSH پر port forward کریں، پھر اپنے laptop پر http://localhost:5476/?token=<token> کھولیں۔ اسے reachable بنانے کے لیے 127.0.0.1: prefix ہٹانے سے gateway public internet پر آ جاتا ہے۔ Firewall rule اسے محدود نہیں کر سکے گا، کیونکہ Docker کے published-port DNAT rules، ufw کے traffic filters سے پہلے evaluate ہوتے ہیں۔

KiroCrew اپنا data کہاں محفوظ کرتا ہے، اور مجھے کس چیز کا backup لینا چاہیے؟

تمام data ~/.kiro/crew کے تحت ہوتا ہے، جو container image کے اندر /home/kirocrew/.kiro/crew ہے، اور KIROCREW_HOME اسے دوسری جگہ منتقل کرتا ہے۔ Gateway بند ہونے کی حالت میں پوری directory یا پورے Docker volume کا backup لیں۔ memory.db اور memory_index.db SQLite databases ہیں، اس لیے gateway کے لکھنے کے دوران بنائی گئی copy inconsistent ہو سکتی ہے۔ نئے host پر منتقل کرتے وقت workspace/memory/، دونوں database files اور config.json منتقل کریں۔ PID files، security event log اور .env پرانے host سے متعلق ہوتے ہیں۔

کیا مجھے stable tag استعمال کرنا چاہیے یا version tag؟

Version tag استعمال کریں۔ stable ہر release کے جاری ہونے پر تبدیل ہو جاتا ہے، اس لیے اگلی pull کے بعد آپ کے زیرِ استعمال version میں غیر متوقع تبدیلی آ سکتی ہے، اور tag خود یہ نہیں بتاتا کہ کیا چل رہا ہے۔ 0.1.3 جیسے version tags immutable ہوتے ہیں۔ یہی چیز rollback کو قابلِ اعتماد بناتی ہے: پرانا number دوبارہ درج کریں اور وہی identical image حاصل کریں۔ 6 August 2026 تک newest release 0.1.3 ہے۔

میرا agent کوئی بھی command چلانے سے کیوں انکار کرتا ہے؟

Container پہلی بار start ہونے پر sandbox support کی جانچ کرتا ہے۔ اگر یہ agent subprocesses کو isolate نہ کر سکے اور KIROCREW_ALLOW_UNSANDBOXED=1 set نہ ہو، تو container انہیں unconfined چلانے کے بجائے execute کرنے سے انکار کر دیتا ہے۔ اس صورت میں gateway healthy دکھائی دیتا ہے، لیکن ہر task رک جاتا ہے۔ docker logs kirocrew پہلی run کا sandbox فیصلہ دکھاتا ہے۔ یہ variable set کرنے سے agent اور host کے درمیان صرف container boundary رہ جاتی ہے۔ اس لیے اگر آپ اسے set کریں تو ایسی کوئی چیز mount نہ کریں جو آپ agent کو براہِ راست دینے کے لیے تیار نہ ہوں۔

کیا KiroCrew کو self-host کرنے کے لیے Kiro account ضروری ہے؟

ہاں، August 2026 تک ضروری ہے۔ KiroCrew Apache 2.0 کے تحت free software ہے، لیکن یہ kiro-cli کو چلاتا ہے، جس کے لیے one-time sign-in درکار ہے، اور agent inference کی billing Kiro plan پر ہوتی ہے۔ Container میں docker exec -it kirocrew kiro-cli login چلائیں اور اپنے browser میں device code approve کریں۔ Sign-in مکمل ہونے تک gateway start ہو جاتا ہے اور dashboard load ہو جاتا ہے، لیکن agent کے پاس رابطہ کرنے کے لیے کوئی model نہیں ہوتا۔