# Scale

Daytona sandboxes are designed to be created and operated at high volume. A single sandbox scales up by resizing its reserved resources, a fleet scales out by running many sandboxes at once, and each sandbox runs multiple processes concurrently. 

Unlike request-based execution environments, a sandbox is a long-lived computer: processes are not terminated after a request completes, so running services, open connections, and background workers persist until the sandbox stops.

Scale operates along three dimensions:

| **Dimension**            | **What scales**                                  | **Mechanisms**                                                                                                                                                                                                                                        |
| ------------------------ | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Sandbox (vertical)       | vCPU, RAM, and disk of a single sandbox          | • <u>[**Custom resources**](https://www.daytona.io/docs/en/sandboxes.md#resources)</u> <br /> • <u>[**Resize**](https://www.daytona.io/docs/en/sandboxes.md#resize-sandboxes)</u>                                                                                                                       |
| Fleet (horizontal)       | Number of sandboxes running at the same time     | • <u>[**Snapshot fan-out**](https://www.daytona.io/docs/en/snapshots.md)</u> <br /> • <u>[**Fork**](https://www.daytona.io/docs/en/sandboxes.md#fork-sandboxes)</u> <br /> • <u>[**Linked sandboxes**](https://www.daytona.io/docs/en/sandboxes.md#linked-sandboxes)</u>                                                         |
| Workload (concurrency)   | Concurrent processes inside a single sandbox     | • <u>[**Sessions**](https://www.daytona.io/docs/en/process-code-execution.md#session-operations)</u> <br /> • <u>[**Async commands**](https://www.daytona.io/docs/en/process-code-execution.md#session-operations)</u> <br /> • <u>[**PTY sessions**](https://www.daytona.io/docs/en/pty.md)</u>                                 |

## Sandbox scaling

Sandbox scaling changes the resources of a single sandbox: **vCPU**, **memory**, and **disk**. Resources are reserved when the sandbox is created and can be changed later by resizing.

Resources are set differently depending on how the sandbox is created:

- **From an image**: set **`resources`** on the create parameters
- **From a snapshot**: the sandbox inherits the resources defined on the snapshot

Resizing changes the allocation of an existing sandbox. On a running sandbox, CPU and memory can be increased without interruption. Decreasing CPU or memory, or increasing disk, requires the sandbox to be stopped first. Disk can only grow, and GPU allocation cannot be resized. Every allocation must stay within your organization's per-sandbox limits.


```python
from daytona import CreateSandboxFromImageParams, Daytona, Resources

daytona = Daytona()

# Reserve 2 vCPUs, 4GiB of RAM, and 8GiB of disk for the sandbox
sandbox = daytona.create(
    CreateSandboxFromImageParams(
        image="ubuntu:22.04",
        resources=Resources(cpu=2, memory=4, disk=8),
    )
)
```


```python
from daytona import Daytona, Resources

daytona = Daytona()
sandbox = daytona.get("my-sandbox")

# CPU and memory can be increased while the sandbox is running
sandbox.resize(Resources(cpu=4, memory=8))

# Decreasing CPU or memory, or increasing disk, requires a stopped sandbox
sandbox.stop()
sandbox.resize(Resources(cpu=2, memory=4, disk=20))
sandbox.start()
```


## Fleet scaling

Fleet scaling raises the number of sandboxes running at the same time. The unit of scale is the sandbox itself: instead of packing unrelated workloads into one environment, create one sandbox per user, task, or agent.

Sandboxes are isolated from each other, so a fleet scales linearly: each new sandbox adds capacity without contention, and a failure in one sandbox does not affect the others.

The mechanisms differ in what state each new sandbox starts with:

| **Mechanism**                                                              | **Starting state**                                                    | **Use**                                                                            |
| --------------------------------------------------------------------------- | ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------ |
| <u>[**Snapshot fan-out**](https://www.daytona.io/docs/en/snapshots.md)</u>                          | Filesystem from the snapshot; hot snapshots add memory state           | Any number of identical environments from one prepared snapshot                     |
| <u>[**Fork**](https://www.daytona.io/docs/en/sandboxes.md#fork-sandboxes)</u>                       | Filesystem and memory of a running VM sandbox                          | Branch a live environment into independent copies                                   |
| <u>[**Linked sandboxes**](https://www.daytona.io/docs/en/sandboxes.md#linked-sandboxes)</u>         | Fresh environment, co-located with a parent on the same runner         | Coordinated groups with a local network between parent and children                 |

**Snapshot fan-out** is the default pattern: prepare the environment once, capture it as a snapshot, and create any number of sandboxes from it. Each sandbox starts with the environment intact, with nothing to reinstall. Sandboxes created from a [hot snapshot](https://www.daytona.io/docs/en/snapshots.md#create-snapshot-from-sandbox) start with processes already running.

**Forking** duplicates a running VM sandbox, filesystem and memory included, into an independent sandbox. Where snapshot fan-out distributes a prepared baseline, forks branch live state: each fork continues from the exact point the original was at. Forking is supported for [VM sandboxes](https://www.daytona.io/docs/en/sandboxes.md#vm-sandboxes) (Linux VM and Windows) only.

**Linked sandboxes** attach ephemeral child sandboxes to a parent. Children are scheduled on the same runner as the parent and share a link network, so the group communicates over local connections. One parent may have many children, and deleting the parent deletes all of them.


```python
import asyncio

from daytona import AsyncDaytona, CreateSandboxFromSnapshotParams


async def run_task(daytona: AsyncDaytona, shard: int) -> str:
    # Each task gets its own isolated, ephemeral sandbox
    sandbox = await daytona.create(
        CreateSandboxFromSnapshotParams(snapshot="my-env-snapshot", ephemeral=True)
    )
    response = await sandbox.process.exec(f"python3 run.py --shard {shard}")

    # Stop deletes the ephemeral sandbox
    await sandbox.stop()
    return response.result


async def main():
    async with AsyncDaytona() as daytona:
        # Create and run 20 sandboxes concurrently from the same snapshot
        results = await asyncio.gather(*(run_task(daytona, i) for i in range(20)))
        print(results)


asyncio.run(main())
```


```python
from daytona import CreateSandboxFromSnapshotParams, Daytona

daytona = Daytona()
sandbox = daytona.create(CreateSandboxFromSnapshotParams(snapshot="daytona-vm-small"))

# Prepare live state once: running processes, loaded caches, open connections
sandbox.process.exec("python3 warmup.py")

# Each fork continues from the same live state, fully independent
forks = [sandbox._experimental_fork(name=f"agent-{i}") for i in range(5)]
```


```python
from daytona import CreateSandboxFromSnapshotParams, Daytona

daytona = Daytona()

parent = daytona.create()

# Children are co-located with the parent and share a link network
children = [
    daytona.create(
        CreateSandboxFromSnapshotParams(
            linked_sandbox=parent.id,
            ephemeral=True,
        )
    )
    for _ in range(3)
]

# Each sandbox on the link network is reachable by name or ID
response = children[0].process.exec(f"curl http://{parent.name}:3000/")
```


## Workload concurrency

Workload concurrency runs multiple processes inside a single sandbox. A single sandbox can run an API server, a database, and background workers side by side: all processes share the sandbox's filesystem and network, and exposed ports are reachable through [previews](https://www.daytona.io/docs/en/preview.md).

A sandbox runs concurrent processes through [sessions](https://www.daytona.io/docs/en/process-code-execution.md#session-operations). Each session is an independent shell with its own state: working directory, environment variables, and command history. 

Commands within a session run sequentially, so parallelism comes from running multiple sessions. Commands started with `run_async` return immediately and run in the background, and [PTY sessions](https://www.daytona.io/docs/en/pty.md) add interactive terminals.


```python
from daytona import Daytona, SessionExecuteRequest

daytona = Daytona()
sandbox = daytona.create()

# Each session is an independent shell inside the same sandbox
sandbox.process.create_session("server")
sandbox.process.create_session("worker")

# The server runs in the background while the worker session stays free
sandbox.process.execute_session_command("server", SessionExecuteRequest(
    command="python3 -m http.server 8000",
    run_async=True,
))
response = sandbox.process.execute_session_command("worker", SessionExecuteRequest(
    command="curl -s http://localhost:8000",
))
print(response.output)
```


```python
from daytona import Daytona, SessionExecuteRequest

daytona = Daytona()
sandbox = daytona.create()
sandbox.process.create_session("build")

# Async commands return immediately with a command ID
command = sandbox.process.execute_session_command("build", SessionExecuteRequest(
    command="make build",
    run_async=True,
))

# Check on the command later by its ID
status = sandbox.process.get_session_command("build", command.cmd_id)
print(status.exit_code)
```


## Capacity and throughput

Fleet size and creation rate operate within your organization's limits. Both are [tier-based](https://www.daytona.io/docs/en/limits.md#tiers) and raised by verification steps or by contacting support.

| **Control**                                                       | **What it limits**                                                    | **Scope**                                        |
| ------------------------------------------------------------------ | ----------------------------------------------------------------------- | -------------------------------------------------- |
| <u>[**Compute pool**](https://www.daytona.io/docs/en/limits.md#resources)</u>              | Total vCPU, RAM, and storage across all running sandboxes              | Organization, per region and sandbox class        |
| <u>[**Per-sandbox limits**](https://www.daytona.io/docs/en/limits.md)</u>   | Maximum vCPU, RAM, and storage of a single sandbox                     | Sandbox                                           |
| <u>[**Rate limits**](https://www.daytona.io/docs/en/limits.md#rate-limits)</u>             | Sandbox creation, lifecycle operations, and API requests per minute    | Organization                                      |

To scale beyond the shared compute pool, [bring your own compute (BYOC)](https://www.daytona.io/docs/en/bring-your-own-compute.md) attaches your own runner nodes in custom regions, which have no concurrent resource usage limits.

### Reclaiming capacity

The compute pool is shared by running sandboxes only: stopped, paused, and archived sandboxes free their reserved CPU and memory back to the pool. A fleet can therefore be much larger than the pool, as long as the concurrently running subset fits.

Reclamation runs automatically. [Ephemeral sandboxes](https://www.daytona.io/docs/en/sandboxes.md#ephemeral-sandboxes) delete themselves on stop, and the [auto-stop, auto-pause, and auto-delete intervals](https://www.daytona.io/docs/en/sandboxes.md#automated-lifecycle-management) reclaim capacity from idle sandboxes without manual intervention. See [persistence](https://www.daytona.io/docs/en/persistence.md#retention-and-lifecycle) for details.

### Operating at scale

At high creation rates, two practices keep an application within its rate limits.

- Handle [rate limit errors](https://www.daytona.io/docs/en/limits.md#rate-limit-errors): the SDKs raise **`DaytonaRateLimitError`** when a limit is exceeded, and the returned headers indicate how long to wait before retrying the request.
- Use [webhooks](https://www.daytona.io/docs/en/webhooks.md) to track sandbox state changes instead of polling. Webhooks deliver state changes as they happen, so no requests are spent checking for status.