द्वारे Matt Connor 2026-08-06 · अपडेटेड 2026-08-13

VPS वर KiroCrew कायम सुरू कसे ठेवावे

Q: KiroCrew डॅशबोर्ड माझ्या सर्व्हरच्या सार्वजनिक IP वर का उघडत नाही?

कारण प्रकाशित उदाहरण port ला loopback शी bind करते. -p 127.0.0.1:5476:5476 कंटेनरचा 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= उघडा. तो बाहेरून उपलब्ध करण्यासाठी 127.0.0.1: prefix काढल्यास gateway सार्वजनिक internet वर उघडतो. Firewall rule त्याला रोखू शकणार नाही, कारण Docker चे published-port DNAT rules ufw ने traffic filter करण्यापूर्वी लागू होतात.

Q: 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 विसंगत असू शकते. नवीन host वर स्थलांतर करताना workspace/memory/, दोन्ही database files आणि config.json सोबत आणा. PID files, security event log आणि .env जुन्या host शी संबंधित असतात.

Q: stable tag वापरावा की version tag?

Version tag वापरा. प्रत्येक release उपलब्ध झाल्यावर stable बदलतो. त्यामुळे पुढील pull वेळी तुम्ही चालवत असलेली version बदलू शकते. तसेच, सध्या कोणती version चालू आहे हे tag वरून कळत नाही. 0.1.3 सारखे version tags immutable असतात. त्यामुळे rollback योग्य प्रकारे करता येतो: जुना number पुन्हा set केल्यावर तीच image मिळते. 6 August 2026 रोजी नवीनतम release 0.1.3 आहे.

Docker आणि systemd वापरून VPS वर KiroCrew चा pinned container चालवा. reboot नंतर memory व schedules टिकवा, SSH access, backups आणि rollback या मार्गदर्शकात समजून घ्या.

लॅपटॉपऐवजी VPS वर KiroCrew self-host का करावे

Self-hosting KiroCrew उपयुक्त ठरण्यासाठी ते कधीही sleep मध्ये न जाणाऱ्या मशीनवर चालणे आवश्यक आहे. त्यामुळे VPS हे त्यासाठी योग्य ठिकाण आहे; लॅपटॉप योग्य नाही. KiroCrew session history, semantic memory, scheduled jobs आणि approval queue डिस्कवर ठेवते. process पुन्हा सुरू झाल्यावर ते सर्व पुन्हा लोड केले जाते. scheduled job ची वेळ 03:00 असताना process चालू नसेल, तर यापैकी कोणत्याही गोष्टीचा उपयोग होत नाही. बंद लॅपटॉपवर process चालू नसतो.

KiroCrew हे Kiro team कडून विकसित केलेले open source agent workspace आहे. त्याचा परवाना Apache 2.0 आहे. त्याची पहिली सार्वजनिक releases August 2026 च्या सुरुवातीला उपलब्ध झाली. gateway नावाचा एक process state नियंत्रित करतो आणि port 5476 वर web dashboard उपलब्ध करून देतो. तुम्ही dashboard, kirocrew CLI किंवा Slack सारख्या chat channel मधून त्या gateway शी संपर्क साधता. तुम्ही self-host करत असलेली एकमेव गोष्ट gateway आहे. त्यामुळे हा मार्गदर्शक तो सतत चालू ठेवणे, public internet पासून दूर ठेवणे आणि खराब upgrade नंतर पुन्हा पूर्वस्थितीत आणता येणे यावर केंद्रित आहे.

सुरुवात करण्यापूर्वी दोन गोष्टी लक्षात ठेवा. KiroCrew kiro-cli चालवते. त्यासाठी Kiro account वापरून एकदाच sign-in करावे लागते. Agent inference चा खर्च Kiro plan वर आकारला जातो. त्यामुळे August 2026 पर्यंत ही offline setup नाही. हा project देखील केवळ काही आठवड्यांचा आहे. काही टप्प्यावर rollback करावा लागेल असे गृहीत धरा. ते शक्य होईल अशा पद्धतीने installation करा. तुम्ही यापूर्वी server वर agent चालवला नसेल, तर VPS वर coding agent चालवणे या मार्गदर्शकात या मार्गदर्शकासाठी आवश्यक मूलभूत माहिती दिली आहे.

KiroCrew ला काय आवश्यक आहे आणि त्याची स्थिती कुठे साठवली जाते

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 आवश्यक आहे. Container install पसंत करण्याचे हे मुख्य कारण आहे.

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/: पहिल्या run वेळी download होणारे embedding model.
gateway.log आणि security_events.jsonl: runtime log आणि security event log.

ही directory म्हणजेच पूर्ण install आहे. ती नवीन VPS वर copy केल्यास तुमचा agent हलवला जातो. म्हणूनच खालील backup section ला install section पेक्षा अधिक महत्त्व आहे.

RAM पेक्षा disk space चे नियोजन करा. Gateway ही Python process आहे. मात्र मशीनवर प्रत्यक्ष भार agent चालवत असलेल्या गोष्टींमुळे येतो, जसे की build किंवा test suite. Chat history वाढत गेल्याने state directory चा आकार वाढतो. Embedding model पहिल्या start वेळी download होते. त्यामुळे project च्या पहिल्या महिन्यात प्रकाशित केलेल्या कोणत्याही आकड्यावर अवलंबून राहण्याऐवजी, काही आठवड्यांनंतर तुमच्या मशीनवर du -sh ~/.kiro/crew वापरून तिचा आकार मोजा.

तीन install path पैकी कोणता वापरावा

प्रकल्प तीन install path प्रकाशित करतो. One-line installer एक wheel fetch करतो आणि 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 बदलणाऱ्या लोकांसाठी आहे; application चालवणाऱ्या लोकांसाठी नाही.

Container वापरा. Native install केल्यास इतर services चालवणाऱ्या त्याच host वर Python packages, Node आणि kiro-cli install होतात. त्यामुळे upgrade अयशस्वी झाल्यास त्यातून manually बाहेर पडावे लागते. Container runtime एका image मध्ये आणि state एका volume मध्ये ठेवतो. त्यामुळे rollback करण्यासाठी tag बदलून service restart करणे पुरेसे असते.

इमेजला `stable` ऐवजी release tag वर pin करा

प्रकल्पाच्या स्वतःच्या उदाहरणात 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 हा बदलणारा tag आहे. तो त्या वेळी उपलब्ध असलेल्या सर्वात नवीन stable release कडे निर्देश करतो. त्यामुळे पुढील pull वेळी तुमची निवड नसतानाही चालू असलेली आवृत्ती बदलू शकते. तसेच त्या tag वरून कोणती आवृत्ती वापरली होती हे कळत नाही. Version tags immutable असतात, त्यामुळे एखादी निश्चित आवृत्ती pin करा. 6 August 2026 रोजी सर्वात नवीन release 0.1.3 आहे. ती 5 August 2026 रोजी प्रकाशित झाली. 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:

ते सुरू करा. त्यानंतर image स्वतःच्या HEALTHCHECK साठी वापरत असलेला health endpoint तपासा:

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 देखील token शिवाय उत्तर देतात. त्यामुळे ते probe म्हणून वापरता येतात. स्थिती starting वरच राहिल्यास काहीही बदलण्यापूर्वी docker logs kirocrew वाचा. पहिल्या run मध्ये embedding model download होते. त्यामुळे link धीमा असल्यास पहिल्यांदा सुरू होण्यासाठी जास्त वेळ लागू शकतो.

systemd वापरून ते सुरू ठेवा

restart: unless-stopped मुळे container crash झाल्यानंतर आणि reboot नंतर पुन्हा सुरू होतो, परंतु Docker स्वतः boot वेळी सुरू होत असणे आवश्यक आहे. Unit file ही dependency स्पष्ट करते आणि backup घेण्यापूर्वी संपूर्ण stack थांबवण्यासाठी एक command देते. 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 एखाद्या foreground process ऐवजी stack सुरू असल्याची स्थिती track करते. त्याऐवजी Type=simple लिहिल्यास command त्वरित exit झाल्याचे systemd पाहते, 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 मिळवा

कंटेनर gateway सुरू करतो; मात्र agent runtime मध्ये अद्याप साइन इन केलेले नसते. कंटेनरच्या आत साइन इन करा:

docker exec -it kirocrew kiro-cli login

यामुळे device code आणि तुमच्या स्वतःच्या browser मध्ये उघडायची URL दाखवली जाते. त्यानंतर dashboard token तयार करा:

docker exec kirocrew kirocrew token --ttl 2h

Dashboard URL http://localhost:5476/?token=<the token> आहे. Tokens कालबाह्य होतात: सत्रांचा default कालावधी one hour असतो आणि दस्तऐवजीकरणानुसार कमाल कालावधी twenty hours आहे. Dashboard रिकामे लोड होत असेल किंवा तुम्हाला थेट पुन्हा बाहेर पाठवत असेल, तर token बहुधा कालबाह्य झालेला असतो. त्यामुळे नवीन token तयार करा. Token कधीही ticket किंवा chat message मध्ये paste करू नका, कारण तो ज्याच्याकडे असेल त्याला तुमच्या agent वर नियंत्रण मिळते.

SSH द्वारे dashboard वापरा आणि port 5476 कधीही सार्वजनिक करू नका

प्रकल्पाच्या उदाहरणातील bind address पुन्हा पाहा: -p 127.0.0.1:5476:5476. कंटेनरच्या आत gateway 0.0.0.0 वर listen करतो, कारण port mapping द्वारे त्याच्यापर्यंत पोहोचता आले पाहिजे. मात्र mapping host वरील loopback वरच प्रकाशित होते. 127.0.0.1: prefix काढून टाकल्यास, तो port scan करणाऱ्या कोणत्याही व्यक्तीसाठी gateway सार्वजनिक इंटरनेटवर उपलब्ध होतो. Firewall rule देखील तुम्हाला वाचवणार नाही: Docker DNAT rules लिहून ports प्रकाशित करते. या rules चे मूल्यमापन ufw च्या filtering पूर्वी होते. त्यामुळे प्रकाशित port वर ufw deny 5476 याचा परिणाम होत नाही. ufw ला bypass करणारे Docker ports ही यंत्रणा स्पष्ट करते.

त्याऐवजी 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 वर हा 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 करा.

Tunnel द्वारे वापरताना एक documented behaviour लक्षात ठेवा: gateway forwarded requests remote म्हणून वाचतो. त्यामुळे dashboard मधील config-write आणि secret-reveal endpoints त्या requests नाकारतात. 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 साठी प्रकल्प Tailscale च्या tailscale serve कडे निर्देश करतो. त्यामुळे dashboard public hostname वर न ठेवता तुमच्या स्वतःच्या tailnet मध्येच राहतो. सार्वजनिक reverse proxy पेक्षा हा पर्याय वापरा. Token URL मध्ये असतो आणि त्या URL चा प्रत्येक access log मध्ये नोंद केली जाते.

एजंटला शक्य तितका मर्यादित परिणामक्षेत्र द्या

कंटेनर पहिल्यांदा सुरू होताना sandbox समर्थनाची तपासणी करतो. या तपासणीच्या निकालावर एजंट काहीही चालवू शकतो की नाही हे ठरते. namespace isolation उपलब्ध असल्यास एजंटचे subprocesses isolated पद्धतीने चालतात. ते उपलब्ध नसल्यास आणि KIROCREW_ALLOW_UNSANDBOXED=1 सेट केलेले नसल्यास execution unconfined पद्धतीने चालवण्याऐवजी नाकारले जाते. त्यामुळे gateway निरोगी दिसत असला, तरी प्रत्येक task अडकत असेल, तर हेच बहुतेकदा कारण असते. हा निर्णय पहिल्या run मधील docker logs kirocrew मध्ये नोंदवला जातो. प्रकल्प seccomp (secure computing mode) profile देखील प्रकाशित करतो. तो तुम्ही लागू करू शकता:

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 सेट केल्यास काय बदलले आहे हे स्पष्टपणे समजून घ्या: आता एजंट आणि तुमचा server यांच्यामधील एकमेव boundary कंटेनर आहे. प्रकल्पाची warning पूर्णपणे पुन्हा सांगण्यासारखी आहे. एजंटला थेट देण्यास तुम्ही तयार नसलेले host paths mount करू नका. प्रत्यक्षात यामुळे Docker socket, / चा कोणताही bind mount आणि दुसऱ्या सेवेचा data असलेली कोणतीही directory वगळावी लागते.

उर्वरित बाबी command चालवण्याची परवानगी असलेल्या प्रत्येक एजंटला लागू होतात. त्याची credentials फक्त आवश्यक असलेल्या एका repository किंवा एका bucket पुरती मर्यादित ठेवा. account-wide अधिकार असलेला personal token कधीही वापरू नका. dedicated user म्हणून एजंट चालवा. त्या user च्या home मध्ये इतर कोणतीही सामग्री ठेवू नका. यासाठी VPS वरील किमान अधिकार असलेले users उपयुक्त आहेत. एजंट code लिहून तो code चालवत असल्यास, त्याला बिघडवण्याची परवानगी असलेली machine द्या: coding agents साठी disposable VM ही या compose file मधील कोणत्याही flag पेक्षा मजबूत boundary आहे. कारण ती साफ करण्याऐवजी तुम्ही delete करू शकता. याच विचारातून VPS वर OpenClaw सुरक्षितपणे चालवणे आणि VPS वर Hermes agent self-host करणे या पद्धती ठरतात. Tools मुळेही परिणामक्षेत्र वाढते. एजंटला web search दिल्यास तो fetch करत असलेले प्रत्येक page untrusted input बनते. त्यामुळे तुमच्या स्वतःच्या SearXNG instance कडे त्याला निर्देशित करणे हा plumbing इतकाच prompt injection शी संबंधित निर्णय आहे. Scheduled work मुळे तुम्ही झोपेत असतानाही खर्च होतो, कारण inference चा खर्च तुमच्या Kiro plan वर आकारला जातो. त्यामुळे nightly job जोडण्यापूर्वी VPS वर AI agent चा खर्च नियंत्रित करणे येथे वर्णन केलेल्या limits सेट करा.

प्रत्येक upgrade पूर्वी state volume चा backup घ्या

प्रथम वास्तविक volume name शोधा. Compose named volumes ला project name चा prefix लावते. हा name default म्हणून directory name असतो. त्यामुळे /opt/kirocrew/compose.yaml मध्ये kirocrew-home म्हणून घोषित केलेला volume kirocrew_kirocrew-home या नावाने तयार होतो:

docker volume ls

काहीही copy करण्यापूर्वी gateway थांबवा. memory.db आणि memory_index.db हे SQLite databases आहेत. Database मध्ये लेखन सुरू असताना copy केल्यास अर्धवट transaction capture होऊ शकते. त्यामुळे restore केल्यानंतर file corrupt होऊ शकते. Project च्या migration instructions मध्येही हेच सांगितले आहे: gateways थांबवलेले असतानाच memory हलवा.

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 host च्या बाहेर copy करा. Restore करण्यासाठी container थांबवून आणि tar xzf ऐवजी tar czf वापरून हीच command चालवा:

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 नवीन host वर नेता येतात. PID files, security event log आणि .env जुन्या host शी संबंधित आहेत. त्यामुळे ते जुन्या host वरच ठेवा आणि नवीन host वर secrets पुन्हा नोंदवा.

वाईट upgrade कसा पूर्ववत कराल

Upgrade प्रक्रिया लहान आहे. ती सुरक्षित असण्याचे कारण म्हणजे तुम्ही version निश्चित केला आहे. प्रथम 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 करते. त्यामुळे tag संपादित करणे हाच संपूर्ण upgrade आहे. जुना number वापरून हीच प्रक्रिया केल्यास rollback होते. यामुळे आधी वापरलेली अगदी तीच image मिळते, कारण version tags बदलता येत नाहीत.

Binary व्यवस्थित rollback होते. मात्र state तशीच पूर्ववत होईलच असे नाही. नवीन gateway config.json पुन्हा लिहू शकतो किंवा memory databases अशा स्वरूपात migrate करू शकतो, जे जुना gateway वाचू शकत नाही. August 2026 पर्यंत downgrade path documented नाही. त्यामुळे जुनी image सुरू झाल्यानंतर विचित्र वर्तन करत असेल, तर त्याचे debugging करू नका. ती थांबवा, upgrade करण्यापूर्वी घेतलेला backup restore करा आणि पुन्हा सुरू करा. Backup प्रथम घेण्याचे हेच पूर्ण कारण आहे. इतक्या नवीन project मध्ये आधी upgrade करणे आणि नंतर backup घेणे ही सवय अपयशी ठरते.

येथे काय सिद्ध झालेले नाही

या सॉफ्टवेअरचे वय लक्षात घेऊन प्रामाणिकपणे विचार करा. हा मजकूर लिहिताना 0.1.3 ही आवृत्ती काही दिवसांपूर्वीच प्रसिद्ध झाली आहे. तिच्या release notes मध्ये migration notes नसून automated changelog links आहेत. तसेच upgrades चा कोणताही track record अद्याप उपलब्ध नाही. या मार्गदर्शिकेतील कोणताही निष्कर्ष दीर्घकाळाच्या वापरावर आधारित नाही. त्यामुळे memory growth, database size आणि scheduler reliability या बाबी गृहीत धरू नका. त्या तुमच्या स्वतःच्या मशीनवर मोजा.

दोन वर्तनांवर अवलंबून राहण्यापूर्वी त्यांची स्वतः चाचणी घेणे योग्य आहे. पहिले म्हणजे downgrade नवीन आवृत्तीने लिहिलेली state वाचते का. याची चाचणी outage दरम्यान करू नका. गरज नसताना volume ची प्रत वापरून चाचणी करा. दुसरे म्हणजे scheduled job देय असताना Kiro sign-in ची मुदत संपल्यास gateway काय करते. नवीन project मध्ये अशा मर्यादा releases दरम्यान शांतपणे दूर केल्या जातात. या दोन्ही बाबी आत्ताच तपासणे सोपे आहे.

FAQ

KiroCrew डॅशबोर्ड माझ्या सर्व्हरच्या सार्वजनिक IP वर का उघडत नाही?

कारण प्रकाशित उदाहरण port ला loopback शी bind करते. -p 127.0.0.1:5476:5476 कंटेनरचा 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> उघडा. तो बाहेरून उपलब्ध करण्यासाठी 127.0.0.1: prefix काढल्यास gateway सार्वजनिक internet वर उघडतो. Firewall rule त्याला रोखू शकणार नाही, कारण Docker चे published-port DNAT rules ufw ने traffic filter करण्यापूर्वी लागू होतात.

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 विसंगत असू शकते. नवीन host वर स्थलांतर करताना workspace/memory/, दोन्ही database files आणि config.json सोबत आणा. PID files, security event log आणि .env जुन्या host शी संबंधित असतात.

`stable` tag वापरावा की version tag?

Version tag वापरा. प्रत्येक release उपलब्ध झाल्यावर stable बदलतो. त्यामुळे पुढील pull वेळी तुम्ही चालवत असलेली version बदलू शकते. तसेच, सध्या कोणती version चालू आहे हे tag वरून कळत नाही. 0.1.3 सारखे version tags immutable असतात. त्यामुळे rollback योग्य प्रकारे करता येतो: जुना number पुन्हा set केल्यावर तीच image मिळते. 6 August 2026 रोजी नवीनतम release 0.1.3 आहे.

माझा agent कोणतीही command चालवण्यास नकार का देतो?

Container पहिल्यांदा सुरू होताना sandbox support तपासतो. Agent subprocesses isolate करता येत नसतील आणि KIROCREW_ALLOW_UNSANDBOXED=1 set केलेला नसेल, तर container ते subprocesses unconfined पद्धतीने चालवण्याऐवजी commands execute करण्यास नकार देतो. त्यामुळे gateway healthy दिसतो, पण प्रत्येक task थांबतो. पहिल्या run मधील sandbox निर्णय docker logs kirocrew दाखवते. हा variable set केल्यास agent आणि host यांच्यामधील एकमेव boundary container असते. त्यामुळे तो set करताना agent ला थेट देणार नसलेली कोणतीही गोष्ट mount करू नका.

KiroCrew self-host करण्यासाठी Kiro account आवश्यक आहे का?

होय, August 2026 पर्यंत. KiroCrew हे Apache 2.0 अंतर्गत उपलब्ध free software आहे. परंतु ते kiro-cli चालवते. यासाठी एकदाच sign-in करावा लागतो आणि agent inference साठी Kiro plan नुसार शुल्क आकारले जाते. Container मध्ये docker exec -it kirocrew kiro-cli login चालवा आणि browser मध्ये device code मंजूर करा. हा sign-in पूर्ण होईपर्यंत gateway सुरू होतो आणि dashboard load होते. मात्र agent कडे संवाद साधण्यासाठी model उपलब्ध नसते.

#kirocrew#ai-agents #docker #systemd #self-hosting

लॅपटॉपऐवजी VPS वर KiroCrew self-host का करावे

KiroCrew ला काय आवश्यक आहे आणि त्याची स्थिती कुठे साठवली जाते

तीन install path पैकी कोणता वापरावा

इमेजला stable ऐवजी release tag वर pin करा

systemd वापरून ते सुरू ठेवा

पहिली धाव: साइन इन करा आणि dashboard token मिळवा

SSH द्वारे dashboard वापरा आणि port 5476 कधीही सार्वजनिक करू नका

एजंटला शक्य तितका मर्यादित परिणामक्षेत्र द्या

प्रत्येक upgrade पूर्वी state volume चा backup घ्या

वाईट upgrade कसा पूर्ववत कराल

येथे काय सिद्ध झालेले नाही

FAQ

KiroCrew डॅशबोर्ड माझ्या सर्व्हरच्या सार्वजनिक IP वर का उघडत नाही?

KiroCrew आपला data कुठे साठवते आणि मी कोणता backup घ्यावा?

stable tag वापरावा की version tag?

माझा agent कोणतीही command चालवण्यास नकार का देतो?

KiroCrew self-host करण्यासाठी Kiro account आवश्यक आहे का?

इमेजला `stable` ऐवजी release tag वर pin करा

`stable` tag वापरावा की version tag?