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.
Network 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 |
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 API key belongs to exactly one project, and access control is enforced at that boundary: an API key from one project cannot see or operate on another project's resources.
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, and revocation takes effect immediately for new requests. |
| 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. |
| Volume subpath | Shared data across tenants | Volumes are scoped with a subpath so each sandbox mounts only its tenant's slice. |