Skip to main content
The REST spawn request has one public network control:
enabled defaults to true. When false, the VM starts without a guest network interface. Set it on every independent operation that requires this boundary. An additional subprocess shares its parent VM and cannot select a separate VM network setting. Use networking.enabled=false when the workload must run without a guest network interface. Inspect /sys/class/net and assert that no interface other than loopback is present so the workload verifies this boundary without depending on an external service. See Verify with networking disabled. If the workload requires destination allowlists, private networking, ingress, specific DNS behavior, or network logs, contact the Sandboxes team to confirm support before deployment.

​
Separate setup and verification

Fetch dependencies and fixtures in a controlled setup operation, retain the result, then run verification from its immutable UUID with networking disabled. Saving an image carries filesystem state, not the earlier network policy, connection, DNS cache, or authentication session.

​
Credential boundary

  • Keep the API credential in the client process; sandbox code does not need it unless it intentionally calls the control plane.
  • Pass short-lived, narrow credentials only to operations that need them.
  • Avoid command-line arguments, stdout, stderr, uploaded files, Dockerfile arguments, and retained filesystem locations for secrets.
  • preserve_env=True writes the combined environment into result-image metadata. Leave it false for secrets.
  • A disposable run prevents its filesystem changes from becoming a branch source, but it is not a deletion or log-retention guarantee.
Before sharing operation diagnostics, remove authorization headers, credentials, customer data, and sensitive command output. Confirm encryption-at-rest, deletion, and retention requirements with the Sandboxes team before processing data that depends on those guarantees; see Security and data handling.