Jinsi ya ku-host KiroCrew kwenye VPS kwa usahihi

Kwa nini u-self-host KiroCrew kwenye VPS badala ya laptop

Self-hosting ya KiroCrew inaleta faida tu kwenye mashine ambayo haizimi, kwa hiyo VPS ndiyo mahali sahihi pa kuiweka na si laptop. KiroCrew huhifadhi historia ya session, kumbukumbu ya semantic, kazi zilizopangwa (scheduled jobs) na foleni ya idhini kwenye diski, na hupakia upya data hizo zote mchakato (process) unapoanzishwa upya. Hakuna faida yoyote ikiwa mchakato haufanyi kazi saa 09:00 usiku wakati kazi iliyopangwa inatakiwa kutekelezwa, na laptop iliyofungwa haiwezi kuendesha mchakato huo.

KiroCrew ni nafasi ya kazi ya wakala (agent workspace) ya chanzo huria kutoka kwa timu ya Kiro, yenye leseni ya Apache 2.0, na matoleo yake ya kwanza ya umma yalitoka mapema Agosti 2026. Mchakato mmoja, unaoitwa gateway, unamiliki hali (state) na kutoa dashibodi ya wavuti kwenye port 5476. Unafikia gateway hiyo kutoka kwenye dashibodi, kutoka kwa kirocrew CLI, au kutoka kwenye chaneli ya gumzo kama Slack. Gateway ndicho kitu pekee unachofanya self-hosting, kwa hiyo mwongozo huu unahusu jinsi ya kuifanya iendelee kufanya kazi, kuizuia isionekane kwenye mtandao wa umma, na kuweza kuirejesha baada ya upgrade mbaya.

Mambo mawili ya kujua kabla ya kuanza. KiroCrew huendesha kiro-cli, ambayo inahitaji kuingia (sign-in) mara moja kwa kutumia akaunti ya Kiro, na inference ya wakala inatozwa kwenye mpango wa Kiro, kwa hivyo kufikia Agosti 2026 hii si usanidi wa nje ya mtandao (offline). Mradi huu pia una wiki chache tu tangu kuanzishwa. Tarajia kuwa utahitaji kufanya rollback wakati fulani, na uisakinishe kwa njia inayokuruhusu kufanya hivyo. Ikiwa hujawahi kuendesha wakala kwenye seva hapo awali, kuendesha wakala wa coding kwenye VPS kunashughulikia kanuni za msingi ambazo mwongozo huu unajengwa juu yake.

Mahitaji ya KiroCrew, na mahali hali yake inapohifadhiwa

Ufungaji wa asili (native install) unahitaji Python 3.10 au toleo jipya zaidi (mradi unapendekeza 3.12), Node.js 18 au toleo jipya zaidi ikiwa unajenga dashboard kutoka kwenye source code, na kiro-cli, ambayo uzinduzi wa kwanza utaisakinisha na kukuwezesha kuingia. Ufungaji wa container hauhitaji chochote kati ya hivyo kwenye host. Unahitaji tu Docker. Hiyo ndiyo sababu kuu ya kuupendelea.

Hali ya mfumo (state) inakaa ndani ya ~/.kiro/crew, na variable ya mazingira ya KIROCREW_HOME inaweza kuihamishia mahali pengine. Yaliyomo ndani yake ni:

• config.json: mipangilio ya gateway na vitambulisho vya chat channel.
• .env: siri (secrets).
• workspace/memory/: mapendeleo, madokezo ya mradi na historia ya chat.
• memory.db na memory_index.db: index za semantic na full-text.
• models/: modeli ya embedding, inayopakuliwa wakati wa uzinduzi wa kwanza.
• gateway.log na security_events.jsonl: logi ya runtime na logi ya matukio ya usalama.

Saraka hiyo ndiyo ufungaji wenyewe. Icopy kwenye VPS mpya na utakuwa umehamisha agent wako, ndiyo maana sehemu ya backup hapa chini ni muhimu zaidi kuliko sehemu ya ufungaji.

Panga kwa ajili ya diski badala ya RAM. Gateway ni mchakato wa Python; kinachozidisha mzigo kwenye seva ni kile ambacho agent anakiendesha, kama vile build au test suite. Saraka ya state hukua kulingana na historia ya chat, na modeli ya embedding hufika wakati wa kuanza kwa mara ya kwanza, kwa hivyo ipime kwenye seva yako mwenyewe kwa kutumia du -sh ~/.kiro/crew baada ya wiki chache badala ya kuamini takwimu zozote zilizochapishwa katika mwezi wa kwanza wa mradi.

Ni njia ipi kati ya njia tatu za usakinishaji unayopaswa kutumia

Mradi huu huchapisha njia tatu. Kisakinishi cha mstari mmoja hupakua wheel na kuweka kirocrew kwenye PATH yako:

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

Huchukua flag ya channel na flag ya version:

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

Picha ya container huchapishwa kwenye ghcr.io/kirodotdev/kirocrew, kwa ajili ya linux/amd64 na linux/arm64 chini ya kila tag. Ujenzi kutoka kwa source ni git clone pamoja na make build, na ni kwa ajili ya watu wanaobadilisha code, si kwa ajili ya watu wanaoitumia.

Tumia container. Usakinishaji wa native huweka vifurushi vya Python, Node na kiro-cli kwenye host ileile inayoendesha huduma zako nyingine, kwa hivyo upgrade inayofeli kukuachia kazi ya kurekebisha kwa mikono. Container huweka runtime kwenye image moja na state kwenye volume moja, jambo linalofanya rollback kuwa ni kubadili tag na kuanzisha upya.

Bandika picha kwenye tag ya toleo, siyo kwenye stable

Mfano wa mradi huu unatumia tag ya stable:

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

stable ni tag inayobadilika. Inaelekeza kwenye toleo lolote jipya zaidi la stable, kwa hivyo pull inayofuata inaweza kubadilisha toleo unaloliendesha bila wewe kuchagua, na tag hiyo hairekodi chochote kuhusu toleo hilo lilikuwa lipi. Tag za toleo haziwezi kubadilika (immutable), kwa hivyo bandika moja. Toleo jipya zaidi kufikia 6 August 2026 ni 0.1.3, lililochapishwa tarehe 5 August 2026. Kuna pia tag ya nightly, ambayo kwenye mradi mchanga kama huu inamaanisha kuwa msimbo umebadilika asubuhi ya leo.

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

Ianzishe, kisha kagua endpoint ya afya (health endpoint) ambayo picha hiyo pia inaitumia kwa ajili ya HEALTHCHECK yake:

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

docker compose ps inapaswa kuripoti kuwa container iko katika hali nzuri (healthy) ndani ya dakika moja hivi, na /api/health inajibu bila token (kama vile /api/live na /api/ready, jambo linalozifanya ziweze kutumika kama probes). Ikiwa hali inabaki kuwa starting, soma docker logs kirocrew kabla ya kubadilisha chochote. Uendeshaji wa kwanza unapakua modeli ya embedding, kwa hivyo muunganisho wa polepole hufanya kuanza kwa mara ya kwanza kuchukue muda mrefu.

Dumisha huduma kwa kutumia systemd

restart: unless-stopped huirejesha container baada ya crash na baada ya reboot, mradi tu Docker yenyewe ianze wakati wa boot. Faili la unit hufanya utegemezi huo kuwa wazi na kukupa amri moja ya kusimamisha stack nzima kabla ya kufanya backup. Kuanzisha stack ya Docker Compose wakati wa boot inaelezea muundo huu kwa ujumla. Hii ndiyo namna ya KiroCrew ya kuifanya, katika /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 inapaswa kusomeka active (exited), ambayo ndiyo matokeo sahihi kwa unit hii. Type=oneshot pamoja na RemainAfterExit=yes imewekwa hapa kwa sababu docker compose up -d hurejea mara tu container inapoanzishwa: systemd hufuatilia ukweli kwamba stack iko juu, si mchakato wa foreground. Andika Type=simple badala yake na systemd itaona amri hiyo ikimaliza kazi mara moja, itaashiria huduma hiyo imekufa, kisha itaacha au kuanza mzunguko wa restart kulingana na mpangilio wako wa Restart=. Kwa usakinishaji wa asili (native install), mradi huu hutoa kitu chake sawa na hicho, kirocrew service install, ambacho huandika /etc/systemd/system/kirocrew.service na kuendesha gateway kama mtumiaji wako. Usiendeshe unit zote mbili kwa wakati mmoja. Toleo pana zaidi la mada hii liko katika huduma za systemd na timers kwenye VPS.

Uendeshaji wa kwanza: ingia na upate token ya dashboard

Container huanzisha gateway, lakini agent runtime bado haijaingia kwenye mfumo. Ingia ndani ya container:

docker exec -it kirocrew kiro-cli login

Hii itachapisha device code na URL unayopaswa kufungua kwenye kivinjari chako. Kisha tengeneza token ya dashboard:

docker exec kirocrew kirocrew token --ttl 2h

URL ya dashboard ni http://localhost:5476/?token=<the token>. Token huisha muda wake: session hudumu kwa saa moja kwa kawaida na muda mrefu zaidi ulioruhusiwa ni saa ishirini. Dashboard inayofunguka ikiwa tupu au inayokurudisha nje mara moja kwa kawaida inaashiria token iliyoisha muda wake, hivyo tengeneza nyingine. Usibandike token kwenye tiketi au ujumbe wa chat, kwa sababu yeyote anayeishikilia anashikilia agent yako.

Fikia dashibodi kupitia SSH, na usiwahi kuchapisha port 5476

Angalia tena anwani ya bind katika mfano wa mradi: -p 127.0.0.1:5476:5476. Ndani ya container, gateway inasikiliza kwenye 0.0.0.0, kwa sababu lazima iweze kufikika kupitia port mapping, lakini mapping yenyewe huchapisha kwenye loopback pekee ya host. Futa prefix ya 127.0.0.1: na gateway itakuwa kwenye mtandao wa umma kwa yeyote anayechanganua (scan) port hiyo. Sheria ya firewall haitakuokoa: Docker huchapisha ports kwa kuandika sheria za DNAT ambazo hupitiwa kabla ya uchujaji wa ufw, kwa hivyo ufw deny 5476 haifanyi kazi kwenye port iliyochapishwa. Docker ports bypassing ufw inaelezea utaratibu huo.

Sambaza (forward) port hiyo kupitia SSH kutoka kwenye laptop yako badala yake:

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

Iache ikifanya kazi na ufungue http://localhost:5476/?token=<the token> kwenye mashine yako. Ili kufanya usambazaji huo kuwa wa kiotomatiki kila unapounganisha, iweke kwenye ~/.ssh/config:

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

Ikiwa port 5476 tayari inatumiwa kwenye laptop yako, badilisha namba ya upande wa kushoto pekee: ssh -N -L 45476:127.0.0.1:5476 you@your-server.example.com, kisha uende kwenye http://localhost:45476/?token=....

Tabia moja iliyoandikwa ambayo inapaswa kutarajiwa kupitia tunnel: gateway husoma maombi yaliyosambazwa kama ya mbali (remote), kwa hivyo endpoints za config-write na secret-reveal kwenye dashibodi huyakataa. Mabadiliko ya mipangilio ambayo hayahifadhiwi kupitia SSH ni ya kawaida, si hitilafu. Hariri usanidi kwenye host badala yake:

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

Kwa ufikiaji wa simu, mradi unaelekeza kwenye tailscale serve ya Tailscale, ambayo huweka dashibodi ndani ya tailnet yako badala ya hostname ya umma. Ipendekeze hiyo kuliko reverse proxy ya umma. Token husafiri ndani ya URL, na URL huandikwa kwenye kila access log katika njia yake.

Mpe wakala wigo mdogo zaidi wa madhara (blast radius)

Kontena hufanya uchunguzi wa usaidizi wa sandbox wakati wa kuanza kwa mara ya kwanza, na matokeo huamua kama mawakala wanaweza kutekeleza chochote. Ikiwa namespace isolation inapatikana, subprocesses za wakala huendeshwa kwa kutengwa. Ikiwa haipatikani na KIROCREW_ALLOW_UNSANDBOXED=1 haijawekwa, utekelezaji hukataliwa badala ya kuendeshwa bila vizuizi, kwa hivyo gateway inayoonekana kuwa nzima wakati kila kazi inakwama kwa kawaida husababishwa na hili. Uamuzi huu uko kwenye docker logs kirocrew kutoka kwa uanzishaji huo wa kwanza. Mradi huu pia huchapisha profile ya seccomp (secure computing mode) unayoweza kutumia:

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

Ikiwa utaweka KIROCREW_ALLOW_UNSANDBOXED=1, uwe wazi kuhusu kile kilichobadilika: kontena sasa ndilo kizuizi pekee kati ya wakala na seva yako. Onyo la mradi huu linastahili kurudiwa kikamilifu. Usiweke (mount) njia za host ambazo usingempa wakala moja kwa moja. Kwa vitendo, hii inakataza Docker socket, bind mount yoyote ya /, na saraka yoyote inayoshikilia data ya huduma nyingine.

Mengine yote ni mfumo unaotumika kwa kila wakala anayeruhusiwa kuendesha amri. Punguza wigo wa vitambulisho vyake (credentials) kwenye repository moja au bucket moja inayohitaji, kamwe usitumie token ya kibinafsi yenye haki za akaunti nzima. Iendeshe kama mtumiaji maalum ambaye saraka yake ya nyumbani (home) haina kitu kingine, jambo ambalo ndilo kusudi la watumiaji wenye upendeleo mdogo kwenye VPS. Wakati wakala anapoandika msimbo na kisha kuendesha msimbo huo, mpe mashine anayoruhusiwa kuivunja: VM inayoweza kutupwa kwa ajili ya mawakala wa uandishi wa msimbo ni kizuizi imara zaidi kuliko flag yoyote katika faili hili la compose, kwa sababu unaifuta badala ya kuisafisha. Hoja hiyo hiyo huunda kuendesha OpenClaw kwa usalama kwenye VPS na kujihostia wakala wa Hermes kwenye VPS. Zana pia huhesabiwa kama sehemu ya wigo wa madhara: kumpa wakala uwezo wa kutafuta kwenye wavuti hufanya kila ukurasa anaouchukua kuwa input isiyoaminika, kwa hivyo kumwelekeza kwenye instance yako ya SearXNG ni uamuzi wa kuzuia prompt injection vilevile kama uamuzi wa kiufundi. Kazi zilizopangwa pia hutumia pesa wakati umelala, kwa kuwa inference hutoza gharama kwenye mpango wako wa Kiro, kwa hivyo weka mipaka iliyoelezewa katika kudhibiti gharama za wakala wa AI kwenye VPS kabla ya kuongeza kazi ya usiku.

Hifadhi nakala ya volume ya state kabla ya kila upgrade

Tafuta jina halisi la volume kwanza. Compose huweka viambishi awali kwenye named volumes kwa kutumia jina la mradi, ambalo kwa kawaida ni jina la saraka, kwa hivyo volume iliyotangazwa kama kirocrew-home katika /opt/kirocrew/compose.yaml hutengenezwa kama kirocrew_kirocrew-home:

docker volume ls

Simamisha gateway kabla ya kunakili chochote. memory.db na memory_index.db ni database za SQLite, na kunakili database wakati inaandikiwa kunaweza kunasa transaction ambayo haijakamilika, jambo linalosababisha faili lililoharibika wakati wa kurejesha. Maelekezo ya migration ya mradi huu yanasema vivyo hivyo: hamisha kumbukumbu tu wakati gateways zimesimamishwa.

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

Nakili archive nje ya seva. Kurejesha ni amri ileile huku container ikiwa imesimamishwa na tar xzf ikichukua nafasi ya 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

Kuhamia kwenye host mpya ni kazi tofauti na kurejesha kwenye mfumo uleule, na mradi huu una maelekezo mahususi kuhusu hilo. Historia ya chat na madokezo ya mradi yaliyo chini ya workspace/memory/ huhamishika, pamoja na faili mbili za database na config.json. Faili za PID, logi ya matukio ya usalama na .env zimefungwa na host ya zamani, kwa hivyo ziache na uingize siri (secrets) tena kwenye mashine mpya.

Jinsi ya kurejesha toleo la awali baada ya upgrade mbaya

Upgrade ni fupi, na inakuwa salama tu kwa sababu umefunga (pin) toleo fulani. Chukua backup kwanza, kisha badilisha 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 hupakua image ikiwa haipo kwenye seva, kwa hivyo kuhariri tag ndiyo upgrade nzima. Kurejesha toleo la awali ni mfuatano uleule kwa kutumia namba ya zamani, na inakupa image ileile uliyokuwa nayo awali, kwa sababu version tags haziwezi kubadilishwa.

Binary hurejea katika hali yake ya awali bila matatizo. Hali ya data (state) ndiyo sehemu inayoweza kuleta shida. Gateway mpya inaweza kuandika upya config.json au kuhamaisha database za kumbukumbu kwenda kwenye umbo ambalo gateway ya zamani haisomi, na hakuna njia ya downgrade iliyoandikwa kufikia Agosti 2026. Kwa hivyo, ikiwa image ya zamani inaanza na kisha kuonyesha tabia za ajabu, usijaribu kuitatua. Iisimamishe, rejesha backup uliyochukua kabla ya upgrade, na uanze upya. Hiyo ndiyo sababu nzima ya kuchukua backup kwanza, na ndiyo sababu tabia ya kufanya upgrade sasa na kuchukua backup baadaye inafeli kwenye mradi mchanga kama huu.

Yasiyothibitishwa hapa

Kuwa mkweli kuhusu umri wa programu hii. Toleo la 0.1.3 lina siku chache tu tangu kutolewa wakati wa kuandika mwongozo huu, maelezo yake ya toleo ni viungo vya changelog vilivyotengenezwa kiotomatiki badala ya maelezo ya uhamiaji, na hakuna rekodi ya maboresho yoyote hadi sasa. Hakuna kitu katika mwongozo huu ambacho ni matokeo ya muda mrefu, kwa hivyo chukulia ukuaji wa kumbukumbu, ukubwa wa database na uthabiti wa scheduler kama mambo ya kupima kwenye seva yako mwenyewe badala ya kuyachukulia kama mambo ya uhakika.

Tabia mbili zinastahili kupimwa na wewe mwenyewe kabla ya kuzitegemea. Kwanza, kama kushusha toleo (downgrade) kunaweza kusoma hali iliyoandikwa na toleo jipya zaidi: jaribu hili kwenye nakala ya volume wakati ambapo hakuna madhara, si wakati wa hitilafu. Pili, nini gateway inafanya wakati Kiro sign-in inapoisha muda wake huku kazi iliyopangwa (scheduled job) ikitakiwa kufanyika. Yote haya ni aina ya changamoto ndogo ambazo mradi mpya huzitatua kimya kimya kati ya matoleo, na zote ni rahisi kuzikagua sasa.

FAQ

Kwa nini dashibodi ya KiroCrew haifunguki kwenye IP ya umma ya seva yangu?

Kwa sababu mfano uliotolewa hufunga port kwenye loopback. -p 127.0.0.1:5476:5476 hupanga port ya container kwenye anwani ya loopback ya host pekee, jambo ambalo ni la makusudi. Ifikie kwa kusambaza (forward) port hiyo kupitia SSH kwa kutumia ssh -N -L 5476:127.0.0.1:5476 you@your-server, kisha ufungue http://localhost:5476/?token=<token> kwenye laptop yako. Kuondoa kiambishi 127.0.0.1: ili kuifanya ipatikane hadharani kutaweka gateway kwenye mtandao wa umma, na sheria ya firewall haitaizuia, kwa sababu sheria za DNAT za Docker za port zilizochapishwa huchunguzwa kabla ya ufw kuchuja trafiki.

KiroCrew huhifadhi data zake wapi, na nini ninachopaswa kuhifadhi (backup)?

Kila kitu kipo chini ya ~/.kiro/crew, ambayo ni /home/kirocrew/.kiro/crew ndani ya image ya container, na KIROCREW_HOME huhamisha eneo hilo. Hifadhi saraka nzima, au Docker volume nzima, huku gateway ikiwa imesimamishwa. memory.db na memory_index.db ni database za SQLite, kwa hivyo nakala inayochukuliwa wakati gateway inaandika inaweza kuwa na hitilafu. Unapohamia kwenye host mpya, workspace/memory/, faili mbili za database na config.json huhamishwa, wakati faili za PID, logi ya matukio ya usalama na .env ni za host ya zamani.

Je, nitumie tag ya stable au tag ya toleo?

Tumia tag ya toleo. stable hubadilika kila wakati toleo jipya linapotoka, kwa hivyo toleo unaloliendesha linaweza kubadilika bila wewe kujua wakati wa pull inayofuata, na tag yenyewe haikupi taarifa yoyote kuhusu kile kinachoendeshwa. Tag za toleo kama 0.1.3 hazibadiliki, na ndiyo sababu hasa inayofanya rollback kufanikiwa: unarudisha namba ya zamani na kupata image inayofanana kabisa. Kufikia tarehe 6 Agosti 2026 toleo jipya zaidi ni 0.1.3.

Kwa nini agent wangu anakataa kuendesha amri zozote?

Container huchunguza uwezo wa sandbox wakati wa kuanza kwake kwa mara ya kwanza. Ikiwa haiwezi kutenga (isolate) subprocesses za agent na KIROCREW_ALLOW_UNSANDBOXED=1 haijawekwa, inakataa kuzitekeleza badala ya kuziendesha bila ulinzi, kwa hivyo gateway inaonekana kuwa nzima wakati kila kazi inakwama. docker logs kirocrew huonyesha uamuzi wa sandbox kutoka kwa uendeshaji huo wa kwanza. Kuweka variable hiyo hufanya container kuwa mpaka pekee kati ya agent na host, kwa hivyo ukiweka, usipandishe (mount) chochote ambacho usingempa agent moja kwa moja.

Je, ninahitaji akaunti ya Kiro ili ku-self-host KiroCrew?

Ndiyo, kufikia Agosti 2026. KiroCrew ni programu huria chini ya Apache 2.0, lakini inaendesha kiro-cli, ambayo inahitaji kuingia (sign-in) mara moja, na inference ya agent hutozwa kwenye mpango wa Kiro. Ndani ya container, endesha docker exec -it kirocrew kiro-cli login na uidhinishe kodi ya kifaa kwenye kivinjari chako. Hadi kuingia huko kukamilike, gateway huanza na dashibodi hupakia, lakini agent hana model ya kuwasiliana nayo.