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
Section titled “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
Section titled “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
Section titled “Project isolation”Project isolation separates tenants. Organizations are the unit of membership and billing; projects are the unit of isolation. Every sandbox, image, snapshot, 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. 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. |