Limits

Daytona Limits ↗ provide an overview of your organization’s current usage, resources, sandbox limits, and rate limits. Daytona uses a tier-based 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.

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.

Daytona supports managing your sandbox resources by changing the sandbox state. The table below summarizes how each state affects sandbox resource usage:

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):

Rate limit errors

Daytona Python, TypeScript, Ruby and Go 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

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

All errors include headers and statusCode properties, allowing access to rate limit headers directly from the error object. Headers support case-insensitive access:

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
  }
}

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

begin
  daytona.create
rescue Daytona::Sdk::Error => e
  puts "Error: #{e.message}"
end

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
  }
}

For more information, see the Python SDK and TypeScript SDK references.

DaytonaRateLimitError (Python SDK)

DaytonaRateLimitError (TypeScript SDK)

Daytona::Sdk::Error (Ruby SDK)

DaytonaRateLimitError (Go SDK)

Tiers

Limits are applied to your organization’s default region. To unlock higher limits, complete the following verification steps in the Daytona Dashboard ↗:

Limits

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

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:

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 (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 (when relatively static), available regions, and snapshot information. 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 instead of deleting and recreating them, stop sandboxes when not in use rather than deleting them, and leverage auto-stop intervals to automatically manage running sandboxes without manual intervention.

Implement request queuing to prevent bursts that exceed limits, and use 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.