KiroCrew VPS 자가 호스팅 및 상시 구동 가이드

노트북 대신 VPS에서 KiroCrew를 직접 호스팅해야 하는 이유

KiroCrew를 직접 호스팅하는 것은 항상 켜져 있는 기기에서만 효과가 있으므로, 노트북보다는 VPS가 적합한 환경입니다. KiroCrew는 세션 기록, 의미론적 메모리, 예약 작업 및 승인 대기열을 디스크에 저장하며, 프로세스가 재시작될 때 이 모든 데이터를 다시 불러옵니다. 예약된 작업이 실행되어야 할 새벽 03:00에 프로세스가 실행 중이지 않다면 아무런 소용이 없으며, 덮개가 닫힌 노트북은 이를 실행할 수 없습니다.

KiroCrew는 Kiro 팀에서 제공하는 오픈 소스 에이전트 워크스페이스로, Apache 2.0 라이선스를 따르며 2026년 8월 초에 첫 공개 릴리스가 배포되었습니다. gateway라고 불리는 단일 프로세스가 상태를 관리하며 5476 포트에서 웹 대시보드를 제공합니다. 이 gateway에는 대시보드, kirocrew CLI, 또는 Slack과 같은 채팅 채널을 통해 접근할 수 있습니다. 직접 호스팅하는 대상은 오직 이 gateway뿐이므로, 본 가이드는 이를 항상 실행 상태로 유지하고, 공용 인터넷에 노출하지 않으며, 잘못된 업그레이드 이후에도 복구할 수 있도록 관리하는 방법을 다룹니다.

시작하기 전에 알아두어야 할 두 가지 사항이 있습니다. KiroCrew는 kiro-cli를 구동하며, 이를 위해서는 Kiro 계정으로 1회 로그인이 필요합니다. 또한 에이전트 추론 비용은 Kiro 플랜에 청구되므로, 2026년 8월 기준으로 이 설정은 오프라인 환경이 아닙니다. 또한 이 프로젝트는 공개된 지 몇 주밖에 되지 않았습니다. 언제든 롤백이 필요할 수 있음을 가정하고, 복구가 가능한 방식으로 설치하십시오. 서버에서 에이전트를 실행해 본 적이 없다면, VPS에서 코딩 에이전트 실행하기를 통해 본 가이드의 기반이 되는 기본 규칙을 먼저 확인하시기 바랍니다.

KiroCrew의 요구 사항과 상태 저장 위치

네이티브 설치에는 Python 3.10 이상(프로젝트 권장 버전은 3.12)이 필요하며, 대시보드를 소스에서 빌드할 경우 Node.js 18 이상이 필요합니다. 또한 첫 실행 시 자동으로 설치 및 로그인을 진행하는 kiro-cli이 필요합니다. 컨테이너 설치 방식은 호스트에 이러한 환경을 구성할 필요가 없으며, 오직 Docker만 있으면 됩니다. 이것이 컨테이너 방식을 선호하는 주된 이유입니다.

상태 데이터는 ~/.kiro/crew에 저장되며, KIROCREW_HOME 환경 변수를 통해 저장 위치를 변경할 수 있습니다. 해당 디렉터리 내부 구성은 다음과 같습니다.

• config.json: 게이트웨이 설정 및 채팅 채널 자격 증명.
• .env: 보안 비밀 정보.
• workspace/memory/: 환경 설정, 프로젝트 노트 및 채팅 기록.
• memory.db 및 memory_index.db: 의미론적(semantic) 인덱스 및 전문(full-text) 인덱스.
• models/: 첫 실행 시 다운로드되는 임베딩 모델.
• gateway.log 및 security_events.jsonl: 런타임 로그 및 보안 이벤트 로그.

해당 디렉터리가 곧 설치 그 자체입니다. 이 디렉터리를 새로운 VPS로 복사하면 에이전트 이전이 완료됩니다. 이것이 아래의 백업 섹션이 설치 섹션보다 더 중요한 이유입니다.

RAM보다는 디스크 용량을 고려하십시오. 게이트웨이는 Python 프로세스이며, 시스템 부하를 실제로 유발하는 것은 에이전트가 실행하는 빌드나 테스트 스위트와 같은 작업입니다. 상태 디렉터리는 채팅 기록이 쌓이면서 커지며, 임베딩 모델은 첫 실행 시 다운로드됩니다. 따라서 프로젝트 초기 단계에 게시된 수치를 맹신하기보다는, 몇 주 사용 후 du -sh ~/.kiro/crew을 사용하여 본인의 서버에서 직접 측정하십시오.

세 가지 설치 경로 중 무엇을 사용해야 하는가

이 프로젝트는 세 가지 설치 방식을 제공합니다. 한 줄짜리 설치 스크립트는 wheel을 가져와 kirocrew를 PATH에 추가합니다:

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

이 스크립트에는 채널 플래그와 버전 플래그를 사용할 수 있습니다:

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

컨테이너 이미지는 ghcr.io/kirodotdev/kirocrew에 게시되며, 모든 태그에서 linux/amd64 및 linux/arm64를 지원합니다. 소스 빌드는 git clone과 make build을 조합한 방식이며, 이는 코드를 수정하는 개발자를 위한 것이지 단순히 실행하려는 사용자를 위한 것이 아닙니다.

컨테이너를 사용하십시오. 네이티브 설치는 다른 서비스가 실행 중인 동일한 호스트에 Python 패키지, Node 및 kiro-cli을 설치하므로, 업그레이드에 실패하면 이를 수동으로 일일이 복구해야 합니다. 컨테이너는 런타임을 하나의 이미지에, 상태를 하나의 볼륨에 유지하므로 롤백이 단순히 태그를 변경하고 재시작하는 것만으로 가능합니다.

이미지를 stable가 아닌 릴리스 태그에 고정하십시오

프로젝트의 자체 예제는 stable 태그를 사용합니다:

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

stable은 유동적인 태그입니다. 이 태그는 가장 최신 안정 릴리스를 가리키므로, 다음 pull 작업 시 사용자가 선택하지 않아도 실행 중인 버전이 변경될 수 있으며 태그에는 어떤 버전이었는지에 대한 기록이 남지 않습니다. 버전 태그는 변경 불가능하므로 특정 버전으로 고정하십시오. 2026년 8월 6일 기준 최신 릴리스는 2026년 8월 5일에 게시된 0.1.3입니다. 또한 nightly 태그도 존재하는데, 이처럼 초기 단계의 프로젝트에서 해당 태그는 오늘 아침에 코드가 변경되었음을 의미합니다.

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

서비스를 시작한 다음, 이미지가 자체 HEALTHCHECK를 위해 사용하는 상태 확인 엔드포인트를 점검하십시오:

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

docker compose ps은 1분 이내에 컨테이너가 정상(healthy) 상태임을 보고해야 하며, /api/health은 토큰 없이 응답합니다(/api/live 및 /api/ready도 마찬가지이며, 이것이 프로브로 사용 가능한 이유입니다). 상태가 starting으로 유지된다면, 설정을 변경하기 전에 docker logs kirocrew을 읽어보십시오. 첫 실행 시 임베딩 모델을 다운로드하므로, 네트워크 연결이 느리면 첫 시작에 시간이 오래 걸릴 수 있습니다.

systemd를 이용한 서비스 상시 가동

restart: unless-stopped는 컨테이너가 충돌하거나 재부팅된 이후에도 Docker가 부팅 시점에 정상적으로 시작된다면 컨테이너를 다시 실행합니다. unit 파일은 이러한 의존성을 명확히 하며, 백업 전 전체 스택을 한 번에 중지할 수 있는 명령어를 제공합니다. 부팅 시 Docker Compose 스택 시작하기에서 일반적인 패턴을 다룹니다. 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의 정상적인 상태입니다. RemainAfterExit=yes과 함께 Type=oneshot을 사용하는 이유는 docker compose up -d이 컨테이너를 시작하자마자 즉시 반환되기 때문입니다. 즉, systemd는 포그라운드 프로세스가 아닌 스택의 실행 상태를 추적합니다. 대신 Type=simple를 작성하면 systemd는 명령어가 즉시 종료된 것으로 간주하여 서비스를 중단된 상태로 표시하며, Restart= 설정에 따라 포기하거나 재시작 루프에 빠지게 됩니다. 네이티브 설치의 경우 프로젝트에서 자체적으로 제공하는 kirocrew service install을 사용하며, 이는 /etc/systemd/system/kirocrew.service를 작성하고 사용자의 권한으로 게이트웨이를 실행합니다. 두 unit을 동시에 실행하지 마십시오. 이 주제에 대한 더 자세한 내용은 VPS에서의 systemd 서비스 및 타이머에서 확인할 수 있습니다.

첫 실행: 로그인 및 대시보드 토큰 획득

컨테이너가 게이트웨이를 시작하지만, 에이전트 런타임은 아직 로그인되지 않은 상태입니다. 컨테이너 내부에서 로그인하십시오:

docker exec -it kirocrew kiro-cli login

이 명령을 실행하면 기기 코드와 브라우저에서 열어야 할 URL이 출력됩니다. 그 후 대시보드 토큰을 생성하십시오:

docker exec kirocrew kirocrew token --ttl 2h

대시보드 URL은 http://localhost:5476/?token=<the token>입니다. 토큰은 만료됩니다. 세션은 기본적으로 1시간 동안 유지되며, 문서화된 최대 시간은 20시간입니다. 대시보드가 빈 화면으로 로드되거나 즉시 튕겨 나간다면 대개 토큰이 만료된 것이므로, 토큰을 새로 생성하십시오. 토큰을 가진 사람은 귀하의 에이전트를 제어할 수 있으므로, 토큰을 티켓이나 채팅 메시지에 절대 붙여넣지 마십시오.

SSH를 통해 대시보드에 접속하고 포트 5476은 절대 공개하지 마십시오

프로젝트 예제에 있는 바인드 주소 -p 127.0.0.1:5476:5476를 다시 확인하십시오. 컨테이너 내부에서 게이트웨이는 0.0.0.0에서 대기합니다. 포트 매핑을 통해 접근 가능해야 하기 때문이지만, 매핑 자체는 호스트의 루프백 인터페이스에만 공개됩니다. 127.0.0.1: 접두사를 삭제하면 해당 포트를 스캔하는 누구에게나 게이트웨이가 공개 인터넷상에 노출됩니다. 방화벽 규칙으로도 보호할 수 없습니다. Docker는 ufw 필터링보다 먼저 평가되는 DNAT 규칙을 작성하여 포트를 게시하므로, ufw deny 5476은 게시된 포트에 아무런 영향을 주지 못합니다. Docker ports bypassing ufw에서 해당 메커니즘을 자세히 다룹니다.

대신 노트북에서 SSH를 통해 포트를 포워딩하십시오:

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

해당 명령을 실행 상태로 두고 로컬에서 http://localhost:5476/?token=<the token>에 접속하십시오. 연결할 때마다 자동으로 포워딩되도록 하려면 ~/.ssh/config에 다음 내용을 추가하십시오:

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

노트북에서 이미 포트 5476을 사용 중이라면 왼쪽 숫자만 변경하십시오(예: ssh -N -L 45476:127.0.0.1:5476 you@your-server.example.com). 그 후 http://localhost:45476/?token=...로 접속하십시오.

터널을 통해 접속할 때 예상되는 문서화된 동작이 하나 있습니다. 게이트웨이는 포워딩된 요청을 원격 요청으로 인식하므로, 대시보드의 설정 쓰기(config-write) 및 비밀값 표시(secret-reveal) 엔드포인트가 이를 거부합니다. SSH를 통해 설정 변경이 저장되지 않는 것은 버그가 아니라 의도된 동작입니다. 대신 호스트에서 설정을 직접 편집하십시오:

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

모바일 기기에서 접근하려면 프로젝트에서 권장하는 Tailscale의 tailscale serve를 사용하십시오. 이를 통해 대시보드를 공개 호스트명이 아닌 개인 tailnet 내부에 유지할 수 있습니다. 공개 리버스 프록시보다 이 방식을 권장합니다. 토큰이 URL에 포함되어 전달되는데, URL은 경로상의 모든 접근 로그에 기록되기 때문입니다.

에이전트의 폭발 반경을 최소화하십시오

컨테이너는 첫 시작 시 샌드박스 지원 여부를 탐색하며, 그 결과에 따라 에이전트의 실행 가능 여부가 결정됩니다. 네임스페이스 격리가 가능하다면 에이전트 하위 프로세스는 격리된 상태로 실행됩니다. 격리가 불가능한데 KIROCREW_ALLOW_UNSANDBOXED=1이 설정되지 않았다면, 제한 없는 실행 대신 실행 자체가 거부됩니다. 따라서 모든 작업이 멈춘 상태에서 게이트웨이만 정상으로 보인다면 대개 이 문제입니다. 해당 결정 사항은 첫 실행 시 docker logs kirocrew에 저장됩니다. 프로젝트는 적용 가능한 seccomp(secure computing mode) 프로필도 제공합니다.

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를 설정한다면 변경 사항을 명확히 인지해야 합니다. 이제 컨테이너가 에이전트와 서버 사이의 유일한 경계가 됩니다. 프로젝트의 경고를 전문 그대로 다시 강조합니다. 에이전트에게 직접 넘겨줄 의도가 없는 호스트 경로는 마운트하지 마십시오. 실제로는 Docker 소켓, /의 모든 바인드 마운트, 다른 서비스의 데이터가 포함된 모든 디렉터리가 이에 해당합니다.

나머지는 명령 실행이 허용된 모든 에이전트에 적용되는 기본 틀입니다. 에이전트의 자격 증명은 필요한 단일 저장소나 버킷으로 범위를 제한하십시오. 계정 전체 권한을 가진 개인 토큰은 절대 사용해서는 안 됩니다. 홈 디렉터리에 다른 파일이 없는 전용 사용자로 실행하십시오. 이것이 바로 VPS에서 최소 권한 사용자 사용하기가 필요한 이유입니다. 에이전트가 코드를 작성하고 실행할 때는 파손되어도 괜찮은 머신을 제공하십시오. 코딩 에이전트를 위한 일회용 VM은 이 compose 파일의 어떤 플래그보다 강력한 경계가 됩니다. 삭제하면 그만이기 때문에 정리할 필요가 없기 때문입니다. 동일한 논리가 VPS에서 OpenClaw 안전하게 실행하기와 VPS에서 Hermes 에이전트 자가 호스팅하기를 구성합니다. 도구 또한 폭발 반경에 포함됩니다. 에이전트에게 웹 검색 기능을 부여하면 가져오는 모든 페이지가 신뢰할 수 없는 입력값이 됩니다. 따라서 자체 SearXNG 인스턴스 연결하기는 인프라 설정인 동시에 프롬프트 인젝션 방어 결정이기도 합니다. 예약된 작업은 잠든 사이에도 비용을 발생시킵니다. 추론 비용은 Kiro 플랜으로 청구되므로, 야간 작업을 추가하기 전에 VPS에서 AI 에이전트 비용 제어하기에 설명된 제한을 설정하십시오.

업그레이드 전 상태 볼륨 백업

먼저 실제 볼륨 이름을 찾습니다. Compose는 프로젝트 이름을 접두사로 붙여 볼륨을 생성하며, 프로젝트 이름은 기본적으로 디렉터리 이름입니다. 따라서 /opt/kirocrew/compose.yaml 파일에서 kirocrew-home로 선언된 볼륨은 kirocrew_kirocrew-home라는 이름으로 생성됩니다.

docker volume ls

데이터를 복사하기 전에 게이트웨이를 중지합니다. memory.db과 memory_index.db은 SQLite 데이터베이스입니다. 데이터베이스에 쓰기 작업이 진행되는 도중에 복사하면 트랜잭션이 중간에 끊긴 상태로 저장될 수 있으며, 이를 복원하면 파일이 손상됩니다. 프로젝트 자체 마이그레이션 지침에서도 게이트웨이를 중지한 상태에서만 데이터를 이동하라고 명시하고 있습니다.

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

아카이브를 서버 외부로 복사합니다. 복원할 때는 컨테이너를 중지한 상태에서 tar czf 대신 tar xzf를 사용하여 동일한 명령을 실행합니다.

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

새 호스트로 이동하는 것은 제자리에서 복원하는 것과는 다른 작업이며, 프로젝트에서 이에 대해 구체적으로 명시하고 있습니다. workspace/memory/ 하위의 채팅 기록과 프로젝트 노트는 그대로 유지되며, 두 개의 데이터베이스 파일과 config.json도 마찬가지입니다. PID 파일, 보안 이벤트 로그, .env은 이전 호스트에 종속적이므로 제외해야 하며, 새 서버에서 비밀 값을 다시 입력해야 합니다.

잘못된 업그레이드를 롤백하는 방법

업그레이드 과정은 짧으며, 버전을 고정(pinning)했기 때문에 안전합니다. 먼저 백업을 수행한 다음 태그를 변경하십시오.

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은 이미 로컬에 없는 이미지를 가져오므로, 태그 수정만으로 업그레이드가 완료됩니다. 롤백 역시 이전 버전 번호로 동일한 과정을 거치며, 버전 태그는 변경 불가능하므로 이전에 사용하던 것과 정확히 동일한 이미지를 제공합니다.

바이너리는 깔끔하게 롤백됩니다. 하지만 상태(state) 데이터는 그렇지 않을 수 있습니다. 더 최신 버전의 게이트웨이는 config.json을 다시 작성하거나 메모리 데이터베이스를 이전 버전의 게이트웨이가 읽을 수 없는 형태로 마이그레이션할 수 있으며, 2026년 8월 기준으로 다운그레이드 경로는 문서화되어 있지 않습니다. 따라서 이전 이미지를 실행한 후 이상 동작이 발생하면 디버깅하지 마십시오. 해당 서비스를 중지하고 업그레이드 전에 수행한 백업을 복원한 뒤 다시 시작하십시오. 이것이 백업을 먼저 수행해야 하는 이유이며, 업그레이드를 먼저 하고 백업을 나중에 하는 습관이 이처럼 초기 단계의 프로젝트에서 실패하는 이유입니다.

검증되지 않은 사항

이 소프트웨어의 버전에 대해 솔직히 말씀드리겠습니다. 이 글을 작성하는 시점에 버전 0.1.3는 출시된 지 며칠 되지 않았습니다. 릴리스 노트는 마이그레이션 가이드가 아닌 자동 생성된 변경 로그 링크에 불과하며, 아직 업그레이드 이력도 없습니다. 이 가이드의 내용은 장기적인 운영 결과를 담고 있지 않으므로, 메모리 증가, 데이터베이스 크기, 스케줄러 신뢰성은 가정하지 말고 직접 서버에서 측정해야 합니다.

의존성을 갖기 전에 직접 테스트해 볼 가치가 있는 동작이 두 가지 있습니다. 첫째, 최신 버전에서 기록한 상태를 이전 버전에서 읽을 수 있는지 확인하십시오. 이는 장애 상황이 아닐 때 볼륨 복사본으로 테스트해야 합니다. 둘째, 예약된 작업이 실행될 시점에 Kiro 로그인 세션이 만료되면 게이트웨이가 어떻게 동작하는지 확인하십시오. 두 경우 모두 초기 프로젝트에서 릴리스를 거치며 조용히 다듬어지는 거친 부분들이며, 지금 확인하는 것은 비용이 거의 들지 않습니다.

FAQ

서버의 공인 IP에서 KiroCrew 대시보드가 열리지 않는 이유는 무엇입니까?

제공된 예제는 포트를 루프백 주소에 바인딩하기 때문입니다. -p 127.0.0.1:5476:5476은 컨테이너의 포트를 호스트의 루프백 주소로만 매핑하도록 의도적으로 설정되어 있습니다. ssh -N -L 5476:127.0.0.1:5476 you@your-server을 사용하여 SSH로 포트를 포워딩한 다음, 노트북에서 http://localhost:5476/?token=<token>에 접속하십시오. 127.0.0.1: 접두사를 제거하여 외부에서 접근 가능하게 만들면 게이트웨이가 공인 인터넷에 노출됩니다. 이때 Docker의 포트 게시 DNAT 규칙이 ufw 필터보다 먼저 평가되므로, 방화벽 규칙만으로는 접근을 차단할 수 없습니다.

KiroCrew는 데이터를 어디에 저장하며, 무엇을 백업해야 합니까?

모든 데이터는 ~/.kiro/crew 아래에 위치하며, 컨테이너 이미지 내부 경로는 /home/kirocrew/.kiro/crew입니다. KIROCREW_HOME을 사용하여 위치를 변경할 수 있습니다. 게이트웨이를 중지한 상태에서 해당 디렉터리 전체 또는 Docker 볼륨 전체를 백업하십시오. memory.db과 memory_index.db은 SQLite 데이터베이스이므로, 게이트웨이가 쓰기 작업을 수행하는 도중에 복사하면 데이터 일관성이 깨질 수 있습니다. 새 호스트로 이전할 때는 workspace/memory/, 두 개의 데이터베이스 파일, 그리고 config.json을 옮기면 됩니다. 반면 PID 파일, 보안 이벤트 로그, .env은 이전 호스트에 종속된 파일이므로 옮길 필요가 없습니다.

stable 태그를 사용해야 합니까, 아니면 버전 태그를 사용해야 합니까?

버전 태그를 사용하십시오. stable은 릴리스가 배포될 때마다 변경됩니다. 따라서 다음 pull 시점에 실행 중인 버전이 예고 없이 바뀔 수 있으며, 태그 자체만으로는 현재 실행 중인 버전을 알 수 없습니다. 0.1.3와 같은 버전 태그는 변경되지 않으므로 롤백이 가능합니다. 이전 버전 번호로 되돌리면 동일한 이미지를 다시 가져올 수 있습니다. 2026년 8월 6일 기준 최신 릴리스는 0.1.3입니다.

에이전트가 명령 실행을 거부하는 이유는 무엇입니까?

컨테이너는 첫 시작 시 샌드박스 지원 여부를 확인합니다. 에이전트 하위 프로세스를 격리할 수 없고 KIROCREW_ALLOW_UNSANDBOXED=1이 설정되지 않은 경우, 보안상 격리되지 않은 상태로 실행하는 대신 실행 자체를 거부합니다. 이 경우 게이트웨이는 정상으로 보이지만 모든 작업이 중단됩니다. docker logs kirocrew을 확인하면 첫 실행 시의 샌드박스 결정 결과를 볼 수 있습니다. 해당 변수를 설정하면 컨테이너가 에이전트와 호스트 사이의 유일한 경계가 됩니다. 따라서 이 변수를 설정할 경우 에이전트에 직접 노출해서는 안 되는 파일은 마운트하지 마십시오.

KiroCrew를 자체 호스팅하려면 Kiro 계정이 필요합니까?

네, 2026년 8월 기준으로 필요합니다. KiroCrew는 Apache 2.0 라이선스를 따르는 자유 소프트웨어이지만, kiro-cli을 구동하려면 1회 로그인이 필요하며 에이전트 추론 비용은 Kiro 플랜에 청구됩니다. 컨테이너 내부에서 docker exec -it kirocrew kiro-cli login를 실행하고 브라우저에서 기기 코드를 승인하십시오. 로그인이 완료되기 전까지는 게이트웨이가 시작되고 대시보드가 로드되더라도, 에이전트가 통신할 모델이 없으므로 정상적으로 작동하지 않습니다.