Isolation
Sandbox runtime, network, and project isolation.
Daytona sandboxes are isolated by default. Each sandbox runs as a hardware-isolated microVM with its own kernel: 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 project. Isolation operates at three boundaries:
| Boundary | What is separated | Mechanisms |
|---|---|---|
| Runtime | Kernel, processes, filesystem, and memory of each sandbox | • Sandboxes • Resources |
| Network | Traffic entering (ingress) and leaving (egress) each sandbox | • Network policy • Preview • Ports |
| Project | Access to sandboxes, data, and credentials | • Projects • API keys • Secrets |
Runtime isolation
Runtime isolation separates what runs inside one sandbox from the host it executes on and from every other sandbox. Each sandbox runs as a Firecracker microVM with its own kernel, filesystem, and network stack. The boundary is enforced by the hypervisor, not by the guest: code inside a sandbox cannot observe or interfere with other sandboxes or the host.
Resources are part of the runtime boundary. Each sandbox has its own vCPU, memory, and disk, and the guest kernel sees only the resources of its own virtual machine. The guest boots with the burst ceiling of the sandbox, so nproc and /proc/meminfo report that ceiling, not the guaranteed CPU. Tools that size themselves from the CPU count, such as pytest -n auto or make -j$(nproc), start one worker per visible CPU.
nproc # vCPUs of the sandbox's virtual machine
grep MemTotal /proc/meminfo # memory of the sandbox's virtual machineNetwork isolation
Network isolation controls traffic in each direction separately. Egress is open by default and locked down per sandbox with a network policy; ingress is closed by default and opened per endpoint; sandboxes never share a network.
| Direction | Default | Controls |
|---|---|---|
| Sandbox to internet | Open egress | Network policy: default-deny with an allow list of IPs, CIDRs, and domains |
| Internet to sandbox | Closed; no port is reachable until exposed | Preview URLs (token-authenticated unless an endpoint is made public), declared ports, and SSH |
| Sandbox to sandbox | No shared network | None; sandboxes reach each other only through exposed endpoints |
Outbound traffic is open by default. A network policy turns on blocking and admits only the domains and IPv4 ranges on its allow lists. With blocking on and empty allow lists, the sandbox reaches no external address and DNS resolves no names.
from daytona import Daytona
daytona = Daytona()
# Block all outbound traffic
sandbox = daytona.v2.create(network_policy={"block_all": True})
# Or allow specific domains only
sandbox = daytona.v2.create(
network_policy={"allow_domains": ["example.com", "*.daytona.io"]},
)
# Or allow specific IPv4 ranges only
sandbox = daytona.v2.create(
network_policy={"block_all": True, "allow_cidrs": ["208.80.154.232/32", "192.168.1.0/24"]},
)Project isolation
Project isolation separates tenants. Organizations are the unit of membership and billing; projects are the unit of isolation. Every sandbox, image, snapshot, volume, secret, and project API key belongs to exactly one project, and access control is enforced at that boundary: a project API key cannot see or operate on another project's resources. Organization API keys are scoped to the organization.
Within a project, access narrows further to the following mechanisms:
| Mechanism | What it scopes | How it works |
|---|---|---|
| Scoped API keys | What a key can do | Each key carries an explicit verb:resource scope list chosen at creation, and every request is confined to those scopes; write: and delete: imply read: on the same resource. Keys can carry an expiry. Revocation takes effect immediately on the API; toolbox and SSH access through the proxy can continue for up to 30 seconds after revocation. |
| Secrets | Credentials used in a sandbox | A sandbox holds an opaque placeholder; an outbound proxy substitutes the real value only for requests to the secret's allowed domains. Responses are not rewritten, so a destination that echoes the credential back returns the real value into the sandbox. |
API key permissions scope what a key can do. A key created with only write:sandboxes and delete:sandboxes can manage sandboxes but cannot read secrets or delete images. A key can hold only permissions its creator holds.
# A key limited to creating and deleting sandboxes in one project
daytona key mint --project PROJECT_ID \
--name tenant-a-key \
--permission write:sandboxes,delete:sandboxes \
--expires 720h