---
title: Limits
description: Overview of your organization's resource limits and usage.
---

import { TabItem, Tabs } from '@astrojs/starlight/components'

[Daytona Limits ↗](https://app.daytona.io/dashboard/limits) provide an overview of your organization's [current usage](#current-usage), [resources](#resources), [sandbox limits](#sandbox-limits), and [rate limits](#rate-limits). Daytona uses a [tier-based](#tiers) system where organizations are placed into tiers based on verification status, with each tier providing access to a specific compute pool and rate limits. For information on spending and wallet management, see [billing](/docs/en/billing).

## Current usage

Current usage provides a summary of your organization's resource usage, tier and region.

### Resources

Resources are shared across all running sandboxes. The number of sandboxes you can run at once depends on their individual usage. Organizations are automatically placed into a tier based on verification status and have access to a compute pool consisting of:

- **Compute**: the total CPU cores available
- **Memory**: the total RAM available
- **Storage**: the total disk space available

### Sandbox limits

Sandbox limits provides an overview of resource limits per sandbox.

- **Compute**: the maximum number of vCPUs per sandbox
- **Memory**: the maximum amount of memory per sandbox in GiB
- **Storage**: the maximum amount of storage per sandbox in GiB

### Rate limits

Rate limits control how many API requests you can make within a specific time window. These limits are applied based on your tier, authentication status, and the type of operation you're performing. Rate limits for general authenticated requests are tracked per organization.

| **Tier**   | **General Requests (per min)** | **Sandbox Creation (per min)** | **Sandbox Lifecycle (per min)** |
| ---------- | ------------------------------ | ------------------------------ | ------------------------------- |
| Tier 1     | 10,000                         | 300                            | 10,000                          |
| Tier 2     | 20,000                         | 400                            | 20,000                          |
| Tier 3     | 40,000                         | 500                            | 40,000                          |
| Tier 4     | 50,000                         | 600                            | 50,000                          |
| Enterprise | Custom                         | Custom                         | Custom                          |

Daytona supports managing your sandbox resources by [changing the sandbox state](/docs/sandboxes#sandbox-lifecycle). The table below summarizes how each state affects sandbox resource usage:

| **State** | **vCPU** | **Memory** | **Storage** | **Description**                               |
| --------- | -------- | ---------- | ----------- | --------------------------------------------- |
| Running   | ✅       | ✅         | ✅          | Counts against all limits                     |
| Stopped   | ❌       | ❌         | ✅          | Frees CPU & memory, but storage is still used |
| Archived  | ❌       | ❌         | ❌          | Data moved to cold storage, no quota impact   |
| Deleted   | ❌       | ❌         | ❌          | All resources freed                           |

#### Rate limit headers

Daytona includes rate limit information in API response headers. Header names include a suffix based on which rate limit is triggered (e.g., `-anonymous`, `-authenticated`, `-sandbox-create`, `-sandbox-lifecycle`):

| Header Pattern                          | Description                                                               |
| --------------------------------------- | ------------------------------------------------------------------------- |
| **`X-RateLimit-Limit-{throttler}`**     | Maximum number of requests allowed in the time window                     |
| **`X-RateLimit-Remaining-{throttler}`** | Number of requests remaining in the current window                        |
| **`X-RateLimit-Reset-{throttler}`**     | Time in seconds until the rate limit window resets                        |
| **`Retry-After-{throttler}`**           | Time in seconds to wait before retrying (included when limit is exceeded) |

#### Rate limit errors

Daytona [Python](/docs/python-sdk), [TypeScript](/docs/en/typescript-sdk), [Ruby](/docs/ruby-sdk) and [Go](/docs/go-sdk) SDKs raise or throw a `DaytonaRateLimitError` exception (Python) or error (TypeScript, Ruby and Go) when you exceed a rate limit.

The rate limit error response is a JSON object with the following properties:

- **`statusCode`**: the HTTP status code of the error
- **`message`**: the error message
- **`error`**: the error type

```json
{
  "statusCode": 429,
  "message": "Rate limit exceeded",
  "error": "Too Many Requests"
}
```

All errors include [**`headers`**](#rate-limit-headers) and status code properties, allowing access to rate limit headers directly from the error object. Headers support case-insensitive access:

<Tabs>
  <TabItem label="TypeScript" icon="seti:typescript">
    ```typescript
    try {
      await daytona.create()
    } catch (error) {
      if (error instanceof DaytonaRateLimitError) {
        console.log(error.headers?.get('x-ratelimit-remaining-sandbox-create'))
        console.log(error.headers?.get('X-RateLimit-Remaining-Sandbox-Create')) // also works
      }
    }
    ```
  </TabItem>
  <TabItem label="Python" icon="seti:python">
    ```python
    try:
      daytona.create(snapshot="my-snapshot")
    except DaytonaRateLimitError as e:
      print(e.headers['x-ratelimit-remaining-sandbox-create'])
      print(e.headers['X-RateLimit-Remaining-Sandbox-Create'])  # also works
    ```
  </TabItem>
  <TabItem label="Ruby" icon="seti:ruby">
    ```ruby
    begin
      daytona.create
    rescue Daytona::Sdk::Error => e
      puts "Error: #{e.message}"
    end
    ```
  </TabItem>
  <TabItem label="Go" icon="seti:go">
    ```go
    sandbox, err := daytona.Create(ctx, nil)
    if err != nil {
      var rateLimitErr *errors.DaytonaRateLimitError
      if errors.As(err, &rateLimitErr) {
        fmt.Println(rateLimitErr.Headers.Get("x-ratelimit-remaining-sandbox-create"))
        fmt.Println(rateLimitErr.Headers.Get("X-RateLimit-Remaining-Sandbox-Create")) // also works
      }
    }
    ```
  </TabItem>
</Tabs>

### Tiers

Limits are applied to your organization's default region. To unlock higher limits, complete the following verification steps in the [Daytona Dashboard ↗](https://app.daytona.io/dashboard/limits):

| **Tier** | **Resources (vCPU / RAM / Storage)** | **Access Requirements**                                 |
| -------- | ------------------------------------ | ------------------------------------------------------- |
| Tier 1   | 10 / 10GiB / 30GiB                   | Email verified                                          |
| Tier 2   | 100 / 200GiB / 300GiB                | Credit card linked, $25 top-up                          |
| Tier 3   | 250 / 500GiB / 2000GiB               | $500 top-up                                             |
| Tier 4   | 500 / 1000GiB / 5000GiB              | $2000 top-up every 30 days                              |
| Custom   | Custom                               | Contact [support@daytona.io](mailto:support@daytona.io) |

:::note[Tier-based network restrictions]
[Network limits](/docs/en/network-limits) are automatically applied to sandboxes based on your organization's billing tier. This provides secure and controlled internet access for development environments.
:::

## Limits

Limits provide an overview of tiers and their corresponding resource and rate limits.

| **Tier**       | **Compute (vCPU)** | **Memory (GiB)** | **Storage (GiB)** | **API Requests (minutes)** | **Sandbox Creation (minutes)** | **Sandbox Lifecycle (minutes)** |
| -------------- | ------------------ | ---------------- | ----------------- | -------------------------- | ------------------------------ | ------------------------------- |
| **1**          | 10                 | 20               | 30                | 10,000                     | 300                            | 10,000                          |
| **2**          | 100                | 200              | 300               | 20,000                     | 400                            | 20,000                          |
| **3**          | 250                | 500              | 2,000             | 40,000                     | 500                            | 40,000                          |
| **4**          | 500                | 1,000            | 5,000             | 50,000                     | 600                            | 50,000                          |
| **Enterprise** | Custom             | Custom           | Custom            | Custom                     | Custom                         | Custom                          |

## Best practices

To work effectively within rate limits, always handle `429` errors gracefully with proper retry logic. When you receive a rate limit error, implement exponential backoff—wait progressively longer between retries (1s, 2s, 4s, 8s, etc.) to avoid overwhelming the API.

The following snippet demonstrates how to create a sandbox with retry logic using the TypeScript SDK:

```typescript
async function createSandboxWithRetry() {
  let retries = 0
  const maxRetries = 5

  while (retries < maxRetries) {
    try {
      return await daytona.create({ snapshot: 'my-snapshot' })
    } catch (error) {
      if (error instanceof DaytonaRateLimitError && retries < maxRetries - 1) {
        // Use Retry-After header if available, otherwise exponential backoff
        const retryAfter = error.headers?.get('retry-after-sandbox-create')
        const delay = retryAfter
          ? parseInt(retryAfter) * 1000
          : Math.pow(2, retries) * 1000
        await new Promise(resolve => setTimeout(resolve, delay))
        retries++
      } else {
        throw error
      }
    }
  }
}
```

**Monitor [rate limit headers](#rate-limit-headers)** (e.g., `X-RateLimit-Remaining-{throttler}`, `X-RateLimit-Reset-{throttler}`) to track your consumption and implement proactive throttling before hitting limits. These headers are available on all error objects via the `headers` property.

**Cache API responses** that don't frequently change, such as [sandbox lists](/docs/sandboxes#list-sandboxes) (when relatively static), [available regions](/docs/regions), and [snapshot information](/docs/snapshots). This reduces unnecessary API calls and helps you stay well within your limits.

**Batch and optimize operations** by creating multiple sandboxes in parallel (within rate limits) rather than sequentially. Consider reusing existing sandboxes when possible instead of creating new ones for every task.

**Efficiently manage sandbox lifecycle** to reduce API calls. [Archive sandboxes](/docs/sandboxes#archive-sandboxes) instead of deleting and recreating them, stop sandboxes when not in use rather than deleting them, and leverage [auto-stop intervals](/docs/sandboxes#auto-stop-interval) to automatically manage running sandboxes without manual intervention.

**Implement request queuing** to prevent bursts that exceed limits, and use [webhooks](/docs/webhooks) instead of polling for state changes to avoid unnecessary API calls. Set up monitoring and alerts for `429` errors in your application logs so you can proactively address rate limiting issues before they impact your users.
