Skip to main content
POST /v1/sandboxes:createFromFile starts a sandbox from an uploaded file. You send a file type and the file bytes, and the sandbox gateway translates the document into a sandbox spec and runs the same create path as POST /v1/sandboxes. Docker Compose (SANDBOX_FILE_TYPE_COMPOSE) is the only accepted file type. Every service in the file becomes a container in a single sandbox, and one service you name becomes the sandbox primary. The gateway doesn’t store the file bytes. GET /v1/sandboxes/{sandboxId} returns the translated spec. This isn’t Docker Compose equivalence. Before you import an existing project, read Compose support.

Before you begin

W&B の APIキーが必要です。詳しくははじめにを参照してください。キーは x-wandb-api-key ヘッダーで送信します。デフォルト以外の W&B entity でサンドボックスを作成する場合は、x-entity-id も併せて送信してください。

Request fields

このリクエストでは、maxLifetimeSeconds、tags、network、annotations、requestId も受け入れられます。各パラメーターの意味は POST /v1/sandboxes と同じです。networkIds を指定すると UNIMPLEMENTED が返されます。 This field list is closed. Volumes, instance type, runtime class, image-pull credentials, and published services aren’t available on this endpoint. Use POST /v1/sandboxes when you need them.

Create the sandbox

Write a Compose file:
Write compose.yaml
Post it with contents base64-encoded:
Create a sandbox from compose.yaml
The response is a sandbox in STATE_CREATING. Poll its sandboxId until it reaches STATE_RUNNING or a terminal state:
Poll the sandbox
The returned spec has two containers, main marked primary, and HELPER_HOST still set to helper. Inside the sandbox, helper resolves to 127.0.0.1. To retry a create safely, send requestId. The same requestId with the same declared inputs returns the existing sandbox. The same requestId with different bytes, including a whitespace-only change, returns ALREADY_EXISTS with reason CWSANDBOX_REQUEST_ID_CONFLICT.

Compose support

All services share one pod and one network namespace. Service names resolve to 127.0.0.1, so values such as HELPER_HOST: helper and API_BASE: http://main:8080 work without rewriting the file. The sandbox has no per-service IP addresses, bridge networks, or replicas. The following behavior differs from Docker Compose:
  • Startup is serial. Every non-primary service starts one after another, before the primary. Size maxLifetimeSeconds for that. A service that never becomes ready leaves the sandbox in STATE_CREATING.
  • RUNNING tracks the primary only. A helper that crashes after start doesn’t fail the sandbox.
  • healthcheck becomes an exec-only startup probe. test must be a string, CMD, CMD-SHELL, or NONE, and durations must be whole seconds. When the probe exhausts its retries, the container is stopped rather than marked unhealthy.
  • Ports stay in the pod. expose and ports declare listen ports, but nothing is published externally.
  • Images must be pullable. Every service needs image: in the file or an entry in imageOverrides. A service that still needs build: returns UNIMPLEMENTED.
  • command and entrypoint follow Docker’s shell and exec forms. Omit them to use the image defaults. Explicit null and [] are rejected.
  • GPUs are primary-only, through deploy.resources.reservations.devices with the gpu capability and a positive integer count.
  • Names must be DNS-1123 labels (my-app, not My_App), and can’t use the reserved cw-object-store-agent, cw-object-store-agent-restore, or dns-egress prefixes.

Unsupported keys

The document must be self-contained: the gateway doesn’t read your disk and doesn’t expand your environment. Unrecognized keys are rejected with the offending field path rather than ignored. The gateway ignores version, project name, labels, and x-* extension keys. Don’t rely on labels reaching the sandbox.

Common errors

Field violations arrive as BadRequest details naming the path and the limit. They don’t quote your document.

See also

最終更新日 2026年10月5日