Skip to main content
POST /v1/sandboxes:createFromFile は、アップロードされたファイルからサンドボックスを起動します。ファイルタイプとファイルのバイト列を送信すると、サンドボックスのゲートウェイがドキュメントをサンドボックスの spec に変換し、POST /v1/sandboxes と同じ作成処理を実行します。 受け付けるファイルタイプは Docker Compose (SANDBOX_FILE_TYPE_COMPOSE) のみです。ファイル内の各サービスは、単一のサンドボックス内のコンテナーになり、指定した 1 つのサービスがサンドボックスのプライマリになります。ゲートウェイはファイルのバイト列を保存しません。GET /v1/sandboxes/{sandboxId} は変換された spec を返します。 これは Docker Compose と同等の機能を提供するものではありません。既存の project をインポートする前に、Compose のサポートをお読みください。

始める前に

以下の例では Forge APIキーを使用します。詳しくははじめにを参照してください。キーは x-wandb-api-key ヘッダーで送信します。デフォルト以外の Forge entity にサンドボックスを作成する場合は、x-entity-id も送信してください。
SANDBOX_USER action を持つ CoreWeave API アクセストークンを使用することもできます。これは CKS への配置にも使用できます。認証情報を選択して取得するの手順に従ったうえで、トークンを設定します。
そのトークンを使用するには、このガイドのすべてのリクエストで -H "x-wandb-api-key: $FORGE_API_KEY" を -H "Authorization: Bearer $CWSANDBOX_API_KEY" に置き換えてください。認証方式とエラーの形式は、API のほかの部分と同じです。詳しくは、API の概要を参照してください。

リクエストフィールド

リクエストでは、mode、maxLifetimeSeconds、tags、network、objectStorageAccess、annotations、runnerIds、requestId も受け入れます。意味は POST /v1/sandboxes と同じです。networkIds は UNIMPLEMENTED を返します。 CKS への配置では、CoreWeave API アクセストークンを使用し、サンドボックスの配置とスピルオーバー の説明に従って配置フィールドを設定してください。オブジェクトストレージの前提条件については、サンドボックスに AI Object Storage へのアクセスを許可する を参照してください。 指定できるフィールドはこの一覧に限られます。このエンドポイントでは、ボリューム、インスタンスタイプ、ランタイムクラス、イメージをプルするための認証情報、公開サービスは利用できません。これらが必要な場合は、POST /v1/sandboxes を使用してください。

サンドボックスを作成する

Compose ファイルを作成します。
Write compose.yaml
contents を base64 エンコードして POST します。
Create a sandbox from compose.yaml
応答は STATE_CREATING 状態のサンドボックスです。STATE_RUNNING または終端状態になるまで、その sandboxId をポーリングします。
Poll the sandbox
返された spec には 2 つのコンテナーがあり、main はプライマリとして指定され、HELPER_HOST は引き続き helper に設定されています。サンドボックス内では、helper は 127.0.0.1 に解決されます。 作成を安全に再試行するには、requestId を送信します。同じ requestId と同じ宣言済みの入力を使用すると、既存のサンドボックスが返されます。同じ requestId でもバイト列が異なる場合は、空白のみの変更も含め、理由 CWSANDBOX_REQUEST_ID_CONFLICT とともに ALREADY_EXISTS が返されます。

Compose のサポート

すべてのサービスは、1 つの Pod と 1 つのネットワーク namespace を共有します。サービス名は 127.0.0.1 に解決されるため、HELPER_HOST: helper や API_BASE: http://main:8080 などの値は、ファイルを書き換えずに使用できます。サンドボックスには、サービスごとの IP アドレス、ブリッジネットワーク、レプリカはありません。 以下の動作は Docker Compose と異なります。
  • 起動は逐次実行されます。 プライマリ以外の各サービスは、プライマリより先に、順番に起動します。これを考慮して maxLifetimeSeconds を設定してください。サービスが準備完了にならない場合、サンドボックスは STATE_CREATING のままになります。
  • RUNNING はプライマリのみをトラッキングします。 起動後にヘルパーがクラッシュしても、サンドボックスは失敗しません。
  • healthcheck は exec のみの起動プローブになります。 test は string、CMD、CMD-SHELL、または NONE である必要があり、期間は整数秒で指定する必要があります。プローブの再試行回数を使い切ると、コンテナーは異常とマークされるのではなく、停止されます。
  • ポートは Pod 内にとどまります。 expose と ports は待ち受けポートを宣言しますが、外部には公開されません。
  • イメージはプル可能である必要があります。 すべてのサービスで、ファイル内の image: または imageOverrides 内のエントリが必要です。依然として build: が必要なサービスは、UNIMPLEMENTED を返します。
  • command と entrypoint は Docker のシェル形式と exec 形式に従います。 イメージのデフォルトを使用するには、これらを省略してください。明示的な null と [] は拒否されます。
  • GPU はプライマリ専用です。deploy.resources.reservations.devices で gpu 機能と正の整数の個数を指定します。
  • 名前は DNS-1123 ラベルである必要があります (My_App ではなく my-app) 。また、予約済みの接頭辞 cw-object-store-agent、cw-object-store-agent-restore、dns-egress は使用できません。

サポートされないキー

ドキュメントは自己完結している必要があります。ゲートウェイはディスクを読み取らず、環境変数も展開しません。認識されないキーは無視されず、問題のあるフィールドのパスとともに拒否されます。 ゲートウェイは version、project の name、labels、x-* 拡張キーを無視します。labels がサンドボックスに渡されることを前提にしないでください。

よくあるエラー

フィールド違反は、パスと制限値を示す BadRequest の詳細として返されます。ドキュメントの内容は引用されません。

関連情報

  • はじめに: spec から最初のサンドボックスを作成します。
  • API の概要: 認証、バージョン管理、エラー処理について説明します。
  • サンドボックスの環境変数: プラットフォームが各コンテナーに注入する環境変数について説明します。
最終更新日 2026年10月15日