KiroCrew VPS uzerinde nasil barindirilir?

KiroCrew uygulamasını dizüstü bilgisayar yerine neden VPS üzerinde barındırmalıyım?

KiroCrew uygulamasını kendi sunucunuzda barındırmak, yalnızca hiç kapanmayan bir makinede verim sağlar; bu nedenle VPS uygun bir ortamken, dizüstü bilgisayar uygun değildir. KiroCrew oturum geçmişini, anlamsal belleği, zamanlanmış görevleri ve onay kuyruğunu disk üzerinde tutar ve süreç yeniden başlatıldığında tüm bunları tekrar yükler. Zamanlanmış bir görevin vakti geldiğinde, saat 03:00'te süreç çalışmıyorsa bunların hiçbirinin bir faydası olmaz; kapalı bir dizüstü bilgisayar ise bu süreci çalıştırmaz.

KiroCrew, Kiro ekibi tarafından geliştirilen, Apache 2.0 lisansına sahip açık kaynaklı bir aracı çalışma alanıdır ve ilk genel sürümleri 2026 yılının Ağustos ayı başında yayınlanmıştır. Gateway adı verilen tek bir süreç, durumu yönetir ve 5476 numaralı port üzerinden bir web paneli sunar. Bu gateway'e panel üzerinden, kirocrew CLI aracılığıyla veya Slack gibi bir sohbet kanalı üzerinden erişirsiniz. Kendi sunucunuzda barındırdığınız tek bileşen gateway'dir; bu nedenle bu kılavuz, onu nasıl ayakta tutacağınız, genel internete nasıl kapatacağınız ve hatalı bir yükseltme sonrasında nasıl geri yükleyeceğiniz hakkındadır.

Başlamadan önce bilinmesi gereken iki husus vardır. KiroCrew, Kiro hesabı ile tek seferlik bir oturum açmayı gerektiren kiro-cli servisini kullanır ve aracı çıkarımı (agent inference) bir Kiro planı üzerinden faturalandırılır; dolayısıyla 2026 Ağustos ayı itibarıyla bu çevrimdışı bir kurulum değildir. Proje ayrıca henüz birkaç haftalıktır. Bir noktada geri alma işlemi yapmanız gerekeceğini varsayın ve kurulumu buna olanak tanıyacak şekilde gerçekleştirin. Daha önce bir sunucuda hiç aracı çalıştırmadıysanız, VPS üzerinde kodlama aracı çalıştırma başlıklı bölüm, bu kılavuzun temelini oluşturan genel kuralları kapsamaktadır.

KiroCrew'un gereksinimleri ve durum verisinin konumu

Yerel kurulum; Python 3.10 veya daha yeni bir sürüm (proje 3.12 sürümünü önerir), kaynak koddan dashboard oluşturacaksanız Node.js 18 veya daha yeni bir sürüm ve ilk çalıştırmada sizin yerinize kurulumu yapıp oturum açan kiro-cli bileşenini gerektirir. Container kurulumunda ise ana makinede bunların hiçbirine ihtiyaç duyulmaz. Sadece Docker gereklidir. Bu, container kurulumunu tercih etmek için temel nedendir.

Durum verisi ~/.kiro/crew dizininde tutulur ve KIROCREW_HOME ortam değişkeni ile başka bir yere taşınabilir. Bu dizinin içeriği şöyledir:

• config.json: ağ geçidi ayarları ve sohbet kanalı kimlik bilgileri.
• .env: gizli anahtarlar.
• workspace/memory/: tercihler, proje notları ve sohbet geçmişi.
• memory.db ve memory_index.db: anlamsal (semantic) ve tam metin (full-text) dizinleri.
• models/: ilk çalıştırmada indirilen embedding modeli.
• gateway.log ve security_events.jsonl: çalışma zamanı günlüğü ve güvenlik olay günlüğü.

Bu dizin, kurulumun kendisidir. Dizin içeriğini yeni bir VPS'e kopyaladığınızda ajansınızı taşımış olursunuz; bu nedenle aşağıdaki yedekleme bölümü, kurulum bölümünden daha kritiktir.

RAM yerine disk alanını planlayın. Ağ geçidi bir Python sürecidir; sistemi asıl yükleyen şey ajanın çalıştırdığı derleme veya test paketleridir. Durum dizini sohbet geçmişiyle birlikte büyür ve embedding modeli ilk başlatmada indirilir. Bu yüzden, projenin ilk ayında yayınlanan herhangi bir rakama güvenmek yerine, birkaç hafta sonra kendi sunucunuzda du -sh ~/.kiro/crew komutuyla ölçüm yapın.

Hangi kurulum yolunu kullanmalısınız

Proje üç farklı yöntem sunar. Tek satırlık yükleyici bir wheel dosyası indirir ve kirocrew öğesini PATH değişkeninize ekler:

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

Bu yöntem bir kanal bayrağı ve sürüm bayrağı alır:

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 imajı ghcr.io/kirodotdev/kirocrew adresinde, her etiket altında linux/amd64 ve linux/arm64 için yayınlanır. Kaynak koddan derleme işlemi git clone ve make build gerektirir; bu yöntem kodu değiştiren geliştiriciler içindir, uygulamayı çalıştıran kullanıcılar için değildir.

Container kullanın. Yerel kurulum; Python paketlerini, Node ve kiro-cli öğesini diğer servislerinizin çalıştığı aynı ana makineye yerleştirir. Bu nedenle hatalı bir yükseltme işlemi, sistemi elle düzeltmenizi gerektirir. Container ise çalışma zamanını tek bir imajda, durumu ise tek bir volume içinde tutar. Bu sayede geri alma işlemi sadece bir etiket değişikliği ve yeniden başlatmadan ibaret olur.

İmajı bir sürüm etiketine sabitleyin, stable etiketine değil

Projenin kendi örneği stable etiketini kullanmaktadır:

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

stable değişken bir etikettir. En güncel kararlı sürüm hangisiyse onu işaret eder; bu nedenle bir sonraki çekme işleminde, siz tercih etmeseniz dahi çalıştırdığınız sürüm değişebilir ve etiket, hangi sürümün kullanıldığına dair hiçbir kayıt tutmaz. Sürüm etiketleri değiştirilemezdir, bu yüzden bir tanesini sabitleyin. 6 Ağustos 2026 itibarıyla en güncel sürüm, 5 Ağustos 2026 tarihinde yayınlanan 0.1.3 etiketidir. Ayrıca, bu kadar yeni bir projede kodun bu sabah değiştiği anlamına gelen bir nightly etiketi de mevcuttur.

/opt/kirocrew/compose.yaml dosyasını yazın:

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:

Servisi başlatın, ardından imajın kendi HEALTHCHECK kontrolü için de kullandığı sağlık uç noktasını denetleyin:

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

docker compose ps, container durumunun bir dakika içinde sağlıklı olduğunu bildirmelidir ve /api/health, herhangi bir token gerektirmeden yanıt verir (/api/live ve /api/ready uç noktaları da aynı şekilde çalışır; bu durum onları probe olarak kullanılabilir kılar). Eğer durum starting olarak kalırsa, herhangi bir değişiklik yapmadan önce docker logs kirocrew dosyasını okuyun. İlk çalıştırma sırasında embedding modeli indirilir, bu nedenle yavaş bir bağlantı ilk başlatma süresini uzatabilir.

systemd ile servisi çalışır durumda tutma

restart: unless-stopped, Docker'ın kendisi açılışta başladığı sürece, bir çökme sonrasında veya yeniden başlatmanın ardından container'ı tekrar ayağa kaldırır. Bir unit dosyası bu bağımlılığı açık hale getirir ve yedekleme öncesinde tüm yığını durdurmanızı sağlayan tek bir komut sunar. Docker Compose yığınını açılışta başlatma bölümü genel modeli ele almaktadır. Bunun KiroCrew biçimi /etc/systemd/system/kirocrew.service dosyasındadır:

[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, bu unit için sağlıklı sonuç olan active (exited) değerini okumalıdır. RemainAfterExit=yes ile Type=oneshot burada kullanılmalıdır çünkü docker compose up -d, container başlatıldığı anda geri döner: systemd, ön planda çalışan bir süreci değil, yığının ayakta olduğu gerçeğini takip eder. Bunun yerine Type=simple yazarsanız, systemd komutun hemen sonlandığını görür, servisi ölü olarak işaretler ve Restart= ayarınıza bağlı olarak ya vazgeçer ya da yeniden başlatma döngüsüne girer. Yerel bir kurulum için proje, kendi eşdeğeri olan ve /etc/systemd/system/kirocrew.service dosyasını yazıp ağ geçidini kullanıcınız olarak çalıştıran kirocrew service install birimini sunar. Her iki unit dosyasını aynı anda çalıştırmayın. Bu konunun daha kapsamlı hali VPS üzerinde systemd servisleri ve zamanlayıcılar bölümündedir.

İlk çalıştırma: oturum açma ve dashboard token alma

Konteyner gateway'i başlatır ancak agent runtime henüz oturum açmamıştır. Konteyner içinde oturum açın:

docker exec -it kirocrew kiro-cli login

Bu komut bir cihaz kodu ve kendi tarayıcınızda açmanız gereken bir URL çıktısı verir. Ardından bir dashboard token oluşturun:

docker exec kirocrew kirocrew token --ttl 2h

Dashboard URL adresi http://localhost:5476/?token=<the token> şeklindedir. Token'ların süresi dolar: oturumlar varsayılan olarak bir saat sürer ve belgelenen maksimum süre yirmi saattir. Boş yüklenen veya sizi doğrudan dışarı atan bir dashboard genellikle süresi dolmuş bir token'a işaret eder; bu durumda yeni bir tane oluşturun. Bir token'ı asla destek talebine veya sohbet mesajına yapıştırmayın; çünkü token'a sahip olan kişi agent'ınızın kontrolünü ele geçirmiş olur.

Dashboard'a SSH üzerinden erişin ve 5476 numaralı portu asla dışarıya açmayın

Projenin örneğindeki bind adresini tekrar inceleyin: -p 127.0.0.1:5476:5476. Gateway, container içerisinde 0.0.0.0 adresinde dinleme yapar; çünkü port eşlemesi üzerinden erişilebilir olması gerekir, ancak eşlemenin kendisi ana makinede (host) yalnızca loopback arayüzüne yayın yapar. 127.0.0.1: önekini silerseniz, gateway o portu tarayan herkes için genel internete açık hale gelir. Bir güvenlik duvarı kuralı da sizi kurtarmaz: Docker, portları ufw filtrelemesinden önce değerlendirilen DNAT kuralları yazarak yayınlar, bu nedenle ufw deny 5476 yayınlanmış bir port üzerinde hiçbir işe yaramaz. Docker portlarinin ufw'yi baypas etmesi bu mekanizmayı detaylıca açıklar.

Bunun yerine portu dizüstü bilgisayarınızdan SSH üzerinden yönlendirin:

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

Bu komutu çalışır durumda bırakın ve yerel olarak http://localhost:5476/?token=<the token> adresini açın. Yönlendirmeyi her bağlantıda otomatik hale getirmek için ~/.ssh/config içerisine ekleyin:

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

Eğer 5476 numaralı port dizüstü bilgisayarınızda zaten kullanımdaysa, yalnızca soldaki sayıyı değiştirin: ssh -N -L 45476:127.0.0.1:5476 you@your-server.example.com, ardından http://localhost:45476/?token=... adresine gidin.

Tünel üzerinden erişimde beklenen belgelenmiş bir davranış şudur: Gateway, yönlendirilen istekleri uzak (remote) olarak algılar, bu nedenle dashboard üzerindeki config-write ve secret-reveal uç noktaları bu istekleri reddeder. SSH üzerinden kaydedilmeyen bir ayar değişikliği bir hata değil, bu durumun bir sonucudur. Bunun yerine yapılandırmayı ana makine üzerinde düzenleyin:

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

Mobil erişim için proje, dashboard'u genel bir ana makine adı yerine kendi tailnet'iniz içinde tutan Tailscale tailscale serve çözümünü işaret eder. Bunu, genel bir reverse proxy kullanımına tercih edin. Token URL içerisinde taşınır ve bir URL, yolundaki her erişim günlüğüne (access log) yazılır.

Aracıya mümkün olan en küçük etki alanını tanıyın

Container, ilk başlatıldığında sandbox desteğini denetler ve sonuç, aracıların herhangi bir şey çalıştırıp çalıştıramayacağını belirler. Namespace izolasyonu mevcutsa, aracı alt süreçleri izole bir şekilde çalışır. Eğer izolasyon mevcut değilse ve KIROCREW_ALLOW_UNSANDBOXED=1 ayarlanmamışsa, süreçler kısıtlanmamış (unconfined) bir şekilde çalıştırılmak yerine reddedilir; bu nedenle, her görev askıda kalırken sağlıklı görünen bir ağ geçidi genellikle bu durumdan kaynaklanır. Karar, ilk çalıştırmadan itibaren docker logs kirocrew içerisinde tutulur. Proje ayrıca uygulayabileceğiniz bir seccomp (secure computing mode) profili de yayınlar:

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

Eğer KIROCREW_ALLOW_UNSANDBOXED=1 ayarını yaparsanız, neyin değiştiğinin farkında olun: artık aracı ile sunucunuz arasındaki tek sınır container'dır. Projenin uyarısını bütünüyle yinelemekte fayda var. Doğrudan aracıya vermeyeceğiniz hiçbir host yolunu mount etmeyin. Uygulamada bu durum; Docker socket'ini, / dizininin herhangi bir bind mount işlemini ve başka bir servisin verisini tutan tüm dizinleri kapsam dışı bırakır.

Geriye kalan kısım, komut çalıştırmasına izin verilen her aracı için geçerli olan çerçevedir. Kimlik bilgilerini, ihtiyaç duyduğu tek bir depo veya tek bir bucket ile sınırlandırın; asla hesap genelinde yetkilere sahip kişisel bir token kullanmayın. Aracıyı, ev dizininde başka hiçbir şey bulunmayan özel bir kullanıcı olarak çalıştırın; VPS üzerinde en düşük yetkili kullanıcılar rehberinin amacı budur. Aracı kod yazıp ardından bu kodu çalıştırdığında, ona bozmasına izin verilen bir makine verin: kodlama aracıları için tek kullanımlık VM kullanımı, bu compose dosyasındaki herhangi bir bayraktan daha güçlü bir sınırdır çünkü temizlemek yerine makineyi silersiniz. Aynı mantık OpenClaw'u VPS üzerinde güvenli çalıştırma ve Hermes aracısını VPS üzerinde self-host etme süreçlerini de şekillendirir. Araçlar da etki alanına dahildir: aracıya web araması yetkisi vermek, getirdiği her sayfayı güvenilmeyen bir girdi haline getirir; bu nedenle kendi SearXNG örneğinize yönlendirme yapmak, teknik bir altyapı kararı olduğu kadar bir prompt injection kararıdır. Planlanmış işler siz uyurken de para harcar, çünkü çıkarım (inference) işlemleri Kiro planınıza faturalandırılır; bu yüzden gece çalışacak bir iş eklemeden önce bir yapay zeka aracısının VPS maliyetini kontrol etme bölümünde açıklanan limitleri ayarlayın.

Her yükseltme öncesinde durum birimini yedekleyin

Önce gerçek birim adını bulun. Compose, adlandırılmış birimleri proje adıyla önekler; proje adı varsayılan olarak dizin adıdır. Bu nedenle kirocrew-home içinde /opt/kirocrew/compose.yaml olarak tanımlanan birim, kirocrew_kirocrew-home şeklinde oluşturulur:

docker volume ls

Herhangi bir kopyalama işlemi yapmadan önce ağ geçidini durdurun. memory.db ve memory_index.db SQLite veritabanlarıdır. Veritabanı yazma işlemi devam ederken kopyalamak, yarım kalmış bir işlemin yakalanmasına neden olabilir; bu da geri yükleme sırasında bozuk bir dosya ile sonuçlanır. Projenin kendi taşıma talimatları da aynı şeyi belirtir: belleği yalnızca ağ geçitleri durdurulmuş durumdayken taşıyın.

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

Arşivi sunucudan dışarı kopyalayın. Geri yükleme işlemi, konteyner durdurulmuş ve tar czf yerine tar xzf kullanılarak aynı komutla gerçekleştirilir:

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

Yeni bir sunucuya geçiş yapmak, yerinde geri yükleme yapmaktan farklı bir işlemdir ve proje bu konuda özel talimatlar içerir. workspace/memory/ altındaki sohbet geçmişi ve proje notları, iki veritabanı dosyası ve config.json ile birlikte taşınır. PID dosyaları, güvenlik olay günlüğü ve .env eski sunucuya bağlıdır; bu nedenle bunları geride bırakın ve yeni sunucuda gizli bilgileri (secrets) yeniden girin.

Hatalı bir yükseltme işlemi nasıl geri alınır

Yükseltme işlemi kısa sürer ve yalnızca bir sürümü sabitlediğiniz için güvenlidir. Önce yedeği alın, ardından etiketi değiştirin:

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, görüntü sunucuda mevcut değilse onu çeker, bu nedenle etiket düzenlemesi yükseltmenin tamamıdır. Geri alma işlemi, eski numara ile aynı sırayı takip eder ve size daha önce sahip olduğunuz görüntünün aynısını verir; çünkü sürüm etiketleri değiştirilemezdir.

İkili dosya sorunsuz bir şekilde geri döner. Durum (state) kısmı ise sorun çıkarabilir. Daha yeni bir ağ geçidi (gateway), config.json dosyasını yeniden yazabilir veya bellek içi veritabanlarını, eski bir ağ geçidinin okuyamayacağı bir biçime dönüştürebilir; Ağustos 2026 itibarıyla belgelenmiş bir sürüm düşürme yolu bulunmamaktadır. Bu nedenle, eski görüntü çalışmaya başlar ve ardından garip davranırsa, hata ayıklamaya çalışmayın. Servisi durdurun, yükseltme öncesinde aldığınız yedeği geri yükleyin ve yeniden başlatın. Yedeğin ilk sırada alınmasının tek nedeni budur ve bu kadar yeni bir projede önce yükseltme yapıp sonra yedek alma alışkanlığının başarısız olmasının sebebi de budur.

Burada kanıtlanmamış olanlar

Bu yazılımın yaşı konusunda dürüst olun. 0.1.3 sürümü, bu metnin yazıldığı tarihte henüz birkaç günlüktür; sürüm notları geçiş rehberinden ziyade otomatikleştirilmiş değişiklik günlükleridir ve henüz bir yükseltme geçmişi bulunmamaktadır. Bu kılavuzdaki hiçbir şey uzun vadeli sonuçlara dayanmamaktadır; bu nedenle bellek kullanımı, veritabanı boyutu ve zamanlayıcı güvenilirliği gibi konuları varsayım olarak değil, kendi sunucunuzda ölçmeniz gereken değerler olarak kabul edin.

İki davranış, onlara bağımlı hale gelmeden önce bizzat test edilmeye değerdir. Birincisi, bir sürüm düşürme işleminin daha yeni bir sürüm tarafından yazılmış durumu okuyup okuyamadığıdır; bunu bir kesinti sırasında değil, bir sorun teşkil etmediği bir zamanda birim kopyası üzerinde deneyin. İkincisi, zamanlanmış bir işin zamanı geldiğinde Kiro oturum açma süresi dolarsa ağ geçidinin ne yaptığıdır. Her ikisi de genç bir projenin sürümler arasında sessizce düzelttiği türden pürüzlerdir ve her ikisini de şimdi kontrol etmenin maliyeti düşüktür.

FAQ

KiroCrew paneli sunucumun genel IP adresi üzerinden neden açılmıyor?

Yayınlanan örnek, portu loopback adresine bağladığı için bu durum yaşanır. -p 127.0.0.1:5476:5476, container portunu yalnızca ana makinenin loopback adresine eşler; bu bilinçli bir tercihtir. Panele erişmek için ssh -N -L 5476:127.0.0.1:5476 you@your-server ile portu SSH üzerinden yönlendirin ve ardından dizüstü bilgisayarınızda http://localhost:5476/?token=<token> adresini açın. Erişilebilir kılmak için 127.0.0.1: önekini kaldırmak, ağ geçidini genel internete açar. Docker'ın yayınlanan port DNAT kuralları, ufw filtrelerinden önce değerlendirildiği için bir güvenlik duvarı kuralı bu trafiği engelleyemez.

KiroCrew verilerini nerede saklar ve neleri yedeklemeliyim?

Her şey ~/.kiro/crew altında bulunur; bu dizin container imajı içinde /home/kirocrew/.kiro/crew konumundadır ve KIROCREW_HOME ile yeri değiştirilebilir. Ağ geçidi durdurulmuş haldeyken tüm dizini veya tüm Docker volume alanını yedekleyin. memory.db ve memory_index.db SQLite veritabanlarıdır; bu nedenle ağ geçidi yazma işlemi yaparken alınan bir kopya tutarsız olabilir. Yeni bir ana makineye taşınırken workspace/memory/, iki veritabanı dosyası ve config.json taşınmalıdır; PID dosyaları, güvenlik olay günlüğü ve .env ise eski ana makineye aittir.

stable etiketini mi yoksa bir sürüm etiketini mi kullanmalıyım?

Sürüm etiketi kullanın. stable, her yeni sürüm yayınlandığında değişir; bu nedenle bir sonraki çekme işleminde çalıştırdığınız sürüm değişebilir ve etiketin kendisi neyin çalıştığına dair bilgi vermez. 0.1.3 gibi sürüm etiketleri değiştirilemezdir; geri alma (rollback) işleminin çalışmasını sağlayan tam olarak budur: eski numarayı geri yüklersiniz ve aynı imajı elde edersiniz. 6 Ağustos 2026 itibarıyla en yeni sürüm 0.1.3'tir.

Ajanım neden herhangi bir komutu çalıştırmayı reddediyor?

Container, ilk başlatıldığında sandbox desteğini denetler. Ajan alt süreçlerini izole edemezse ve KIROCREW_ALLOW_UNSANDBOXED=1 ayarlanmamışsa, bunları kısıtlanmamış şekilde çalıştırmak yerine yürütmeyi reddeder. Bu durumda ağ geçidi sağlıklı görünür ancak tüm görevler durur. docker logs kirocrew, ilk çalıştırmadan elde edilen sandbox kararını gösterir. Bu değişkeni ayarlamak, container'ı ajan ile ana makine arasındaki tek sınır haline getirir; bu nedenle değişkeni ayarlarsanız, doğrudan ajana vermeyeceğiniz hiçbir şeyi mount etmeyin.

KiroCrew'u self-host etmek için bir Kiro hesabına ihtiyacım var mı?

Evet, Ağustos 2026 itibarıyla gereklidir. KiroCrew, Apache 2.0 lisanslı özgür bir yazılımdır ancak kiro-cli servisini kullanır; bu servis tek seferlik bir oturum açma gerektirir ve ajan çıkarımı (inference) bir Kiro planı üzerinden faturalandırılır. Container içinde docker exec -it kirocrew kiro-cli login komutunu çalıştırın ve tarayıcınızda cihaz kodunu onaylayın. Bu oturum açma işlemi tamamlanana kadar ağ geçidi başlar ve panel yüklenir ancak ajanın iletişim kurabileceği bir model bulunmaz.