# 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**](https://www.daytona.io/docs/en/v2/sandboxes.md) <br /> • [**Resources**](https://www.daytona.io/docs/en/v2/sandboxes.md#resources)                                                                      |
| **Network**  | Traffic entering (ingress) and leaving (egress) each sandbox | • [**Network policy**](https://www.daytona.io/docs/en/v2/network-limits.md) <br /> • [**Preview**](https://www.daytona.io/docs/en/v2/preview.md) <br /> • [**Ports**](https://www.daytona.io/docs/en/v2/linux-sandboxes.md#create-a-linux-sandbox) |
| **Project**  | Access to sandboxes, data, and credentials                   | • [**Projects**](https://www.daytona.io/docs/en/v2/projects.md) <br /> • [**API keys**](https://www.daytona.io/docs/en/v2/api-keys.md#permissions--scopes) <br /> • [**Secrets**](https://www.daytona.io/docs/en/v2/secrets.md)                       |

## 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**](https://www.daytona.io/docs/en/v2/network-limits.md): default-deny with an allow list of IPs, CIDRs, and domains                                                                |
| **Internet to sandbox** | Closed; no port is reachable until exposed | [**Preview URLs**](https://www.daytona.io/docs/en/v2/preview.md) (token-authenticated unless an endpoint is made public), [**declared ports**](https://www.daytona.io/docs/en/v2/linux-sandboxes.md#create-a-linux-sandbox), and [**SSH**](https://www.daytona.io/docs/en/v2/ssh-access.md) |
| **Sandbox to sandbox**  | No shared network                          | None; sandboxes reach each other only through exposed endpoints                                                                                                                           | 

## Project isolation

Project isolation separates tenants. [Organizations](https://www.daytona.io/docs/en/v2/organizations.md) are the unit of membership and billing; [projects](https://www.daytona.io/docs/en/v2/projects.md) 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**](https://www.daytona.io/docs/en/v2/api-keys.md#permissions--scopes) | 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**](https://www.daytona.io/docs/en/v2/secrets.md)                              | 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. |