Skip to main content
POST /v1/sandboxes:createFromFile démarre une sandbox à partir d’un fichier téléversé. Vous envoyez un type de fichier et le contenu binaire du fichier ; la passerelle des sandboxes convertit alors le document en spécification de sandbox et suit le même processus de création que POST /v1/sandboxes. Docker Compose (SANDBOX_FILE_TYPE_COMPOSE) est le seul type de fichier accepté. Chaque service du fichier devient un conteneur au sein d’une même sandbox, et le service que vous désignez devient le conteneur principal de la sandbox. La passerelle ne stocke pas le contenu du fichier. GET /v1/sandboxes/{sandboxId} renvoie la spécification convertie. Cette fonctionnalité n’offre pas une équivalence complète avec Docker Compose. Avant d’importer un projet existant, consultez Prise en charge de Compose.

Avant de commencer

Les exemples suivants utilisent une clé API Forge. Voir Premiers pas. Transmettez la clé dans l’en-tête x-wandb-api-key. Pour créer la sandbox dans une entity Forge autre que votre entity par défaut, transmettez également l’en-tête x-entity-id.
Vous pouvez également utiliser un jeton d’accès à l’API CoreWeave avec l’action SANDBOX_USER, y compris pour le placement sur CKS. Suivez les instructions de la section Choisir et obtenir des identifiants d’authentification, puis définissez le jeton :
Pour chaque requête de ce guide, remplacez -H "x-wandb-api-key: $FORGE_API_KEY" par -H "Authorization: Bearer $CWSANDBOX_API_KEY" afin d’utiliser ce jeton. L’authentification et le format des erreurs sont les mêmes que pour le reste de l’API. Voir Aperçu de l’API.

Champs de la requête

La requête accepte également mode, maxLifetimeSeconds, tags, network, objectStorageAccess, annotations, runnerIds et requestId, avec la même signification que pour POST /v1/sandboxes. networkIds renvoie UNIMPLEMENTED. Pour un placement sur CKS, utilisez un jeton d’accès à l’API CoreWeave et configurez les champs de placement comme décrit dans Placement et débordement des sandboxes. Pour les prérequis liés au stockage d’objets, consultez Accorder aux sandboxes l’accès à AI Object Storage. Cette liste de champs est exhaustive. Les volumes, le type d’instance, la classe de runtime, les identifiants d’authentification pour la récupération d’images et les services publiés ne sont pas disponibles sur ce point de terminaison. Utilisez POST /v1/sandboxes si vous en avez besoin.

Créer la sandbox

Écrivez un fichier Compose :
Write compose.yaml
Envoyez-le via une requête POST, avec contents encodé en base64 :
Create a sandbox from compose.yaml
La réponse renvoie une sandbox à l’état STATE_CREATING. Interrogez-la régulièrement à l’aide de son sandboxId jusqu’à ce qu’elle atteigne l’état STATE_RUNNING ou un état terminal :
Poll the sandbox
La spécification renvoyée comporte deux conteneurs : main, marqué comme principal, et HELPER_HOST, toujours défini sur helper. Dans le sandbox, helper est résolu en 127.0.0.1. Pour relancer une création sans risque, envoyez requestId. Un même requestId associé aux mêmes entrées déclarées renvoie le sandbox existant. Un même requestId associé à des octets différents, y compris lorsque la modification ne porte que sur des caractères d’espacement, renvoie ALREADY_EXISTS avec le motif CWSANDBOX_REQUEST_ID_CONFLICT.

Prise en charge de Compose

Tous les services partagent un même pod et un même namespace réseau. Les noms de service sont résolus en 127.0.0.1, si bien que des valeurs telles que HELPER_HOST: helper et API_BASE: http://main:8080 fonctionnent sans qu’il soit nécessaire de réécrire le fichier. La sandbox ne dispose ni d’adresses IP par service, ni de réseaux bridge, ni de répliques. Les comportements suivants diffèrent de ceux de Docker Compose :
  • Le démarrage est séquentiel. Les services non principaux démarrent les uns après les autres, avant le service principal. Dimensionnez maxLifetimeSeconds en conséquence. Si un service ne devient jamais prêt, la sandbox reste dans l’état STATE_CREATING.
  • RUNNING ne suit que le service principal. Le plantage d’un service auxiliaire après son démarrage ne fait pas échouer la sandbox.
  • healthcheck devient une sonde de démarrage de type exec uniquement. test doit être une chaîne, CMD, CMD-SHELL ou NONE, et les durées doivent être exprimées en secondes entières. Lorsque la sonde a épuisé ses tentatives, le conteneur est arrêté au lieu d’être marqué comme défaillant.
  • Les ports restent internes au pod. expose et ports déclarent des ports d’écoute, mais rien n’est publié à l’extérieur.
  • Les images doivent pouvoir être récupérées. Chaque service doit avoir une clé image: dans le fichier ou une entrée dans imageOverrides. Un service qui requiert encore build: renvoie UNIMPLEMENTED.
  • command et entrypoint suivent les formes shell et exec de Docker. Omettez-les pour utiliser les valeurs par défaut de l’image. Les valeurs explicites null et [] sont rejetées.
  • Les GPU sont réservés au service principal, via deploy.resources.reservations.devices avec la capacité gpu et un nombre entier positif.
  • Les noms doivent être des libellés DNS-1123 (my-app, et non My_App) et ne peuvent pas utiliser les préfixes réservés cw-object-store-agent, cw-object-store-agent-restore ou dns-egress.

Clés non prises en charge

Le document doit être autonome : la passerelle ne lit pas votre disque et ne développe pas les variables de votre environnement. Les clés non reconnues ne sont pas ignorées, mais rejetées avec le chemin du champ en cause. La passerelle ignore les clés version, name du projet, labels et les clés d’extension x-*. Ne comptez pas sur la transmission des labels à la sandbox.

Erreurs courantes

Les violations de champ sont renvoyées sous forme de détails BadRequest qui indiquent le chemin et la limite concernés. Elles ne reprennent pas le contenu de votre document.

Voir aussi

Dernière modification le 15 octobre 2026