著者 KiroCrewをVPSで常時稼働させる方法
KiroCrewをDockerの固定タグ付きコンテナでVPSに常駐させる手順です。再起動後もメモリとスケジュールを保持し、SSH接続、バックアップ、問題発生時のロールバックまで説明します。
ノート PC ではなく VPS で KiroCrew をセルフホストする理由
KiroCrew のセルフホストは、常時稼働するマシンで運用して初めて効果があります。そのため、適した場所は VPS であり、ノート PC ではありません。KiroCrew はセッション履歴、セマンティックメモリ、スケジュール済みジョブ、承認キューをディスクに保存し、プロセスの再起動時にすべてを読み込みます。スケジュール済みジョブの実行時刻が 03:00 でもプロセスが稼働していなければ、これらの機能は役に立ちません。電源を切ったノート PC では、プロセスも稼働していません。
KiroCrew は Kiro チームが開発したオープンソースのエージェントワークスペースで、ライセンスは Apache 2.0 です。最初の一般公開リリースは 2026 年 8 月初旬に行われました。gateway と呼ばれる 1 つのプロセスが状態を管理し、port 5476 で Web ダッシュボードを提供します。この gateway には、ダッシュボード、kirocrew CLI、または Slack などのチャットチャネルから接続します。セルフホストするのは gateway だけです。そのため、このガイドでは gateway の稼働を維持する方法、パブリックインターネットから隔離する方法、問題のあるアップグレード後に復旧する方法を説明します。
開始前に、2 つの点を理解しておいてください。KiroCrew は kiro-cli を実行します。kiro-cli では、Kiro アカウントによる初回のサインインが必要です。また、エージェントの推論は Kiro プランに課金されるため、2026 年 8 月時点ではオフライン環境ではありません。このプロジェクトは公開からまだ数週間しか経過していません。いずれロールバックが必要になると考え、それが可能な方法でインストールしてください。サーバーでエージェントを実行した経験がない場合は、VPS でコーディングエージェントを実行するで、このガイドの前提となる基本事項を確認できます。
KiroCrew に必要なものと状態の保存場所
ネイティブインストールには Python 3.10 以降が必要です。プロジェクトでは 3.12 を推奨しています。ダッシュボードをソースからビルドする場合は Node.js 18 以降も必要です。また、kiro-cliも必要です。これは初回起動時にインストールされ、サインインも自動的に行われます。コンテナインストールでは、ホスト側にこれらは必要ありません。必要なのは Docker だけです。これが、コンテナインストールを優先する主な理由です。
状態は ~/.kiro/crew に保存されます。KIROCREW_HOME 環境変数を設定すると、保存先を変更できます。内部には次のものがあります。
config.json: ゲートウェイ設定とチャネルの認証情報です。.env: Secret です。workspace/memory/: 環境設定、プロジェクトメモ、チャット履歴です。memory.dbとmemory_index.db: セマンティックインデックスと全文インデックスです。models/: 初回実行時にダウンロードされる埋め込みモデルです。gateway.logとsecurity_events.jsonl: 実行時ログとセキュリティイベントログです。
このディレクトリがインストールの実体です。これを新しい VPS にコピーすればエージェントを移行できます。そのため、以下のバックアップのセクションはインストールのセクションより重要です。
RAM ではなくディスク容量を基準に計画してください。ゲートウェイは Python プロセスです。サーバーに実際の負荷をかけるのは、エージェントが実行する処理、ビルド、テストスイートです。状態ディレクトリはチャット履歴に応じて増加します。また、埋め込みモデルは初回起動時に配置されます。そのため、プロジェクト開始から最初の 1 か月に公開された数値をそのまま使うのではなく、数週間運用した後に du -sh ~/.kiro/crew で自分のサーバー上の使用量を測定してください。
3 つのインストール方法のどれを使うか
このプロジェクトでは、3 つの方法が公開されています。1 行インストーラーは wheel を取得し、kirocrew を PATH に追加します。
curl -fsSL https://download.crew.kiro.dev/cli.sh | shchannel フラグと 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コンテナイメージは ghcr.io/kirodotdev/kirocrew で公開されており、すべてのタグで linux/amd64 と linux/arm64 に対応しています。ソースからのビルドには git clone と make build が必要です。これはコードを変更する人向けであり、実行する人向けではありません。
コンテナを使用してください。ネイティブインストールでは、他のサービスを実行している同じホストに Python パッケージ、Node、kiro-cli が配置されます。そのため、アップグレードに失敗すると、手作業で元に戻す必要があります。コンテナでは、ランタイムを 1 つのイメージに、状態を 1 つのボリュームにまとめられます。そのため、ロールバックはタグの変更と再起動だけで実行できます。
リリースタグを指定し、stableは指定しないでください
プロジェクト自体の例では、stableタグを使用しています。
docker run -d --name kirocrew \
-p 127.0.0.1:5476:5476 \
-v kirocrew-home:/home/kirocrew \
ghcr.io/kirodotdev/kirocrew:stablestableは可変タグです。常に最新の安定版リリースを指すため、次回の pull で、選択していないバージョンに実行中のバージョンが変わる可能性があります。また、そのタグからは、どのバージョンだったかを確認できません。バージョンタグは不変なので、1 つを固定してください。2026 年 8 月 6 日時点での最新リリースは0.1.3で、2026 年 8 月 5 日に公開されています。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にも使用している health エンドポイントを確認します。
cd /opt/kirocrew
docker compose up -d
docker compose ps
curl -s http://127.0.0.1:5476/api/healthdocker compose psは、通常 1 分以内にコンテナを healthy と報告します。/api/healthは token なしで応答します（/api/liveと/api/readyも同様です）。そのため、これらを probe として使用できます。状態がstartingのままの場合は、何かを変更する前にdocker logs kirocrewを確認してください。初回の起動では embedding model がダウンロードされるため、接続が遅いと最初の起動に時間がかかります。
systemd で稼働を維持する
restart: unless-stopped は、Docker 自体がブート時に起動する限り、クラッシュ後や再起動後にコンテナを復旧します。unit ファイルを使うと、その依存関係を明示でき、バックアップ前にスタック全体を停止するコマンドも 1 つにまとめられます。一般的なパターンについては、ブート時に 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.targetsudo systemctl daemon-reload
sudo systemctl enable --now kirocrew
systemctl status kirocrewsystemctl status kirocrew には active (exited) と表示されるはずです。これは、この unit が正常な状態であることを示します。ここで Type=oneshot に RemainAfterExit=yes を指定するのは適切です。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 は公開しないでください
プロジェクトの例にある bind address をもう一度確認してください。-p 127.0.0.1:5476:5476。コンテナ内では、ポートマッピング経由で到達できる必要があるため、ゲートウェイは 0.0.0.0 で待ち受けます。ただし、マッピング自体はホストの loopback に対してのみ公開します。127.0.0.1: プレフィックスを削除すると、そのポートをスキャンする誰もがゲートウェイへアクセスできる状態になります。ファイアウォールルールでも防げません。Docker は DNAT ルールを書き込んでポートを公開し、そのルールは ufw のフィルタリングより前に評価されるため、ufw deny 5476 は公開済みポートに対して何もしません。ufw を迂回する Docker のポートでは、この仕組みを説明しています。
ノートパソコンから 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=... を開きます。
トンネル経由では、次の動作に注意してください。ゲートウェイは転送されたリクエストをリモートからのアクセスとして扱うため、ダッシュボードの設定書き込みエンドポイントと Secret 表示エンドポイントは拒否されます。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 は経路上のすべてのアクセスログに記録されます。
エージェントに与える影響範囲を可能な限り小さくする
コンテナは初回起動時にサンドボックスのサポート状況を検査し、その結果でエージェントが何かを実行できるかどうかを決定します。namespace 分離が利用できる場合、エージェントのサブプロセスは分離して実行されます。利用できず、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.jsonKIROCREW_ALLOW_UNSANDBOXED=1を設定する場合は、何が変わったのかを明確にしてください。コンテナが、エージェントとサーバーの間にある唯一の境界になります。プロジェクトの警告をそのまま繰り返します。エージェントに直接渡せない host のパスはマウントしないでください。実際には、Docker socket、/の bind mount、別のサービスのデータを保存しているディレクトリはすべて対象外です。
残りは、コマンド実行を許可したすべてのエージェントに適用する基本方針です。認証情報の権限範囲は、必要な1つのリポジトリまたは1つのバケットに限定してください。アカウント全体の権限を持つ個人用トークンは使用しないでください。専用ユーザーで実行し、その home には他のデータを置かないでください。これは VPS で最小権限ユーザーを使うための方法です。エージェントがコードを作成してからそのコードを実行する場合は、壊してもよいマシンを用意してください。コーディングエージェント用の使い捨て VMは、この compose file のどのフラグよりも強固な境界になります。問題が起きても、修復するのではなく VM を削除できるためです。同じ考え方が、VPS で OpenClaw を安全に実行する場合や、VPS で Hermes agent をセルフホストする場合にも当てはまります。スケジュール実行では、睡眠中も推論料金が発生します。料金は Kiro plan に請求されるため、夜間ジョブを追加する前に、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/ 配下のチャット履歴とプロジェクトメモは移行します。2 つのデータベースファイルと config.json も移行します。PID ファイル、セキュリティイベントログ、.env は旧ホストに依存するため移行せず、新しいホストで Secret を再入力します。
問題のあるアップグレードをロールバックする方法
アップグレード自体は短時間で完了します。バージョンを固定しているため、安全に実行できます。最初にバックアップを取得し、その後でタグを変更します。
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/healthdocker compose up -d は、まだホスト上にない場合にイメージを取得します。そのため、タグの編集だけでアップグレード全体が完了します。ロールバックも、古い番号を指定して同じ手順を実行します。バージョンタグは不変であるため、アップグレード前とまったく同じイメージを使用できます。
バイナリは問題なくロールバックできます。ただし、状態データはその限りではありません。新しい gateway が config.json を書き換えたり、メモリデータベースを古い gateway が読み取れない形式へ移行したりする可能性があります。2026 年 8 月時点で、ダウングレード手順は文書化されていません。古いイメージが起動した後に動作が不安定になった場合は、原因を調査しないでください。停止し、アップグレード前に取得したバックアップを復元してから、もう一度起動します。これが最初にバックアップを取得する理由です。開発初期のプロジェクトでは、先にアップグレードして後からバックアップを取得する運用では問題を解決できません。
ここで証明されていないこと
このソフトウェアがまだ新しいことを正しく認識してください。執筆時点で Version 0.1.3 はリリースから数日しか経っておらず、リリースノートも移行手順ではなく、自動生成された変更履歴へのリンクです。アップグレードの実績もまだありません。このガイドに長期運用の結果は含まれていないため、メモリ使用量の増加、データベースサイズ、スケジューラーの信頼性は、前提にせず自分の環境で測定してください。
依存する前に、自分で確認しておくべき動作が2つあります。1つ目は、ダウングレードしたバージョンが新しいバージョンによって書き込まれた状態を読み込めるかどうかです。障害中ではなく、問題が発生しても影響のない時点で、ボリュームのコピーを使って試してください。2つ目は、スケジュール済みジョブの実行時刻に Kiro のサインインが期限切れになった場合、ゲートウェイがどのように動作するかです。どちらも、新しいプロジェクトがリリース間に静かに修正していく初期段階の問題になりやすく、今のうちに低コストで確認できます。
FAQ
KiroCrew のダッシュボードがサーバーのパブリック IP で開かないのはなぜですか？
公開されている例では、ポートが loopback にバインドされているためです。-p 127.0.0.1:5476:5476 はコンテナのポートをホストの loopback アドレスだけにマッピングします。これは意図した設定です。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 volume 全体をバックアップしてください。memory.db と memory_index.db は SQLite データベースです。そのため、ゲートウェイが書き込み中に取得したコピーは不整合になる可能性があります。新しいホストへ移行する場合は、workspace/memory/、2 つのデータベースファイル、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 を実行し、ブラウザーでデバイスコードを承認してください。サインインが完了するまでは、ゲートウェイが起動してダッシュボードも読み込まれますが、エージェントが接続するモデルはありません。