Limits

Daytona Limits ↗ provide an overview of your organization's 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.

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

Sandboxes count against these limits based on their lifecycle state: stopped, paused, archived, and deleted sandboxes free reserved CPU and memory, while disk quota depends on the sandbox type and state.

Disk quota

Disk quota and sandbox billing are separate: a sandbox can be billed for reserved disk without counting against your organization's storage limit. The table below details which states occupy disk quota for container sandboxes and VM sandboxes.

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.

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

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 and wait progressively longer between retries (1s, 2s, 4s, 8s, etc.) to avoid overwhelming the API.

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.