kind, metadata,
spec, and read-only status fields, and it uses a pod template to describe
the Linux environment to run.
When to use a Sandbox
Use a Sandbox when you need a temporary environment for:- Agent workspaces.
- Experiments.
- Tests.
- Builds.
- Debugging.
- Preview environments.
Lifecycle
Every Sandbox has a requiredspec.ttl. The TTL uses duration strings such as
15m, 2h, or 24h. IDYL removes the Sandbox after the duration expires
unless it is deleted earlier.
Use idyl delete sandbox <name> to remove a Sandbox before expiry.
Names and placement
The imperative CLI workflow can generate a Sandbox name:--name when you want to choose the name:
metadata.name:
metadata.subnet in manifests or --subnet in CLI commands to choose the
subnet where the Sandbox should run.
Isolation
Sandboxes can request a workload isolation class when allowed by the target subnet:| Isolation class | Use |
|---|---|
container | Standard container isolation. |
microvm | MicroVM-backed workload isolation. |
Runtime status
When available, Sandbox status reports the associated pod for the environment. Inspect the Sandbox to see TTL, expiry, image, and associated pod information:idyl get sandboxes to list Sandboxes in the current namespace.
Command scope
The documented Sandbox CLI workflow is create, inspect, apply, and delete:shell, exec, cp, logs, wait, and scale commands
are not part of the documented Sandbox CLI workflow. Use the published workload
commands for behavior documented outside the Sandbox workflow.

