लेखक: Matt Connor 2026-08-06 · अपडेट किया गया: 2026-08-07

KiroCrew को VPS पर कैसे host करें: पूरी गाइड

Q: मेरे सर्वर के public IP पर KiroCrew dashboard क्यों नहीं खुल रहा है?

क्योंकि प्रकाशित उदाहरण 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 के साथ port को SSH के माध्यम से forward करें, और फिर अपने laptop पर http://localhost:5476/?token= खोलें। इसे public internet पर उपलब्ध कराने के लिए 127.0.0.1: prefix को हटाने से gateway public हो जाएगा, और firewall rule इसे रोक नहीं पाएगा, क्योंकि Docker के published-port DNAT rules, ufw द्वारा traffic filter करने से पहले ही लागू हो जाते हैं।

Q: KiroCrew अपना डेटा कहाँ store करता है, और मुझे किसका backup लेना चाहिए?

सब कुछ ~/.kiro/crew के अंतर्गत स्थित है, जो container image के भीतर /home/kirocrew/.kiro/crew है, और KIROCREW_HOME इसे relocate करता है। gateway को रोककर पूरी directory, या पूरे Docker volume का backup लें। memory.db और memory_index.db SQLite databases हैं, इसलिए gateway के लिखते समय ली गई copy असंगत (inconsistent) हो सकती है। नए host पर move करते समय, workspace/memory/, दोनों database files और config.json को साथ ले जाएँ, जबकि PID files, security event log और .env पुराने host के लिए ही होते हैं।

Q: क्या मुझे stable tag का उपयोग करना चाहिए या version tag का?

Version tag का उपयोग करें। stable हर बार बदलता है जब कोई नया software release होता है, इसलिए अगली बार pull करने पर आपके द्वारा चलाया जा रहा version बदल सकता है, और tag स्वयं यह नहीं बताता कि क्या चल रहा है। 0.1.3 जैसे version tags immutable होते हैं, और यही rollback को काम करने योग्य बनाता है: आप पुराना number वापस डालते हैं और आपको वही image मिल जाती है। 6 August 2026 तक का नवीनतम release 0.1.3 है।

KiroCrew को VPS पर Docker के साथ host करने का तरीका जानें। यह गाइड systemd, SSH एक्सेस और बैकअप के जरिए आपके एजेंट को 24/7 चालू रखने और डेटा सुरक्षित रखने में मदद करेगी।

KiroCrew को लैपटॉप के बजाय VPS पर self-host क्यों करें

KiroCrew को self-host करने का लाभ केवल ऐसी मशीन पर मिलता है जो कभी बंद न हो, इसलिए इसके लिए VPS सही जगह है, लैपटॉप नहीं। KiroCrew session history, semantic memory, scheduled jobs और approval queue को disk पर रखता है, और process restart होने पर यह सब फिर से load हो जाता है। यदि 03:00 बजे कोई scheduled job चलनी हो और process न चल रहा हो, तो इसका कोई लाभ नहीं है, और बंद लैपटॉप पर यह नहीं चल सकता।

KiroCrew, Kiro टीम का एक open source agent workspace है, जो Apache 2.0 license के तहत उपलब्ध है, और इसके पहले public releases अगस्त 2026 की शुरुआत में आए हैं। gateway नामक एक process state को नियंत्रित करता है और port 5476 पर web dashboard प्रदान करता है। आप उस gateway तक dashboard से, kirocrew CLI से, या Slack जैसे chat channel से पहुँच सकते हैं। gateway ही वह एकमात्र चीज़ है जिसे आप self-host कर रहे हैं, इसलिए यह guide उसे चालू रखने, उसे public internet से दूर रखने, और खराब upgrade के बाद उसे फिर से ठीक करने के बारे में है।

शुरू करने से पहले दो बातें जान लें। KiroCrew kiro-cli को संचालित करता है, जिसके लिए Kiro account के साथ एक बार sign-in की आवश्यकता होती है, और agent inference का billing Kiro plan के माध्यम से होता है, इसलिए अगस्त 2026 तक यह offline setup नहीं है। यह project अभी कुछ ही सप्ताह पुराना है। यह मानकर चलें कि आपको किसी बिंदु पर rollback करने की आवश्यकता होगी, और इसे ऐसे install करें कि आप ऐसा कर सकें। यदि आपने पहले कभी server पर agent नहीं चलाया है, तो running a coding agent on a VPS उन बुनियादी नियमों को कवर करता है जिन पर यह guide आधारित है।

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 के साथ अपने स्वयं के बॉक्स पर इसे मापें।

आपको तीन install paths में से किसका उपयोग करना चाहिए

यह प्रोजेक्ट तीन विकल्प प्रकाशित करता है। one-line installer एक wheel fetch करता है और उसे आपके PATH पर kirocrew में डाल देता है:

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 का संयोजन है, और यह उन लोगों के लिए है जो कोड में बदलाव कर रहे हैं, न कि उन लोगों के लिए जो इसे चला रहे हैं।

Container का उपयोग करें। एक native install आपके अन्य services चलाने वाले host पर ही Python packages, Node और kiro-cli को डाल देता है, इसलिए यदि कोई upgrade गलत हो जाए, तो आपको उसे मैन्युअल रूप से ठीक करना पड़ेगा। Container runtime को एक image में और state को एक volume में रखता है, जिससे rollback केवल एक tag बदलना और restart करना रह जाता है।

इमेज को एक release tag पर पिन करें, न कि `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 होते हैं, इसलिए एक को पिन करें। 6 August 2026 तक का सबसे नया release 0.1.3 है, जिसे 5 August 2026 को प्रकाशित किया गया था। एक nightly tag भी है, जिसका अर्थ इस नए प्रोजेक्ट पर यह है कि कोड में आज सुबह ही बदलाव हुआ है।

/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 की जाँच करें जिसका उपयोग इमेज अपने स्वयं के 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 के रूप में उपयोग करने योग्य बनाता है)। यदि स्थिति starting पर बनी रहती है, तो कुछ भी बदलने से पहले docker logs kirocrew पढ़ें। पहली बार चलाने पर embedding model डाउनलोड होता है, इसलिए धीमे link के कारण पहली बार start होने में अधिक समय लग सकता है।

systemd के साथ इसे चालू रखना

restart: unless-stopped क्रैश या रीबूट के बाद कंटेनर को वापस ले आता है, बशर्ते Docker स्वयं बूट पर शुरू हो। एक unit file इस निर्भरता को स्पष्ट करती है और आपको एक ही कमांड देती है जो बैकअप से पहले पूरे स्टैक को रोक देती है। बूट पर 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 इस तथ्य को ट्रैक कर रहा है कि स्टैक चालू है, न कि किसी foreground प्रक्रिया को। इसके बजाय Type=simple लिखें और systemd कमांड को तुरंत exit होते हुए देखेगा, सर्विस को dead मार्क करेगा, और फिर आपकी Restart= सेटिंग के आधार पर या तो प्रयास छोड़ देगा या restart-loop में चला जाएगा। नेटिव इंस्टॉलेशन के लिए प्रोजेक्ट अपना समकक्ष kirocrew service install प्रदान करता है, जो /etc/systemd/system/kirocrew.service लिखता है और गेटवे को आपके यूजर के रूप में चलाता है। दोनों यूनिट्स को एक साथ न चलाएं। इस विषय का विस्तृत संस्करण VPS पर systemd सर्विसेज और टाइमर्स में है।

पहली बार चलाना: साइन इन करें और डैशबोर्ड टोकन प्राप्त करें

कंटेनर गेटवे को स्टार्ट करता है, लेकिन एजेंट रनटाइम अभी तक साइन इन नहीं है। कंटेनर के अंदर साइन इन करें:

docker exec -it kirocrew kiro-cli login

यह एक डिवाइस कोड और एक URL प्रिंट करेगा जिसे आप अपने ब्राउज़र में खोलें। इसके बाद एक डैशबोर्ड टोकन जनरेट करें:

docker exec kirocrew kirocrew token --ttl 2h

डैशबोर्ड URL http://localhost:5476/?token=<the token> है। टोकन की समय-सीमा समाप्त हो जाती है: सत्र डिफ़ॉल्ट रूप से एक घंटे के होते हैं और प्रलेखित अधिकतम सीमा बीस घंटे है। यदि डैशबोर्ड खाली लोड होता है या आपको सीधे बाहर कर देता है, तो आमतौर पर इसका मतलब है कि टोकन समाप्त हो गया है, इसलिए दूसरा टोकन जनरेट करें। किसी टोकन को कभी भी टिकट या चैट संदेश में पेस्ट न करें, क्योंकि जिसके पास यह टोकन है, उसके पास आपके एजेंट का नियंत्रण है।

SSH के माध्यम से डैशबोर्ड तक पहुँचें और port 5476 को कभी भी सार्वजनिक न करें

प्रोजेक्ट के उदाहरण में bind address को फिर से देखें: -p 127.0.0.1:5476:5476। कंटेनर के अंदर gateway 0.0.0.0 पर listen करता है, क्योंकि इसे port mapping के माध्यम से पहुँच योग्य होना चाहिए, लेकिन mapping स्वयं host पर केवल loopback के लिए publish करती है। यदि आप 127.0.0.1: prefix को हटा देते हैं, तो gateway सार्वजनिक इंटरनेट पर किसी भी ऐसे व्यक्ति के लिए उपलब्ध हो जाएगा जो उस port को स्कैन करता है। firewall rule भी आपको नहीं बचा पाएगा: Docker ports को DNAT rules लिखकर publish करता है, जिनका मूल्यांकन ufw की filtering से पहले किया जाता है, इसलिए ufw deny 5476 का किसी published port पर कोई प्रभाव नहीं पड़ता है। Docker ports bypassing ufw इस प्रक्रिया को विस्तार से समझाता है।

इसके बजाय अपने लैपटॉप से SSH के माध्यम से port को forward करें:

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

इसे चलते रहने दें और स्थानीय रूप से http://localhost:5476/?token=<the token> खोलें। हर कनेक्शन पर इस forward को स्वचालित बनाने के लिए, इसे ~/.ssh/config में डालें:

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

यदि आपके लैपटॉप पर port 5476 पहले से ही उपयोग में है, तो केवल बाईं ओर की संख्या बदलें: ssh -N -L 45476:127.0.0.1:5476 you@your-server.example.com, फिर http://localhost:45476/?token=... पर ब्राउज़ करें।

tunnel के माध्यम से एक अपेक्षित व्यवहार यह है: gateway forward किए गए अनुरोधों को remote मानता है, इसलिए डैशबोर्ड में config-write और secret-reveal endpoints उन्हें अस्वीकार कर देते हैं। SSH पर जो settings change save नहीं होती है, वह इसी कारण से है, यह कोई बग नहीं है। इसके बजाय 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

फोन से एक्सेस के लिए प्रोजेक्ट Tailscale के tailscale serve का सुझाव देता है, जो डैशबोर्ड को सार्वजनिक hostname के बजाय आपके अपने tailnet के भीतर रखता है। सार्वजनिक reverse proxy की तुलना में इसे प्राथमिकता दें। token URL में यात्रा करता है, और URL उसके रास्ते में आने वाले प्रत्येक access log में लिखा जाता है।

एजेंट को न्यूनतम संभव ब्लास्ट रेडियस दें

कंटेनर पहली बार स्टार्ट होने पर सैंडबॉक्स सपोर्ट की जाँच करता है, और परिणाम यह तय करता है कि एजेंट कुछ भी निष्पादित कर सकते हैं या नहीं। यदि namespace isolation उपलब्ध है, तो एजेंट के सब-प्रोसेस आइसोलेटेड होकर चलते हैं। यदि यह उपलब्ध नहीं है और KIROCREW_ALLOW_UNSANDBOXED=1 सेट नहीं है, तो अनकन्फाइंड (unconfined) तरीके से चलाने के बजाय निष्पादन (execution) को अस्वीकार कर दिया जाता है। इसलिए, यदि कोई गेटवे स्वस्थ दिखता है लेकिन सभी टास्क रुक जाते हैं, तो आमतौर पर यही कारण होता है। यह निर्णय उस पहले रन से docker logs kirocrew में दर्ज होता है। प्रोजेक्ट एक seccomp (secure computing mode) प्रोफाइल भी प्रकाशित करता है जिसे आप लागू कर सकते हैं:

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, / का कोई भी बाइंड माउंट, और किसी अन्य सर्विस का डेटा रखने वाली कोई भी डायरेक्टरी इसमें शामिल नहीं होनी चाहिए।

बाकी वह फ्रेमवर्क है जो कमांड चलाने की अनुमति वाले प्रत्येक एजेंट पर लागू होता है। इसके क्रेडेंशियल्स को केवल उस एक रिपॉजिटरी या बकेट तक सीमित रखें जिसकी उसे आवश्यकता है, कभी भी ऐसे पर्सनल टोकन का उपयोग न करें जिसमें अकाउंट-व्यापी अधिकार हों। इसे एक समर्पित यूजर के रूप में चलाएं जिसके होम डायरेक्टरी में कुछ और न हो, जिसके लिए VPS पर न्यूनतम विशेषाधिकार वाले यूजर्स का उपयोग किया जाता है। जब एजेंट कोड लिखता है और फिर उस कोड को चलाता है, तो उसे ऐसी मशीन दें जिसे तोड़ने की उसे अनुमति हो: कोडिंग एजेंटों के लिए एक डिस्पोजेबल VM इस compose फाइल के किसी भी फ्लैग की तुलना में एक मजबूत सीमा है, क्योंकि आप इसे साफ करने के बजाय डिलीट कर देते हैं। यही तर्क VPS पर सुरक्षित रूप से OpenClaw चलाना और VPS पर Hermes एजेंट को सेल्फ-होस्ट करना को आकार देता है। निर्धारित कार्य आपके सोते समय भी पैसे खर्च करते हैं, क्योंकि इन्फरेंस आपके Kiro प्लान में बिल होता है, इसलिए कोई भी nightly जॉब जोड़ने से पहले VPS पर AI एजेंट की लागत को नियंत्रित करना में वर्णित सीमाएं सेट करें।

हर अपग्रेड से पहले state volume का बैकअप लें

सबसे पहले वास्तविक volume नाम ढूँढें। Compose project नाम के साथ volumes को prefix करता है, जो डिफ़ॉल्ट रूप से डायरेक्टरी का नाम होता है, इसलिए /opt/kirocrew/compose.yaml में kirocrew-home के रूप में घोषित volume को kirocrew_kirocrew-home के रूप में बनाया जाता है:

docker volume ls

कुछ भी कॉपी करने से पहले gateway को रोकें। memory.db और memory_index.db SQLite डेटाबेस हैं, और लिखते समय डेटाबेस को कॉपी करने से एक अधूरा ट्रांजेक्शन कैप्चर हो सकता है, जो रिस्टोर करने पर एक करप्ट फ़ाइल बन जाता है। प्रोजेक्ट के अपने माइग्रेशन निर्देश भी यही कहते हैं: मेमोरी को केवल तभी मूव करें जब gateways बंद हों।

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

एक नए होस्ट पर जाना, उसी स्थान पर रिस्टोर करने से एक अलग कार्य है, और प्रोजेक्ट इस बारे में स्पष्ट है। workspace/memory/ के अंतर्गत चैट हिस्ट्री और प्रोजेक्ट नोट्स ट्रांसफर हो जाते हैं, और साथ ही दो डेटाबेस फ़ाइलें और config.json भी। PID फ़ाइलें, सिक्योरिटी इवेंट लॉग और .env पुराने होस्ट से जुड़े होते हैं, इसलिए उन्हें वहीं छोड़ दें और नए बॉक्स पर secrets को फिर से दर्ज करें।

खराब अपग्रेड को रोल बैक कैसे करें

अपग्रेड की प्रक्रिया संक्षिप्त है, और यह केवल इसलिए सुरक्षित है क्योंकि आपने एक version को पिन किया है। पहले बैकअप लें, फिर 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 को box पर न होने पर pull करता है, इसलिए tag में बदलाव ही पूरा अपग्रेड है। रोल बैक करना पुराने number के साथ वही क्रम है, और यह आपको वही सटीक image देता है जो आपके पास पहले थी, क्योंकि version tags अपरिवर्तनीय (immutable) होते हैं।

binary साफ-सुथरे तरीके से रोल बैक हो जाती है। state वह हिस्सा है जो शायद न हो। एक नया gateway config.json को फिर से लिख सकता है या memory databases को ऐसे आकार में migrate कर सकता है जिसे पुराना gateway नहीं पढ़ पाता, और August 2026 तक कोई भी डाउनग्रेड पाथ प्रलेखित (documented) नहीं है। इसलिए यदि पुरानी image start होती है और फिर अजीब व्यवहार करती है, तो उसे debug न करें। उसे रोकें, अपग्रेड से पहले लिए गए बैकअप को restore करें, और फिर से शुरू करें। यही एकमात्र कारण है कि बैकअप पहले लिया जाता है, और यही कारण है कि अभी अपग्रेड करने और बाद में बैकअप लेने की आदत इस तरह के नए प्रोजेक्ट पर विफल हो जाती है।

यहाँ क्या प्रमाणित नहीं है

इस सॉफ़्टवेयर की आयु के बारे में ईमानदार रहें। लेखन के समय version 0.1.3 केवल कुछ दिन पुराना है, इसके release notes माइग्रेशन नोट्स के बजाय स्वचालित changelog लिंक हैं, और अभी तक अपग्रेड का कोई पिछला रिकॉर्ड उपलब्ध नहीं है। इस गाइड में कुछ भी दीर्घकालिक परिणाम नहीं है, इसलिए memory growth, database size और scheduler reliability को ऐसी चीज़ें मानें जिन्हें आपको अपने सर्वर पर स्वयं मापना है, न कि ऐसी चीज़ें जिन्हें मान लिया जाए।

दो व्यवहार ऐसे हैं जिन्हें आप पर निर्भर होने से पहले स्वयं टेस्ट करना उचित है। पहला, क्या downgrade करने पर नई version द्वारा लिखा गया state पढ़ा जा सकता है: इसे volume की एक copy पर तब आज़माएँ जब यह महत्वपूर्ण न हो, न कि outage के दौरान। दूसरा, जब scheduled job का समय हो और Kiro sign-in समाप्त हो जाए, तो gateway क्या करता है। ये दोनों ही ऐसी कमियाँ हैं जिन्हें एक नया प्रोजेक्ट releases के बीच चुपचाप ठीक कर देता है, और इन दोनों की जाँच अभी करना आसान है।

FAQ

मेरे सर्वर के public IP पर KiroCrew dashboard क्यों नहीं खुल रहा है?

क्योंकि प्रकाशित उदाहरण 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 के साथ port को SSH के माध्यम से forward करें, और फिर अपने laptop पर http://localhost:5476/?token=<token> खोलें। इसे public internet पर उपलब्ध कराने के लिए 127.0.0.1: prefix को हटाने से gateway public हो जाएगा, और firewall rule इसे रोक नहीं पाएगा, क्योंकि Docker के published-port DNAT rules, ufw द्वारा traffic filter करने से पहले ही लागू हो जाते हैं।

KiroCrew अपना डेटा कहाँ store करता है, और मुझे किसका backup लेना चाहिए?

सब कुछ ~/.kiro/crew के अंतर्गत स्थित है, जो container image के भीतर /home/kirocrew/.kiro/crew है, और KIROCREW_HOME इसे relocate करता है। gateway को रोककर पूरी directory, या पूरे Docker volume का backup लें। memory.db और memory_index.db SQLite databases हैं, इसलिए gateway के लिखते समय ली गई copy असंगत (inconsistent) हो सकती है। नए host पर move करते समय, workspace/memory/, दोनों database files और config.json को साथ ले जाएँ, जबकि PID files, security event log और .env पुराने host के लिए ही होते हैं।

क्या मुझे `stable` tag का उपयोग करना चाहिए या version tag का?

Version tag का उपयोग करें। stable हर बार बदलता है जब कोई नया software release होता है, इसलिए अगली बार pull करने पर आपके द्वारा चलाया जा रहा version बदल सकता है, और tag स्वयं यह नहीं बताता कि क्या चल रहा है। 0.1.3 जैसे version tags immutable होते हैं, और यही rollback को काम करने योग्य बनाता है: आप पुराना number वापस डालते हैं और आपको वही image मिल जाती है। 6 August 2026 तक का नवीनतम release 0.1.3 है।

मेरा agent कोई भी command चलाने से मना क्यों कर रहा है?

Container अपनी पहली start पर sandbox support की जाँच करता है। यदि यह agent subprocesses को isolate नहीं कर पाता है और KIROCREW_ALLOW_UNSANDBOXED=1 set नहीं है, तो यह उन्हें unconfined चलाने के बजाय execute करने से मना कर देता है, जिससे gateway स्वस्थ दिखता है जबकि हर task रुक जाता है। docker logs kirocrew उस पहली run से sandbox निर्णय दिखाता है। इस variable को set करने से container, agent और host के बीच एकमात्र boundary बन जाता है, इसलिए यदि आप इसे set करते हैं, तो ऐसी कोई भी चीज़ mount न करें जिसे आप सीधे agent को नहीं देना चाहेंगे।

क्या KiroCrew को self-host करने के लिए मुझे Kiro account की आवश्यकता है?

हाँ, August 2026 तक। KiroCrew Apache 2.0 के अंतर्गत free software है, लेकिन यह kiro-cli को संचालित करता है, जिसके लिए एक बार 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 नहीं होता।

#kirocrew#ai-agents #Docker #systemd #सेल्फ़-होस्टिंग