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

VPS पर KiroCrew को self-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 internet पर आ जाएगा, और firewall rule इसे रोक नहीं पाएगा, क्योंकि Docker के published-port DNAT rules, ufw द्वारा traffic filter करने से पहले ही evaluate हो जाते हैं।

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

सब कुछ ~/.kiro/crew के अंतर्गत स्थित है, जो container image के भीतर /home/kirocrew/.kiro/crew है, और KIROCREW_HOME इसे relocate करता है। gateway को stop करके पूरी directory, या पूरे Docker volume का backup लें। memory.db और memory_index.db SQLite databases हैं, इसलिए gateway के लिखते समय ली गई copy असंगत (inconsistent) हो सकती है। नए host पर migrate करते समय, 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 है।

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

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

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

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

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

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 के AI सहकर्मियों को सेल्फ-होस्ट करना साइजिंग को डिस्क से पहले 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 को उसी होस्ट पर डाल देता है जो आपकी अन्य सेवाओं को चलाता है, इसलिए यदि कोई अपग्रेड गलत हो जाता है, तो आपको उसे मैन्युअल रूप से ठीक करना पड़ेगा। कंटेनर रनटाइम को एक इमेज में और स्टेट को एक वॉल्यूम में रखता है, जिससे रोलबैक करना केवल एक टैग बदलना और रीस्टार्ट करना रह जाता है।

इमेज को एक 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 इस निर्भरता (dependency) को स्पष्ट करती है और आपको एक ही कमांड देती है जो बैकअप से पहले पूरे स्टैक को रोक देती है। बूट पर 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) पढ़ना चाहिए, जो इस यूनिट के लिए सही परिणाम है। RemainAfterExit=yes के साथ Type=oneshot यहाँ इसलिए है क्योंकि कंटेनर शुरू होते ही docker compose up -d वापस आ जाता है: systemd इस तथ्य को ट्रैक कर रहा है कि स्टैक चालू है, न कि किसी फोरग्राउंड प्रोसेस को। इसके बजाय Type=simple लिखें और systemd कमांड को तुरंत समाप्त होते हुए देखेगा, सर्विस को मृत (dead) चिह्नित करेगा, और फिर आपकी Restart= सेटिंग के आधार पर या तो प्रयास छोड़ देगा या रीस्टार्ट-लूप में चला जाएगा। नेटिव इंस्टॉलेशन के लिए प्रोजेक्ट अपना समकक्ष kirocrew service install प्रदान करता है, जो /etc/systemd/system/kirocrew.service लिखता है और गेटवे को आपके यूजर के रूप में चलाता है। दोनों यूनिट्स को एक साथ न चलाएं। इस विषय का विस्तृत संस्करण VPS पर systemd सर्विसेज और टाइमर्स में है। जो यूनिट वापस आने में विफल रहती है वह तब तक शांत रहती है जब तक आप उसे सूचित करने के लिए न कहें, इसलिए एक OnFailure= हैंडलर जोड़ें जो आपके अपने ntfy सर्वर पर अलर्ट भेजता है और आपको अपने फोन पर पता चल जाएगा कि गेटवे डाउन है, बजाय इसके कि किसी शेड्यूल किए गए जॉब के विफल होने पर पता चले जो कभी चला ही नहीं।

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

कंटेनर gateway को शुरू करता है, लेकिन agent runtime अभी तक साइन इन नहीं है। कंटेनर के अंदर साइन इन करें:

docker exec -it kirocrew kiro-cli login

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

docker exec kirocrew kirocrew token --ttl 2h

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

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

प्रोजेक्ट के उदाहरण में 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 public internet पर किसी भी ऐसे व्यक्ति के लिए उपलब्ध हो जाएगा जो उस port को scan करता है। firewall rule भी आपकी सुरक्षा नहीं करेगा: Docker ports को DNAT rules लिखकर publish करता है, जिनका मूल्यांकन ufw की filtering से पहले होता है, इसलिए ufw deny 5476 का किसी published port पर कोई प्रभाव नहीं पड़ता है। Docker ports bypassing ufw इस प्रक्रिया को विस्तार से समझाता है।

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

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

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

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

यदि आपके laptop पर port 5476 पहले से उपयोग में है, तो केवल बाईं ओर की संख्या बदलें: ssh -N -L 45476:127.0.0.1:5476 you@your-server.example.com, फिर http://localhost:45476/?token=... पर browse करें। जैसे ही कोई दूसरा agent box को share करेगा, आप इस तरह के forwards को stack कर रहे होंगे, क्योंकि self-hosting open-kritt for security scanning उसी सर्वर पर, port 5173 पर, एक और loopback-only डैशबोर्ड डालता है।

tunnel के माध्यम से एक documented व्यवहार जिसकी अपेक्षा की जानी चाहिए: gateway forwarded requests को remote के रूप में पढ़ता है, इसलिए डैशबोर्ड में 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

फोन से access के लिए project Tailscale के tailscale serve का सुझाव देता है। इससे dashboard public hostname पर रखने के बजाय आपके अपने tailnet के भीतर रहता है। इसे public reverse proxy की तुलना में प्राथमिकता दें। Token URL में जाता है, और उस URL को उसके रास्ते में आने वाले हर access log में लिखा जाता है। यह नियम port पर नहीं, बल्कि port के पीछे चल रही service पर लागू होता है: Halcyon, जो Jellyfin library को browse की जा सकने वाली 90s video store के रूप में फिर से बनाता है जैसी service को दूसरे लोग खोलने के लिए उपयोग करते हैं और वह reverse proxy के लिए उपयुक्त candidate है। इसके विपरीत, ऐसा gateway जो आपके server पर commands चला सकता है, reverse proxy के लिए उपयुक्त नहीं है।

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

कंटेनर पहली बार स्टार्ट होने पर सैंडबॉक्स सपोर्ट की जांच करता है, और परिणाम यह तय करता है कि एजेंट कुछ भी निष्पादित (execute) कर सकते हैं या नहीं। यदि नेमस्पेस आइसोलेशन उपलब्ध है, तो एजेंट के सब-प्रोसेस आइसोलेटेड होकर चलते हैं। यदि यह उपलब्ध नहीं है और KIROCREW_ALLOW_UNSANDBOXED=1 सेट नहीं है, तो अनकन्फाइंड (unconfined) तरीके से चलाने के बजाय निष्पादन को अस्वीकार कर दिया जाता है। इसलिए, यदि गेटवे स्वस्थ दिखता है लेकिन हर टास्क रुक जाता है, तो आमतौर पर यही कारण होता है। यह निर्णय उस पहले रन से 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 सॉकेट, / का कोई भी बाइंड माउंट, और किसी अन्य सर्विस का डेटा रखने वाली कोई भी डायरेक्टरी शामिल नहीं होनी चाहिए।

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

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

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

docker volume ls

कुछ भी कॉपी करने से पहले gateway को रोकें। memory.db और memory_index.db SQLite databases हैं। यदि आप database को लिखते समय उसे कॉपी करते हैं, तो एक अधूरी transaction कॉपी हो सकती है, जो restore करने पर corrupt file बन जाएगी। project के अपने migration निर्देश भी यही कहते हैं: memory को केवल तभी move करें जब gateways बंद हों। यह 'पहले रोकें' वाला नियम केवल KiroCrew के लिए नहीं है। यदि कोई photo server उसी box पर चल रहा है, तो the PhotoPrism and Immich comparison में उन दोनों के लिए आवश्यक सटीक backup commands दी गई हैं।

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 को box से बाहर कॉपी करें। restore करने के लिए वही command इस्तेमाल होती है, बस container को बंद रखें और 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 पर जाना, उसी स्थान पर restore करने से अलग काम है और project इस बारे में स्पष्ट है। workspace/memory/ के अंतर्गत chat history और project notes, साथ ही दोनों database files और config.json को ले जाया जा सकता है। PID files, security event log और .env पुराने host से जुड़े होते हैं, इसलिए उन्हें वहीं छोड़ दें और नए box पर 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 को pull करता है यदि वह पहले से box पर मौजूद नहीं है, इसलिए tag में बदलाव ही पूरा अपग्रेड है। रोल बैक करना पुराने number के साथ वही क्रम है, और यह आपको वही सटीक image देता है जो आपके पास पहले थी, क्योंकि version tags अपरिवर्तनीय (immutable) होते हैं।

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

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

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

दो व्यवहार ऐसे हैं जिन्हें आप पर निर्भर होने से पहले स्वयं टेस्ट करना उचित है। पहला, क्या डाउनग्रेड करने पर नई version द्वारा लिखा गया स्टेट पढ़ा जा सकता है: इसे वॉल्यूम की एक कॉपी पर तब आज़माएँ जब यह महत्वपूर्ण न हो, न कि आउटेज के दौरान। दूसरा, जब कोई scheduled job ड्यू हो और Kiro साइन-इन समाप्त हो जाए, तो गेटवे क्या करता है। ये दोनों ही ऐसी कमियाँ हैं जिन्हें एक नया प्रोजेक्ट 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 internet पर आ जाएगा, और firewall rule इसे रोक नहीं पाएगा, क्योंकि Docker के published-port DNAT rules, ufw द्वारा traffic filter करने से पहले ही evaluate हो जाते हैं।

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

सब कुछ ~/.kiro/crew के अंतर्गत स्थित है, जो container image के भीतर /home/kirocrew/.kiro/crew है, और KIROCREW_HOME इसे relocate करता है। gateway को stop करके पूरी directory, या पूरे Docker volume का backup लें। memory.db और memory_index.db SQLite databases हैं, इसलिए gateway के लिखते समय ली गई copy असंगत (inconsistent) हो सकती है। नए host पर migrate करते समय, 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 #सेल्फ़-होस्टिंग

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

KiroCrew को क्या चाहिए, और इसका स्टेट कहाँ रहता है

आपको तीन इंस्टॉलेशन पथों में से किसका उपयोग करना चाहिए

इमेज को एक release tag पर पिन करें, न कि stable पर

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

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

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

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

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

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

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

FAQ

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

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

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

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

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

इमेज को एक release tag पर पिन करें, न कि `stable` पर

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