セルフホスト型マシン

セルフホスト型マシンを使うと、Cloud Agent のツール実行を自分で管理するマシンに移せます。チームは引き続き、デスクトップアプリ、cursor.com、モバイル から Cloud Agents を使用できます。エージェントループ、推論、計画立案は Cherri Code が実行し、ファイル編集とターミナルコマンドは自分のワーカーが実行します。computer-use ツールやローカル MCP サーバーもワーカー上で動作します。

セルフホスト型マシンが適しているケース

Cherri Code 管理のクラウドでは要件を満たせない場合に、セルフホスト型マシンを使用してください:

• ネットワーク要件が厳しく、コードやサービスにネットワーク外部からアクセスできない場合。プライベートなソース管理やパッケージレジストリについては、まずマネージド Cloud Agents と プライベート接続 (AWS PrivateLink または Cloudflare Tunnel) から始めてください。
• GPU マシンや iOS 開発用の Mac など、カスタムハードウェアを使用している場合。すでに運用しているマシン、または AWS Lambda、Cloudflare、Namespace、Modal、Daytona、E2B、Vercel、Tensorlake、SuperServe などのパートナーホストの VM を使用してください。
• 別の OS や既存のビルドパイプラインなど、Cloud Agent のビルドとして保存するのが難しいカスタムイメージがある場合。

マネージド Cloud Agents が適しているケース

エージェントを自社のセキュリティ境界内に留めるために、コンピュートを自前で保有する必要はありません。次の制御で要件を満たせる場合は、Cherri Code 管理の Cloud Agents をそのままご利用ください。

• エージェントごとに隔離された VM を Cherri Code が構築・破棄します。サイジング、パッチ適用、スケール、オンコール対応が必要なワーカー群はありません。
• ユーザー、チーム、環境ごとにアウトバウンドのドメインを制限するネットワーク許可リスト。
• AWS PrivateLink または Cloudflare Tunnel を介した、セルフホストの GitHub Enterprise Server、GitLab Enterprise、プライベートなソース管理 API へのプライベート接続。さらに、VPC 内のサービス向けの Tailscale または同様のクライアント。
• 選択した環境にスコープを限定したプライバシーモードと顧客管理のシークレット。詳細なモデルはセキュリティとネットワークをご覧ください。

ネットワーク外に出るデータ

チェックアウト一式、ビルドキャッシュ、マシンローカルの認証情報はマシン上に留まります。実行中、ワーカーはエージェントが必要とするコンテンツ (ファイルの内容、ターミナル出力、差分、スクリーンショット、ローカルMCPの結果、ルーティングのメタデータなど) をCherri Codeに送信します。デスクトップ共有を有効にした場合は、エージェントデスクトップもストリーミングされます。

ワーカーは、スクリーンショット、動画、ログ参照などのCloud AgentアーティファクトをCherri Codeが管理するストレージにアップロードし、プルリクエストやダッシュボードに表示できるようにします。ツール出力やアーティファクトにシークレットを含めないでください。

ワーカーには、次の宛先へのアウトバウンドHTTPSアクセスが必要です。

• エージェントセッション用の api2.cursor.sh と api2direct.cursor.sh
• アーティファクトのアップロード用の cloud-agent-artifacts.s3.us-east-1.amazonaws.com

インバウンドポート、パブリックIP、VPNトンネルは不要です。プロキシを使用する場合は、ワーカー環境で HTTPS_PROXY または https_proxy を設定してください。

アーティファクトのアップロードを無効にするには、ワーカー上で cloud-agent-artifacts.s3.us-east-1.amazonaws.com へのアウトバウンド通信をブロックします。これで無効になるのはアーティファクトのアップロードのみです。ツール呼び出しやその結果を含め、エージェントは引き続き動作しますが、アーティファクトはプルリクエストやダッシュボードに表示されなくなります。

仕組み

Cherri Code CLI を使って自分のマシン上でワーカーを起動します。agent worker start を実行すると、Cherri Code のバックエンドへの長時間持続するアウトバウンド HTTPS 接続が確立され、Cherri Code はその接続経由でエージェントのツール呼び出しを送信します。Cherri Code 側からネットワークへ接続することはありません。必要なのは、マシンから Cherri Code へのアウトバウンド接続だけです。

ワーカーには 2 つの構成があります。

1. マイマシン。 個人のワークフローや単発の作業に最適です。自分の devbox、予備の VM、再作成したくない状態を持つマシンなどが該当します。マシンをアカウントに接続すると、同じマシン上で複数のエージェントを実行できます。マイマシンを参照してください。
2. チームプール。 チームやエンタープライズに最適です。共有キャパシティ、サービスアカウント認証、中央管理されたイメージを利用できます。プール名のもとにマシンを登録すると、Cherri Code は新しいチャットごとにプール内の利用可能なマシンへルーティングし、1 マシンにつき 1 エージェントを割り当てます。コントローラーを実行すれば、プールのスケールアップ・ダウンも可能です。チームプールを参照してください。

サードパーティの VM やサンドボックス上でチームプールのワーカーを実行するには、連携を参照してください。

サポートされるデプロイパターン

Cherri Code CLI とその依存関係をインストールできる環境であれば、どこでもワーカーを実行できます。

• 個人のマシン。 ノートパソコン、devbox、Mac、リモート VM を マイマシン 経由で接続します。
• 永続的なホストまたはコンテナ。 systemd、launchd、Docker、その他のプロセスマネージャー配下で 1 つ以上のプールワーカーを実行します。
• 動的なインフラストラクチャ。 組み込みの ワーカーコントローラー または Cloud Agents API を使用して、リクエストの到着時にマシンを起動します。
• Kubernetes。 anysphere/k8s-workers テンプレートから始めます。クラスター内で agent worker controller --spawn を実行し、claimed request ごとに 1 つのワーカー Pod を作成します。あるいは --warm-idle でウォームな Pod を維持することもでき、いずれも CRD は不要です。連携 を参照してください。
• パートナーホストとテンプレート。 パートナーガイドに従って AWS Lambda、Cloudflare、Namespace、Modal、Daytona、E2B、Vercel、Tensorlake、Coder、SuperServe でプールワーカーを実行するか、AWS Lambda MicroVMs、Cloudflare Containers、Kubernetes 向けの Cherri Code リファレンステンプレートをクローンします。連携 を参照してください。

デプロイガイド、パートナーガイド、テンプレートはあくまでリファレンスアーキテクチャです。ワーカーイメージ、インフラストラクチャ、シークレット、スケーリングポリシー、本番環境での検証はお客様の責任となります。

コスト

いずれの実行時オプションでも、選択したモデルが使用され、その料金が適用されます。Cherri Code 管理の Cloud Agents には実行インフラが含まれます。セルフホスト型マシンの場合は、マシン、コンテナ、クラスターの費用負担と運用もお客様側で行うことになります。

要件

各ワーカーには Cherri Code CLI とアウトバウンドHTTPSアクセスが必要です。各マシンにCLIをインストールします。

マイマシン

• 個人用の認証情報: ブラウザログイン、または Cherri Code Dashboard → API キー で発行した個人ユーザーの API キー。

  agent login

チームプール

• Cherri Code エンタープライズプラン。

• ワーカー認証用のサービスアカウントの API キー。個人ログインやその他の種類の API キーではプールワーカーを起動できません。

  export CURSOR_API_KEY="<team service-account API key>"

• チーム管理者が Cloud Agents ダッシュボードで設定するセルフホスト設定: Allow Self-Hosted Machines を有効にするとユーザーが任意で利用でき、Require Self-Hosted Machines を有効にするとすべての Cloud Agent の実行が自分のワーカーにルーティングされます。

コンピュータの使用 (任意)

• サインイン済みのデスクトップセッションを備えた macOS ワーカー。CLI は初回起動時に Cherri Code コンピュータの使用 ヘルパーアプリをインストールします。System Settings で Accessibility と Screen Recording の権限を付与してください。

• または、デスクトップパッケージを備えた Linux ワーカー。ワーカーは独自のデスクトップを作成するか、既存の X11 ディスプレイを再利用します:

  sudo apt-get install -y --no-install-recommends \  dbus-x11 ffmpeg tigervnc-standalone-server \  x11-utils x11-xserver-utils xdotool xfce4

  macOS の権限設定手順と Linux の詳しいセットアップ手順はコンピュータの使用とデスクトップ共有を参照してください。

次のステップ

• Cloud Agents を実行する場所を選択: マネージド Cloud Agents、マイマシン、チームプールを比較します。
• マイマシン: 数分で最初のワーカーを接続し、個人用ワーカー、ワークスペースルート、ローカル MCP サーバーを設定します。
• チームプール: ワーカーをチームプールにまとめ、コントローラーでワーカーのキャパシティをスケールします。
• 連携: AWS Lambda、Cloudflare、Namespace、Modal、Daytona、E2B、Vercel、Tensorlake、Coder、SuperServe 向けのパートナーガイド、AWS Lambda MicroVMs、Cloudflare Containers、Kubernetes (anysphere/k8s-workers) 向けのリファレンステンプレートです。
• コンピュータの使用: ワーカー上でエージェントにデスクトップやブラウザを操作させます。
• API リファレンス: ワーカー、プール、保留中のリクエストキュー (一覧、SSE ウォッチ、引き受け、リリース) 、ワーカートークン向けのエンドポイントです。
• セルフホスト型マシン: セットアップ、チームプール、連携、トラブルシューティングに関する簡潔な回答です。