Isolation
Sandbox runtime, network, and organization isolation.
Daytona sandboxes are isolated by default. Code running in a sandbox cannot read another sandbox's filesystem or memory, is not on a shared network with other sandboxes, and its credentials and API access are scoped to its own organization.
Isolation operates at three boundaries:
| Boundary | What is separated | Mechanisms |
|---|---|---|
| Runtime | Processes, filesystem, memory, and devices of each sandbox | • Sandbox classes • Reserved resources |
| Network | Traffic entering (ingress) and leaving (egress) each sandbox | • Network limits • Preview authentication • Link networks |
| Organization | Access to sandboxes, data, and credentials | • Organizations • API key permissions • Secrets |
Runtime isolation
Runtime isolation separates what runs inside one sandbox from the runner it executes on and from every other sandbox. Each sandbox runs as an isolated instance with its own processes, network, filesystem mounts, and inter-process communication: see architecture for details.
Resources are part of the runtime boundary. Each sandbox reserves its own vCPU, memory, and disk, enforced as hard limits, so one sandbox cannot consume the resources of another regardless of what its code does. Sandbox classes differ in the kind of boundary they provide:
| Sandbox class | Runtime boundary |
|---|---|
| Container | Isolated container with dedicated namespaces and enforced resource limits. Code runs as root inside the sandbox without affecting the runner. |
| VM sandboxes (Linux VM and Windows) | Full virtual machine with its own kernel. The hardware virtualization boundary enables VM-only capabilities: pause / resume, fork, and hot snapshots. |
| GPU | Isolated container with exclusive GPU allocation: assigned GPU devices belong to one sandbox at a time and are never shared. |
Resource limits are visible inside the sandbox through cgroup values. Tools such as nproc and free read host-level values and do not reflect the sandbox's own limits:
cat /sys/fs/cgroup/cpu.max # "<quota> <period>" (cores = quota / period)
cat /sys/fs/cgroup/memory.max # bytes
df -h / # diskNetwork isolation
Network isolation controls traffic in each direction separately. Outbound and inbound access are configured per sandbox; sandbox-to-sandbox networking is off unless sandboxes are explicitly linked.
| Direction | Default | Controls |
|---|---|---|
| Sandbox to internet | Open on Tier 3 and above; restricted on Tier 1 and 2 | Network limits: block all, CIDR allow list, domain allow list, or outbound proxy |
| Internet to sandbox | Authenticated preview URLs and SSH access | Preview tokens and signed URLs and SSH tokens; the public flag opts previews out of authentication |
| Sandbox to sandbox | No shared network | Linked sandboxes join a parent and its children into a link network |
Outbound traffic passes a per-sandbox firewall. Tier-based restrictions apply automatically, and each sandbox can be locked down further with one of three mutually exclusive settings: block all traffic, allow specific CIDR ranges, or allow specific domains. Essential services such as package registries stay reachable on all tiers.
from daytona import CreateSandboxFromSnapshotParams, Daytona
daytona = Daytona()
# Block all outbound traffic
sandbox = daytona.create(CreateSandboxFromSnapshotParams(
network_block_all=True,
))
# Or allow specific domains only
sandbox = daytona.create(CreateSandboxFromSnapshotParams(
domain_allow_list="example.com,*.daytona.io",
))
# Or allow specific CIDR ranges only
sandbox = daytona.create(CreateSandboxFromSnapshotParams(
network_allow_list="208.80.154.232/32,192.168.1.0/24",
))Organization isolation
Organization isolation separates tenants. Every sandbox, snapshot, and volume belongs to exactly one organization, and access control is enforced at that boundary: an API key from one organization cannot see or operate on another organization's resources.
Within an organization, access narrows further to the following mechanisms:
API key permissions scope what a key can do. A key issued with only write:sandboxes cannot delete snapshots or read volumes.
Managed API keys issue scoped child keys at runtime, so a multi-tenant application can hand each tenant a key limited to its own operations.
# A manager key issues a child key scoped to one tenant's operations;
# child key permissions must be a subset of the manager key's permissions
curl 'https://app.daytona.io/api/api-keys' \
--request POST \
--header 'X-Daytona-Organization-ID: YOUR_ORGANIZATION_ID' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer YOUR_MANAGER_API_KEY' \
--data '{
"name": "tenant-a-key",
"permissions": ["write:sandboxes", "delete:sandboxes"]
}'