KiroCrew VPS üzerinde nasıl kurulur ve çalıştırılır

KiroCrew uygulamasını neden dizüstü bilgisayar yerine VPS üzerinde barındırmalısınız

KiroCrew uygulamasını kendi sunucunuzda barındırmak, yalnızca hiç uyumayan bir makinede verim sağlar; bu nedenle bir VPS bunun için doğru yerdir, dizüstü bilgisayar ise değildir. KiroCrew oturum geçmişini, anlamsal belleği, zamanlanmış görevleri ve onay kuyruğunu diskte 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şebilirsiniz. Kendi sunucunuzda barındırdığınız tek şey bu gateway'dir; dolayısıyla 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 bilmeniz gereken iki şey vardır. KiroCrew, bir Kiro hesabı ile tek seferlik oturum açma gerektiren kiro-cli servisini kullanır ve aracı çıkarımı (agent inference) bir Kiro planı üzerinden faturalandırılır; bu nedenle 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 izin verecek ş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 üzerine inşa edildiği temel kuralları kapsar. Aracı tarafı sizin için sunucu tarafına göre daha yeniyse, önce aracı döngüsünün, araçlarının ve belleğinin gerçekte ne olduğunu öğrenmek, aşağıdaki seçenekleri birer büyü gibi değil, bilinçli kararlar olarak okumanızı sağlayacaktır.

KiroCrew 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), dashboard kaynağı derleyecekseniz Node.js 18 veya daha yeni bir sürüm ve ilk çalıştırmada kurulumu ve oturum açma işlemlerini sizin yerinize gerçekleştiren kiro-cli aracını gerektirir. Container kurulumu ise ana makinede bunların hiçbirine ihtiyaç duymaz. Yalnızca 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 konuma 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 ve tam metin dizinleri.
• models/: ilk çalıştırmada indirilen gömme (embedding) modeli.
• gateway.log ve security_events.jsonl: çalışma zamanı günlüğü ve güvenlik olay günlüğü.

Söz konusu dizin, kurulumun kendisidir. Bu dizini yeni bir VPS'e kopyaladığınızda temsilcinizi de 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, temsilcinin çalıştırdığı derleme veya test paketleri gibi işlemlerdir. Durum dizini sohbet geçmişiyle birlikte büyür ve gömme modeli ilk başlatmada indirilir. Bu nedenle, projenin ilk ayında yayınlanan rakamlara güvenmek yerine, birkaç hafta sonra kendi sunucunuzda du -sh ~/.kiro/crew komutuyla ölçüm yapın. Her çalışana kendi container'ını ve tarayıcısını veren bir çalışma zamanı ile bunu kıyaslayın; bu tür yapılarda OpenBot yapay zeka iş arkadaşlarını kendi sunucunuzda barındırma konusu, diskten önce bir RAM kapasitesi sorunu haline gelir.

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 bir 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 bileşenlerini 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 hale gelir.

Görüntüyü 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 seçmediğiniz halde ç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 ve ardından görüntünün kendi HEALTHCHECK kontrolü için de kullandığı sağlık durum 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, bir dakika içerisinde konteynerin sağlıklı olduğunu bildirmelidir ve /api/health, bir token gerektirmeden yanıt verir (/api/live ve /api/ready uç noktaları da aynı şekilde çalışır; bu da onları prob olarak kullanılabilir kılar). Durum starting olarak kalmaya devam ederse, herhangi bir değişiklik yapmadan önce docker logs kirocrew dosyasını okuyun. İlk çalıştırma sırasında gömme (embedding) modeli indirilir, bu nedenle yavaş bir bağlantı ilk başlatma süresini uzatabilir.

systemd ile çalışır durumda tutma

restart: unless-stopped, Docker'ın kendisi önyüklemede 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ığı belirginleştirir ve yedekleme öncesinde tüm yığını durdurmanızı sağlayan tek bir komut sunar. Docker Compose yığınını önyüklemede başlatma genel modeli ele almaktadır. Bunun KiroCrew biçimi /etc/systemd/system/kirocrew.service içinde yer alı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 birlikte Type=oneshot burada doğrudur çünkü docker compose up -d, container başlatılır başlatılmaz 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 pes eder ya da yeniden başlatma döngüsüne girer. Yerel bir kurulum için proje kendi eşdeğeri olan kirocrew service install dosyasını sunar; bu dosya /etc/systemd/system/kirocrew.service yazar ve ağ geçidini sizin kullanıcınız olarak çalıştırır. Her iki unit dosyasını aynı anda çalıştırmayın. Bu konunun daha geniş kapsamlı hali VPS üzerinde systemd servisleri ve zamanlayıcıları başlığındadır. Geri gelmeyen bir unit, siz onu konuşturmadığınız sürece sessiz kalır; bu nedenle kendi ntfy sunucunuza uyarı gönderen bir OnFailure= işleyicisi ekleyin. Böylece ağ geçidinin kapalı olduğunu, hiç çalışmamış zamanlanmış bir işten değil, doğrudan telefonunuzdan öğrenirsiniz.

İlk çalıştırma: oturum açma ve kontrol paneli belirteci alma

Konteyner ağ geçidini başlatır ancak aracı çalışma zamanı 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 kontrol paneli belirteci oluşturun:

docker exec kirocrew kirocrew token --ttl 2h

Kontrol paneli URL adresi http://localhost:5476/?token=<the token> şeklindedir. Belirteçlerin 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 kontrol paneli genellikle süresi dolmuş bir belirteçten kaynaklanır, bu durumda yeni bir tane oluşturun. Bir belirteci asla destek talebi veya sohbet mesajı içine yapıştırmayın; çünkü belirtece sahip olan kişi aracı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 adresini dinler; çünkü port eşlemesi üzerinden erişilebilir olması gerekir, ancak eşlemenin kendisi yalnızca host üzerindeki 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 portlarının ufw'yi atlaması belgesi bu mekanizmayı adım adım 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 makinenizde http://localhost:5476/?token=<the token> adresini açın. Yönlendirmeyi her bağlantıda otomatik hale getirmek için ~/.ssh/config dosyasına 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. İkinci bir aracı sunucuyu paylaştığında bu şekilde yönlendirmeleri üst üste ekliyor olacaksınız, çünkü güvenlik taraması için open-kritt self-hosting işlemi, aynı sunucu üzerinde 5173 numaralı portta başka bir sadece-loopback dashboard oluşturur.

Tünel üzerinden beklenen belgelenmiş bir davranış şudur: Gateway, yönlendirilen istekleri uzak bağlantı olarak okur, bu nedenle dashboard'daki 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ı host ü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

Telefondan erişim için proje, paneli herkese açık bir hostname üzerinde yayınlamak yerine kendi tailnet'iniz içinde tutan Tailscale tailscale serve çözümünü önerir. Bu çözüm, public reverse proxy kullanımına tercih edilmelidir. Token URL içinde taşınır ve URL, geçtiği her erişim loguna yazılır. Bu kural portun kendisinden çok, portun arkasında çalışan bileşenle ilgilidir: Jellyfin kütüphanesini taranabilir bir 90'lar video mağazası olarak yeniden oluşturan Halcyon gibi bir servis, başkalarının erişimine açıktır ve reverse proxy için uygun bir adaydır; ancak sunucunuzda komut çalıştırabilen bir gateway reverse proxy arkasına alınmamalıdır.

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

Konteyner, ilk başlatıldığında sandbox desteğini denetler ve sonuç, aracıların herhangi bir şey çalıştırıp çalıştıramayacağına karar verir. 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çlerin kısıtlamasız çalıştırılması yerine yürütme reddedilir; bu nedenle, her görev duraksarken 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çinde tutulur. Proje ayrıca uygulayabileceğiniz bir seccomp (secure computing mode) profili de yayınlamaktadır:

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ği konusunda net olun: artık aracı ile sunucunuz arasındaki tek sınır konteynerdir. Projenin uyarısını bütünüyle tekrarlamakta fayda var. Doğrudan aracıya vermeyeceğiniz hiçbir ana makine yolunu (host path) mount etmeyin. Uygulamada bu durum; Docker socket, / dizininin herhangi bir bind mount işlemi ve başka bir servisin verilerini tutan herhangi bir dizin için geçerlidir.

Geriye kalan kısım, komut çalıştırmasına izin verilen her aracı için geçerli olan çerçevedir. Kimlik bilgilerini yalnızca ihtiyaç duyduğu bir depo veya 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 az 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, bu compose dosyasındaki herhangi bir bayraktan daha güçlü bir sınırdır, çünkü temizlemek yerine doğrudan silersiniz. Aynı mantık OpenClaw'u bir VPS üzerinde güvenli çalıştırma ve Hermes aracısını bir VPS üzerinde self-host etme süreçlerini de şekillendirir. Araçlar da etki alanına dahildir: aracıya web arama yetkisi vermek, getirdiği her sayfayı güvenilmeyen bir girdi haline getirir; bu nedenle onu kendi SearXNG örneğinize yönlendirmek, bir altyapı kararı olduğu kadar bir prompt injection kararıdır. Zamanlanmış işler siz uyurken de para harcar, çünkü çıkarım (inference) maliyetleri Kiro planınıza yansır; bu yüzden gece çalışacak bir iş eklemeden önce bir VPS üzerinde yapay zeka aracı maliyetlerini 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. Yazma işlemi devam ederken bir veritabanını kopyalamak, yarıda kalmış bir işlemin kaydedilmesine ve geri yükleme sırasında dosyanın bozuk çıkmasına neden olabilir. Projenin kendi taşıma talimatları da aynı şeyi belirtir: verileri yalnızca ağ geçitleri durdurulduğunda taşıyın. Bu "önce durdur" kuralı yalnızca KiroCrew'e özgü değildir; eğer sunucuda bir fotoğraf sunucusu da barındırılıyorsa, PhotoPrism ve Immich karşılaştırması bu iki servisin her biri için gereken kesin yedekleme komutlarını sunar.

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, container durdurulmuş haldeyken 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şınabilir. 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 (pin) 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, imaj sunucuda mevcut değilse onu çeker; bu nedenle etiket düzenlemesi yükseltmenin tamamını oluşturur. Geri alma işlemi de eski numara ile aynı sırayı izler ve size daha önce sahip olduğunuz imajın aynısını verir, çünkü sürüm etiketleri değiştirilemezdir.

İkili dosya (binary) sorunsuz bir şekilde geri döner. Durum (state) ise geri dönmeyebilir. Daha yeni bir gateway, config.json dosyasını yeniden yazabilir veya bellek içi veritabanlarını, eski bir gateway'in okuyamayacağı bir biçime dönüştürebilir; Ağustos 2026 itibarıyla belgelenmiş bir sürüm düşürme (downgrade) yolu bulunmamaktadır. Bu nedenle, eski imaj çalışmaya başlar ve ardından garip davranışlar sergilerse, 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; yükseltmeyi hemen yapıp yedeği sonraya bırakma alışkanlığı, bu kadar yeni bir projede başarısızlıkla sonuçlanır.

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ükleri bağlantılarıdır ve henüz bir yükseltme geçmişi bulunmamaktadır. Bu kılavuzdaki hiçbir şey uzun vadeli bir sonuca dayanmamaktadır; bu nedenle bellek kullanımı, veritabanı boyutu ve zamanlayıcı güvenilirliği gibi unsurları varsayım olarak değil, kendi sunucunuzda ölçmeniz gereken değerler olarak kabul edin.

İki davranışın, onlara bağımlı hale gelmeden önce bizzat test edilmesi faydalıdır. Birincisi, bir sürüm düşürme işleminin daha yeni bir sürüm tarafından yazılan durumu okuyup okuyamadığıdır; bunu bir kesinti sırasında değil, bir sorun teşkil etmeyeceği bir zamanda, birimin bir 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 iki durum da genç bir projenin sürümler arasında sessizce düzelttiği pürüzlerdendir 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 arayüzüne bağladığı için bu durum yaşanır. -p 127.0.0.1:5476:5476, konteynerin portunu yalnızca ana makinenin loopback adresine eşler; bu bilinçli bir tercihtir. Portu ssh -N -L 5476:127.0.0.1:5476 you@your-server ile SSH üzerinden yönlendirerek ve ardından dizüstü bilgisayarınızda http://localhost:5476/?token=<token> adresini açarak erişim sağlayabilirsiniz. 127.0.0.1: önekini kaldırarak erişilebilir hale getirmek, 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 nelerin yedeğini almalıyım?

Her şey ~/.kiro/crew altında bulunur; bu dizin konteyner imajı içinde /home/kirocrew/.kiro/crew konumundadır ve KIROCREW_HOME ile yeri değiştirilebilir. Ağ geçidi durdurulmuş haldeyken tüm dizinin veya tüm Docker volume içeriğinin yedeğini alın. 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'dır.

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

Konteyner, ilk başlatıldığında sandbox desteğini kontrol eder. Ajan alt süreçlerini izole edemezse ve KIROCREW_ALLOW_UNSANDBOXED=1 ayarlanmamışsa, süreçleri kısıtlanmamış bir ş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, konteyneri 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 kendi sunucumda barındırmak 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 üzerinden çalışır; bu da tek seferlik bir oturum açma işlemi gerektirir ve ajan çıkarımı (inference) bir Kiro planı üzerinden faturalandırılır. Konteyner 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 olmaz.