# Bring Your Own Compute

Bring Your Own Compute (BYOC) enables you to run sandbox workloads on your own infrastructure while using Daytona's control plane to manage them.

Daytona provides [shared regions](https://www.daytona.io/docs/en/v2/regions.md#shared-regions) (`earth`, `us`, and `eu`) where Daytona owns the compute and handles provisioning, maintenance, monitoring, and scaling on your behalf.

With BYOC, Daytona provisions one or more [custom regions](#custom-regions) backed by runner nodes that run in your own environment. Each custom region gets its own regional API endpoint, sandbox proxy, and preview domain, so sandbox traffic stays inside your infrastructure.

<BringYourOwnComputeDiagram />

## Use cases

Bring your own compute is used when sandboxes must run on infrastructure you control.

- **Data residency**: sandboxes and their data stay in your environment and in the locations you choose. Each custom region has its own API endpoint, sandbox proxy, and preview domain.
- **Internal services**: sandbox traffic stays inside your infrastructure, so sandboxes reach internal systems without crossing the public internet. Toolbox, preview, SSH, and VNC traffic go through the region's own proxy.
- **Compliance requirements**: workloads that must not run on shared infrastructure run on runner nodes you own. Shared workloads never run on your runners.
- **Dedicated capacity**: the runners of a custom region serve only your sandboxes. Sandboxes targeted at the region never run on shared runners.
- **Existing hardware and cloud capacity**: sandboxes run on machines or cloud accounts you already pay for. Daytona provides the runner binary, a service definition, and a bootstrap script that enrolls each node.
- **No inbound access to your network**: runners connect outbound to the region's control plane and register on startup. No inbound connectivity into your network is required.
- **Capacity on your schedule**: you add capacity by enrolling more nodes with the same bootstrap tooling. Sandbox scheduling picks up new runners automatically.
- **One API for shared and custom regions**: the same API key works on the central and the regional APIs. Organizations, projects, and API keys are managed in one place.

## Custom regions

Custom regions run on compute your organization provides. You control data locality, compliance, and infrastructure configuration, and scale capacity per region independently.

Custom regions are provisioned by Daytona together with your team and are not self-service. Daytona configures the region in the control plane, sets up the regional API, proxy, and preview endpoints, and provides the tooling to enroll your runner nodes.

:::note
Contact [sales@daytona.io](mailto:sales@daytona.io) to set up a custom region for your organization.
:::

### View regions

Once a custom region is provisioned, it appears alongside the shared regions.

1. Go to [Daytona Regions ↗](https://app.daytona.com/dashboard/regions)
2. The **Regions** table lists every region available to your deployment with the following columns:
   - **Name**: the display name of the region
   - **Slug**: the identifier you pass as the **`region`** when creating sandboxes
   - **Status**: **`active`** or **`disabled`**
   - **Macro region**: the macro region the region belongs to
   - **Geo region**: the geo group of that macro region, such as United States or Europe
   - **API endpoint**: the central or regional API URL
3. Click a region to see its details, including the toolbox proxy URL and preview domain

The Regions page is read-only; regions are configured by Daytona.


```bash
daytona region list
```


```bash
curl 'https://api.daytona.com/regions' \
  --header 'Authorization: Bearer YOUR_API_KEY'
```


The response lists the regions at every level, parents before their children. A custom region is an edge region:

```json
{
  "regions": [
    {
      "id": "my-custom-region",
      "name": "My Custom Region",
      "level": "edge",
      "parent_region_id": "my-macro-region",
      "available": true,
      "api_base_url": "https://api.my-custom-region.example.com"
    }
  ]
}
```

| Field                    | Description                                                                                                       |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------- |
| **`id`**                 | Region ID. Use it as the **`region`** when creating sandboxes.                                                        |
| **`name`**               | Human-readable region name.                                                                                       |
| **`level`**              | **`edge`** for a custom region. Broader regions are **`macro`**, **`geo`**, or **`global`**.                                      |
| **`parent_region_id`**   | ID of the parent region. The parent of a custom region is its macro region.                                       |
| **`available`**          | Whether a create request can name this region. Always **`true`** for an edge region.                                  |
| **`api_base_url`**       | Regional API URL to send sandbox operations to. Omitted when the region is served by the central API.             |

Every custom region belongs to a macro region, and every macro region to a geo group, so a broad selector such as the US or EU [geo group](https://www.daytona.io/docs/en/v2/regions.md#list-regions) can place sandboxes on it when automatic placement is enabled. The same list includes the macro regions, the geo groups, and the global root.

### Create sandboxes in a custom region

A custom region's sandbox operations are served by its own API, not the central API. Pass the region's slug as `region` on each create.


```python
from daytona import Daytona

daytona = Daytona()

# Create a sandbox in the custom region
sandbox = daytona.v2.create(region="my-custom-region")
```


```typescript
import { Daytona } from '@daytona/sdk'

const daytona = new Daytona()

// Create a sandbox in the custom region
const sandbox = await daytona.v2.create({ region: 'my-custom-region' })
```


```bash
# Create a sandbox in the custom region
daytona sandbox create --api-url https://api.my-custom-region.example.com \
  --region my-custom-region
```


```bash
curl 'https://api.my-custom-region.example.com/sandboxes' \
  --request POST \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer YOUR_API_KEY' \
  --data '{
  "region": "my-custom-region"
}'
```


The same API key works on the central and regional APIs. Sandbox traffic (toolbox, preview, SSH, VNC) uses the region's toolbox proxy URL from the sandbox object, so it never leaves your infrastructure. Organization, project, and API key management stays on the central API.

## Runner nodes

Runner nodes are your machines that execute sandboxes. Daytona provides the runner binary, a service definition, and a bootstrap script that enrolls a node into your custom region.

- Runners connect outbound to the region's control plane and register themselves on startup. No inbound connectivity into your network is required.
- Runners pull work for their region only. Sandboxes targeted at your custom region never run on shared runners, and shared workloads never run on your runners.
- Add capacity by enrolling additional nodes with the same bootstrap tooling. Sandbox scheduling picks up new runners automatically.

Runner nodes are managed through Daytona's deployment tooling; the dashboard and public API have no runner enrollment.