Jak zainstalować KiroCrew na VPS w kontenerze Docker

Dlaczego warto hostować KiroCrew na VPS zamiast na laptopie

Samodzielne hostowanie KiroCrew ma sens tylko na maszynie, która nigdy nie przechodzi w stan uśpienia, dlatego VPS jest właściwym środowiskiem, w przeciwieństwie do laptopa. KiroCrew przechowuje historię sesji, pamięć semantyczną, zaplanowane zadania oraz kolejkę zatwierdzeń na dysku i wczytuje te dane przy każdym restarcie procesu. Mechanizmy te nie działają, jeśli proces nie jest uruchomiony o godzinie 03:00, gdy przypada termin zaplanowanego zadania, a zamknięty laptop nie zapewnia ciągłości pracy.

KiroCrew to otwartoźródłowe środowisko pracy dla agentów od zespołu Kiro, udostępnione na licencji Apache 2.0, którego pierwsze publiczne wydania pojawiły się na początku sierpnia 2026 roku. Jeden proces, zwany gateway, zarządza stanem i udostępnia pulpit nawigacyjny przez port 5476. Dostęp do gatewaya uzyskuje się z poziomu pulpitu, za pomocą kirocrew CLI lub kanału czatu, takiego jak Slack. Gateway jest jedynym komponentem hostowanym samodzielnie, dlatego niniejszy przewodnik skupia się na utrzymaniu jego ciągłej pracy, izolacji od publicznego Internetu oraz możliwości przywrócenia systemu po nieudanej aktualizacji.

Dwie kwestie wymagają uwagi przed rozpoczęciem. KiroCrew obsługuje kiro-cli, co wymaga jednorazowego zalogowania się na konto Kiro, a wnioskowanie agenta jest rozliczane w ramach planu Kiro, więc według stanu na sierpień 2026 roku nie jest to konfiguracja działająca w trybie offline. Projekt jest również bardzo młody. Należy założyć konieczność wycofania zmian w przyszłości i przeprowadzić instalację w sposób to umożliwiający. Jeśli użytkownik nie uruchamiał wcześniej agenta na serwerze, uruchamianie agenta programistycznego na VPS zawiera podstawowe zasady, na których opiera się ten przewodnik. Jeśli kwestie związane z agentami są mniej znane niż administracja serwerami, zrozumienie pętli agenta, jego narzędzi i pamięci pozwoli na podejmowanie świadomych decyzji zamiast stosowania gotowych poleceń bez ich analizy.

Czego wymaga KiroCrew i gdzie przechowywany jest jego stan

Instalacja natywna wymaga środowiska Python 3.10 lub nowszego (projekt zaleca 3.12), Node.js 18 lub nowszego w przypadku budowania panelu ze źródeł oraz kiro-cli, którego instalacja i logowanie odbywają się automatycznie przy pierwszym uruchomieniu. Instalacja kontenerowa nie wymaga żadnego z powyższych na hoście. Wymaga jedynie Docker. Jest to główny powód, dla którego warto ją wybrać.

Stan przechowywany jest w ~/.kiro/crew, a zmienna środowiskowa KIROCREW_HOME pozwala na przeniesienie go w inne miejsce. Zawartość katalogu:

• config.json: ustawienia bramy i dane uwierzytelniające kanałów czatu.
• .env: sekrety.
• workspace/memory/: preferencje, notatki projektowe i historia czatu.
• memory.db oraz memory_index.db: indeksy semantyczne i pełnotekstowe.
• models/: model osadzeń (embedding model), pobierany przy pierwszym uruchomieniu.
• gateway.log oraz security_events.jsonl: dziennik uruchomieniowy oraz dziennik zdarzeń bezpieczeństwa.

Ten katalog stanowi całą instalację. Skopiowanie go na nowy serwer VPS przenosi agenta, dlatego sekcja dotycząca kopii zapasowych jest ważniejsza niż sekcja instalacji.

Należy planować zasoby pod kątem dysku, a nie pamięci RAM. Brama jest procesem Python; obciążenie serwera zależy od tego, co uruchamia agent, na przykład kompilacji lub zestawu testów. Katalog stanu powiększa się wraz z historią czatu, a model osadzeń jest pobierany przy pierwszym starcie, dlatego po kilku tygodniach należy sprawdzić zajętość za pomocą du -sh ~/.kiro/crew na własnej maszynie, zamiast polegać na danych publikowanych w pierwszym miesiącu projektu. Warto porównać to ze środowiskiem uruchomieniowym, w którym każdy pracownik otrzymuje własny kontener i przeglądarkę, gdzie samodzielne hostowanie współpracowników AI OpenBot sprawia, że szacowanie zasobów staje się kwestią pamięci RAM, zanim stanie się kwestią miejsca na dysku.

Którą z trzech ścieżek instalacji wybrać

Projekt udostępnia trzy warianty. Instalator jednowierszowy pobiera wheel i umieszcza kirocrew w zmiennej PATH:

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

Przyjmuje on flagę kanału oraz flagę wersji:

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

Obraz kontenerowy jest publikowany pod adresem ghcr.io/kirodotdev/kirocrew, dla architektur linux/amd64 oraz linux/arm64 pod każdym tagiem. Budowanie ze źródeł wymaga git clone oraz make build i jest przeznaczone dla osób modyfikujących kod, a nie dla użytkowników końcowych.

Należy używać kontenera. Instalacja natywna umieszcza pakiety Python, Node oraz kiro-cli na tym samym hoście, na którym działają inne usługi, więc nieudana aktualizacja wymusza ręczne usuwanie skutków awarii. Kontener przechowuje środowisko uruchomieniowe w jednym obrazie, a stan w jednym wolumenie, co sprawia, że wycofanie zmian sprowadza się do zmiany tagu i restartu.

Przypnij obraz do konkretnej wersji, a nie do stable

Własny przykład projektu używa tagu stable:

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

stable to tag zmienny. Wskazuje on zawsze na najnowszą stabilną wersję, więc kolejne pobranie obrazu może zmienić uruchomioną wersję bez ingerencji użytkownika, a sam tag nie przechowuje informacji o tym, która to była wersja. Tagi wersji są niezmienne, dlatego należy przypiąć konkretny z nich. Najnowsza wersja na dzień 6 sierpnia 2026 to 0.1.3, opublikowana 5 sierpnia 2026. Dostępny jest również tag nightly, co w przypadku tak młodego projektu oznacza, że kod zmienił się dzisiaj rano.

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

Uruchom kontener, a następnie sprawdź endpoint stanu (health endpoint), którego obraz używa również do własnego HEALTHCHECK:

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

docker compose ps powinien zgłosić stan kontenera jako healthy w ciągu około minuty, a /api/health odpowiada bez tokena (podobnie jak /api/live oraz /api/ready, co umożliwia ich wykorzystanie jako sondy). Jeśli stan pozostaje starting, przed wprowadzeniem jakichkolwiek zmian przeczytaj docker logs kirocrew. Pierwsze uruchomienie pobiera model embeddingów, więc wolne łącze może wydłużyć czas startu.

Utrzymywanie ciągłości działania za pomocą systemd

restart: unless-stopped przywraca kontener po awarii oraz po restarcie systemu, o ile usługa Docker uruchamia się podczas startu. Plik jednostki (unit file) czyni tę zależność jawną i udostępnia jedno polecenie zatrzymujące cały stos przed wykonaniem kopii zapasowej. Uruchamianie stosu Docker Compose przy starcie systemu omawia ogólny schemat. Oto postać tego rozwiązania w stylu KiroCrew, zawarta w /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 powinno zwracać active (exited), co jest prawidłowym stanem dla tej jednostki. Type=oneshot z RemainAfterExit=yes jest tutaj właściwe, ponieważ docker compose up -d kończy działanie natychmiast po uruchomieniu kontenera: systemd monitoruje fakt, że stos jest aktywny, a nie proces działający na pierwszym planie. Wpisanie Type=simple spowoduje, że systemd odnotuje natychmiastowe zakończenie polecenia, oznaczy usługę jako nieaktywną, a następnie zrezygnuje lub wpadnie w pętlę restartów, w zależności od ustawienia Restart=. W przypadku instalacji natywnej projekt dostarcza własny odpowiednik, kirocrew service install, który zapisuje /etc/systemd/system/kirocrew.service i uruchamia bramę z uprawnieniami użytkownika. Nie należy uruchamiać obu jednostek jednocześnie. Szersze omówienie tego tematu znajduje się w usługi i timery systemd na VPS. Jednostka, która nie uruchamia się ponownie, nie generuje powiadomień, chyba że zostanie to skonfigurowane, dlatego warto dodać procedurę obsługi OnFailure=, która wysyła alert na własny serwer ntfy. Dzięki temu informacja o awarii bramy dotrze na telefon, zamiast czekać na wynik zaplanowanego zadania, które nigdy się nie wykonało.

Pierwsze uruchomienie: logowanie i uzyskanie tokena panelu

Kontener uruchamia bramę, jednak środowisko uruchomieniowe agenta nie jest jeszcze zalogowane. Zaloguj się wewnątrz kontenera:

docker exec -it kirocrew kiro-cli login

Polecenie to wyświetli kod urządzenia oraz adres URL, który należy otworzyć w przeglądarce. Następnie wygeneruj token panelu:

docker exec kirocrew kirocrew token --ttl 2h

Adres URL panelu to http://localhost:5476/?token=<the token>. Tokeny wygasają: sesje domyślnie trwają godzinę, a udokumentowane maksimum wynosi dwadzieścia godzin. Jeśli panel ładuje się jako pusty lub następuje natychmiastowe wylogowanie, zazwyczaj oznacza to wygaśnięcie tokena; należy wówczas wygenerować nowy. Nigdy nie wklejaj tokena w zgłoszeniach serwisowych ani wiadomościach na czacie, ponieważ osoba posiadająca token przejmuje kontrolę nad agentem.

Dostęp do panelu przez SSH bez wystawiania portu 5476

Należy ponownie przeanalizować adres powiązania w przykładzie projektu: -p 127.0.0.1:5476:5476. Wewnątrz kontenera bramka nasłuchuje na 0.0.0.0, co jest konieczne dla poprawnego mapowania portów, jednak samo mapowanie ogranicza się wyłącznie do interfejsu loopback na hoście. Usunięcie prefiksu 127.0.0.1: spowoduje wystawienie bramki na publiczny dostęp dla każdego, kto przeskanuje ten port. Reguła firewalla nie zapewni ochrony: Docker publikuje porty poprzez tworzenie reguł DNAT, które są przetwarzane przed filtrowaniem ufw, dlatego ufw deny 5476 nie ma wpływu na opublikowany port. Artykuł Docker ports bypassing ufw szczegółowo opisuje ten mechanizm.

Zamiast tego należy przekierować port przez SSH z poziomu lokalnego komputera:

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

Po uruchomieniu tego polecenia należy otworzyć http://localhost:5476/?token=<the token> w lokalnej przeglądarce. Aby zautomatyzować przekierowanie przy każdym połączeniu, należy dodać odpowiedni wpis do ~/.ssh/config:

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

Jeśli port 5476 jest już zajęty na lokalnym komputerze, należy zmienić tylko pierwszą liczbę: ssh -N -L 45476:127.0.0.1:5476 you@your-server.example.com, a następnie przejść pod adres http://localhost:45476/?token=.... Takie przekierowania będą nakładane warstwowo w momencie, gdy drugi agent zacznie współdzielić serwer, ponieważ self-hosting open-kritt for security scanning uruchamia kolejny panel dostępny tylko przez loopback na tym samym serwerze, na porcie 5173.

Należy uwzględnić udokumentowane zachowanie podczas pracy przez tunel: bramka interpretuje przekierowane żądania jako zdalne, przez co punkty końcowe służące do zapisu konfiguracji oraz odczytu sekretów odrzucają je. Brak możliwości zapisu ustawień przez SSH jest zamierzonym zachowaniem, a nie błędem. Konfigurację należy edytować bezpośrednio na hoście:

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

W przypadku dostępu z telefonu projekt wskazuje na tailscale serve firmy Tailscale, które utrzymuje panel w obrębie własnego tailnetu zamiast udostępniać go pod publiczną nazwą hosta. Takie rozwiązanie należy preferować zamiast publicznego reverse proxy. Token znajduje się w URL, a URL jest zapisywany w każdym dzienniku dostępu na całej ścieżce żądania. Ta zasada dotyczy tego, co znajduje się za portem, a nie samego portu: rozwiązanie takie jak Halcyon, które odtwarza bibliotekę Jellyfin jako przeglądalny sklep z nagraniami wideo z lat 90. jest przeznaczone do udostępniania innym osobom i stanowi uzasadniony przypadek użycia reverse proxy, natomiast brama, która może wykonywać polecenia na serwerze, nie.

Zapewnienie agentowi najmniejszego możliwego obszaru rażenia

Kontener podczas pierwszego uruchomienia sprawdza obsługę piaskownicy (sandbox), a wynik tego testu decyduje o tym, czy agenci mogą cokolwiek wykonywać. Jeśli izolacja przestrzeni nazw (namespace isolation) jest dostępna, podprocesy agenta działają w izolacji. Jeśli nie jest dostępna, a KIROCREW_ALLOW_UNSANDBOXED=1 nie zostało ustawione, wykonywanie zadań jest odrzucane zamiast uruchamiania ich bez ograniczeń. Dlatego brama, która wydaje się sprawna, podczas gdy wszystkie zadania stoją w miejscu, zazwyczaj wynika z tego problemu. Decyzja jest zapisana w docker logs kirocrew od momentu pierwszego uruchomienia. Projekt udostępnia również profil seccomp (secure computing mode), który można zastosować:

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

Jeśli ustawisz KIROCREW_ALLOW_UNSANDBOXED=1, miej świadomość zmian: kontener staje się jedyną barierą między agentem a serwerem. Ostrzeżenie projektu warto przytoczyć w całości. Nie montuj ścieżek hosta, których nie przekazałbyś bezpośrednio agentowi. W praktyce wyklucza to Docker socket, wszelkie dowiązania (bind mount) / oraz każdy katalog przechowujący dane innej usługi.

Reszta to ramy stosowane do każdego agenta, któremu zezwolono na wykonywanie poleceń. Ogranicz jego poświadczenia do jednego repozytorium lub jednego zasobnika (bucket), którego potrzebuje; nigdy nie używaj tokena osobistego z uprawnieniami do całego konta. Uruchamiaj go jako dedykowanego użytkownika, którego katalog domowy nie zawiera niczego innego, co jest celem użytkowników z minimalnymi uprawnieniami na VPS. Gdy agent pisze kod, a następnie go uruchamia, zapewnij mu maszynę, którą może zepsuć: jednorazowa maszyna wirtualna dla agentów programistycznych stanowi silniejszą barierę niż jakakolwiek flaga w tym pliku compose, ponieważ usuwasz ją zamiast czyścić. To samo rozumowanie kształtuje bezpieczne uruchamianie OpenClaw na VPS oraz samodzielne hostowanie agenta Hermes na VPS. Narzędzia również wliczają się do obszaru rażenia: umożliwienie agentowi przeszukiwania sieci sprawia, że każda pobrana strona staje się niezaufanym danymi wejściowymi, więc skierowanie go na własną instancję SearXNG jest decyzją dotyczącą zarówno wstrzykiwania promptów (prompt injection), jak i konfiguracji infrastruktury. Zaplanowane zadania generują koszty również podczas snu, ponieważ wnioskowanie (inference) obciąża plan Kiro, dlatego przed dodaniem nocnego zadania ustaw limity opisane w kontrolowaniu kosztów agenta AI na VPS.

Tworzenie kopii zapasowej wolumenu stanu przed każdą aktualizacją

Najpierw należy ustalić rzeczywistą nazwę wolumenu. Compose dodaje prefiks nazwy projektu do nazwanych wolumenów; domyślnie jest to nazwa katalogu, więc wolumen zadeklarowany jako kirocrew-home w /opt/kirocrew/compose.yaml tworzony jest jako kirocrew_kirocrew-home:

docker volume ls

Przed skopiowaniem jakichkolwiek danych należy zatrzymać bramę. memory.db oraz memory_index.db to bazy danych SQLite, a kopiowanie bazy danych w trakcie zapisu może spowodować przechwycenie niepełnej transakcji, co przy przywracaniu skutkuje uszkodzeniem pliku. Instrukcje migracji projektu wskazują na to samo: przenoszenie danych z pamięci powinno odbywać się wyłącznie przy zatrzymanych bramach. Ta zasada nie dotyczy tylko KiroCrew; jeśli na serwerze działa również serwer zdjęć, porównanie PhotoPrism i Immich zawiera dokładne polecenia kopii zapasowej wymagane dla każdej z tych usług.

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

Skopiuj archiwum poza serwer. Przywracanie danych odbywa się za pomocą tego samego polecenia przy zatrzymanym kontenerze, z użyciem tar xzf zamiast 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

Przenoszenie na nowy host to zadanie inne niż przywracanie danych w tej samej lokalizacji, a dokumentacja projektu precyzuje ten proces. Historia czatów i notatki projektowe w workspace/memory/ są przenoszone, podobnie jak dwa pliki baz danych oraz config.json. Pliki PID, dziennik zdarzeń bezpieczeństwa oraz .env są powiązane ze starym hostem, dlatego należy je pominąć, a na nowym serwerze ponownie wprowadzić sekrety.

Jak wycofać nieudaną aktualizację

Aktualizacja jest krótka i bezpieczna tylko dzięki przypięciu wersji. Najpierw wykonaj kopię zapasową, a następnie zmień 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 pobiera obraz, jeśli nie znajduje się on jeszcze na serwerze, więc edycja tagu stanowi całą procedurę aktualizacji. Wycofanie zmian przebiega w tej samej sekwencji przy użyciu starego numeru wersji; przywraca to dokładnie ten sam obraz, który był używany wcześniej, ponieważ tagi wersji są niezmienne.

Plik binarny wycofuje się bez problemów. Stan aplikacji może jednak sprawiać trudności. Nowsza bramka może nadpisać config.json lub przeprowadzić migrację baz danych w pamięci do formatu, którego starsza wersja nie odczyta, a na sierpień 2026 r. nie udokumentowano ścieżki downgrade'u. Jeśli starszy obraz uruchomi się, ale będzie działał nieprawidłowo, nie należy przeprowadzać debugowania. Należy go zatrzymać, przywrócić kopię zapasową wykonaną przed aktualizacją i rozpocząć proces od nowa. To jedyny powód, dla którego kopia zapasowa jest priorytetem, oraz przyczyna, dla której nawyk aktualizowania przed wykonaniem kopii zapasowej zawodzi w tak młodym projekcie.

Czego tutaj nie udowodniono

Należy zachować uczciwość w kwestii wieku tego oprogramowania. Wersja 0.1.3 ma zaledwie kilka dni w momencie pisania tego tekstu, jej informacje o wydaniu to automatycznie generowane listy zmian, a nie notatki dotyczące migracji, i nie ma jeszcze historii aktualizacji. Nic w tym przewodniku nie jest wynikiem długoterminowej eksploatacji, więc wzrost zużycia pamięci, rozmiar bazy danych i niezawodność harmonogramu należy traktować jako parametry do samodzielnego zmierzenia na własnym serwerze, a nie jako założenia.

Warto samodzielnie przetestować dwa zachowania, zanim uzależni się od nich działanie systemu. Po pierwsze, czy procedura downgrade'u poprawnie odczytuje stan zapisany przez nowszą wersję: należy to sprawdzić na kopii wolumenu, gdy nie ma to krytycznego znaczenia, a nie podczas awarii. Po drugie, jak zachowuje się gateway, gdy sesja logowania Kiro wygasa w momencie zaplanowanego zadania. Oba te przypadki to typowe niedociągnięcia, które w młodych projektach są sukcesywnie eliminowane między wydaniami, a ich sprawdzenie teraz nie wiąże się z dużym nakładem pracy.

FAQ

Dlaczego pulpit nawigacyjny KiroCrew nie otwiera się pod publicznym adresem IP mojego serwera?

Ponieważ opublikowany przykład wiąże port z interfejsem zwrotnym (loopback). -p 127.0.0.1:5476:5476 mapuje port kontenera wyłącznie na adres loopback hosta, co jest działaniem celowym. Dostęp można uzyskać poprzez przekierowanie portu przez SSH za pomocą ssh -N -L 5476:127.0.0.1:5476 you@your-server, a następnie otwarcie http://localhost:5476/?token=<token> na komputerze lokalnym. Usunięcie prefiksu 127.0.0.1: w celu udostępnienia usługi wystawia bramę na publiczny Internet, a reguła zapory sieciowej jej nie ograniczy, ponieważ reguły DNAT dla opublikowanych portów Docker są przetwarzane przed filtrowaniem ruchu przez ufw.

Gdzie KiroCrew przechowuje dane i co należy archiwizować?

Wszystko znajduje się w ~/.kiro/crew, co wewnątrz obrazu kontenera odpowiada /home/kirocrew/.kiro/crew, a KIROCREW_HOME pozwala na zmianę tej lokalizacji. Należy wykonać kopię zapasową całego katalogu lub całego wolumenu Docker przy zatrzymanej bramie. memory.db oraz memory_index.db to bazy danych SQLite, więc kopia wykonana w trakcie zapisu przez bramę może być niespójna. Przy przenoszeniu na nowy host, workspace/memory/, dwa pliki baz danych oraz config.json przenoszą się, podczas gdy pliki PID, dziennik zdarzeń bezpieczeństwa oraz .env są przypisane do starego hosta.

Czy należy używać tagu stable, czy tagu wersji?

Należy używać tagu wersji. stable zmienia się przy każdym wydaniu, więc uruchamiana wersja może ulec zmianie przy kolejnym pobraniu, a sam tag nie informuje o tym, co jest uruchomione. Tagi wersji, takie jak 0.1.3, są niezmienne i właśnie to umożliwia przywrócenie poprzedniej wersji: wystarczy przywrócić stary numer, aby uzyskać identyczny obraz. Według stanu na 6 sierpnia 2026 najnowsze wydanie to 0.1.3.

Dlaczego mój agent odmawia wykonywania jakichkolwiek poleceń?

Kontener sprawdza obsługę piaskownicy (sandbox) przy pierwszym uruchomieniu. Jeśli nie może odizolować podprocesów agenta, a KIROCREW_ALLOW_UNSANDBOXED=1 nie jest ustawione, odmawia ich wykonania zamiast uruchamiać je bez ograniczeń, przez co brama wydaje się działać poprawnie, podczas gdy wszystkie zadania są wstrzymane. docker logs kirocrew pokazuje decyzję dotyczącą piaskownicy z tego pierwszego uruchomienia. Ustawienie tej zmiennej sprawia, że kontener staje się jedyną barierą między agentem a hostem, więc w przypadku jej ustawienia nie należy montować niczego, czego nie przekazałoby się bezpośrednio agentowi.

Czy do samodzielnego hostowania KiroCrew potrzebne jest konto Kiro?

Tak, według stanu na sierpień 2026. KiroCrew to wolne oprogramowanie na licencji Apache 2.0, ale obsługuje ono kiro-cli, co wymaga jednorazowego zalogowania, a wnioskowanie agenta jest rozliczane w ramach planu Kiro. Wewnątrz kontenera należy uruchomić docker exec -it kirocrew kiro-cli login i zatwierdzić kod urządzenia w przeglądarce. Do momentu zakończenia logowania brama uruchamia się, a pulpit nawigacyjny ładuje, jednak agent nie ma modelu, z którym mógłby się komunikować.