DOCSEARCHbyAlgolia
Submit Docs

Daytona Documentation

website·Indexed 39 days ago

https://daytona.io/docs

Secure and elastic infrastructure for running AI-generated code. Daytona provides composable computers via sandboxes with features for runtime and network isolation, filesystem persistence, and scaling. The platform includes a Declarative Builder for dependencies, support for snapshots, warm pools, and FUSE-based volume mounts for S3-compatible storage, GCS, Azure Blob, and Box. It offers APIs for file system operations, Git management, and Language Server Protocol (LSP) support.

Tokens
313.6K
Snippets
1.9K
Records
2.2K
Agent score
71%

What's inside Daytona

  1. Overview of Scaling Tool Execution in veRL with Daytona

    veRL is a distributed RL post-training framework for LLMs. The ReTool recipe trains models to solve math problems by executing Python code in isolated sandboxes. The agent loop follows a lifecycle of create() (sandbox creation per trajectory), execute() (running code), and release() (deleting the sandbox). Using Daytona sandboxes as the tool execution backend allows the async rollout pipeline to scale to hundreds of concurrent executions, avoiding the throughput plateaus common with standard Docker containers.

  2. Overview of ProcessService for sandbox execution

    The ProcessService provides process execution operations for a Daytona sandbox, including command execution, session management, and PTY (pseudo-terminal) operations. It supports both synchronous command execution and interactive terminal sessions. Developers should access this service via Sandbox.Process rather than instantiating it directly.
    // Execute a command
result, err := sandbox.Process.ExecuteCommand(ctx, "echo 'Hello, World!'")
fmt.Println(result.Result)

// Execute with options
result, err := sandbox.Process.ExecuteCommand(ctx, "ls -la",
    options.WithCwd("/home/user/project"),
    options.WithExecuteTimeout(30*time.Second),
)

// Create an interactive PTY session
handle, err := sandbox.Process.CreatePty(ctx, "my-terminal")
defer handle.Disconnect()

  3. Overview of OpenEnv and Daytona Integration

    OpenEnv is a framework for building RL environments that decouples the environment from the training loop by running each instance in its own container. It uses a Gymnasium-style API (reset, step, state) over WebSockets. The DaytonaProvider allows OpenEnv to launch environment instances as Daytona sandboxes, enabling massive parallel execution and API-driven lifecycle management without requiring local infrastructure.

  4. Overview of Daytona Preview URLs

    Daytona provides preview URLs to access services running in sandboxes on any port from 1 to 65535. If a sandbox's public property is set to true, preview links are accessible without authentication. Otherwise, authentication is required via one of two mechanisms: Standard Preview URLs or Signed Preview URLs. These two token types are not interchangeable.

  5. Overview of Box Mount for Daytona Sandboxes

    Box Mount is an official Box client for agent runtimes that maps a Box folder to a local directory with continuous two-way sync. Writes in the sandbox upload to Box, and changes in Box appear in the sandbox. Operations use the authenticated identity, ensuring Box permissions, retention, and audit trails are applied.

    Key Limitations (Private Preview):

    • Workloads are limited to 5 GB and 10,000 files per mount.
    • Applications that save files by replacing them (write-temp-then-rename) create new files instead of new versions.

  6. Overview of the Two-Agent Coding System Architecture

    The system implements a delegation-based architecture to separate high-level planning from low-level execution. It consists of two agents:

    1. Project Manager Agent (Local): Runs on the user's local machine using the claude-sonnet-4-20250514 model. It handles high-level planning, task delegation, and reviews results.
    2. Developer Agent (In-Sandbox): Runs inside a Daytona sandbox using the Claude Agent SDK and Claude Code. It executes the actual coding tasks and automation in a secure environment.

    Workflow: The Project Manager receives a user prompt, plans the workflow, and sends specific tasks to the Developer Agent. The Developer Agent executes these in the sandbox and streams results back. If a web app is created, the Developer Agent provides a Daytona Preview Link, which the Project Manager then presents to the user.

  7. Overview of Cursor Self-Hosted Machines on Daytona

    Cursor Self-Hosted Machines move the execution of Cloud Agent tools to machines managed by the user via Daytona. While Cursor continues to host the agent control plane and user experience, the user controls the operating system, dependencies, and network access of the workers. This is implemented through a Self-Hosted Pool where each request triggers the creation of a Daytona sandbox from a pre-built snapshot.

  8. Overview of Daytona Webhooks

    Webhooks in Daytona are HTTP callbacks sent to specified endpoints when specific infrastructure events occur. They allow for real-time notifications, automated workflows (such as triggering deployment pipelines), monitoring, and audit logging. Webhooks are available to all organization members; if the Webhooks option is missing from the Daytona Dashboard, contact support@daytona.io to enable it.

  9. Overview of Daytona Sandboxes

    Daytona provides 'sandboxes' which are full composable computers offering complete isolation with a dedicated kernel, filesystem, network stack, and allocated vCPU, RAM, and disk. They are designed for AI, agent, and reinforcement learning workflows, supporting Python, TypeScript, and JavaScript. Sandboxes spin up in under 90ms and are OCI/Docker compatible.

  10. Overview of the AG2 and Daytona Bug Fixer Workflow

    The bug-fixing system uses a multi-agent architecture to iteratively fix broken code. A bug_fixer agent (LLM) analyzes broken code and proposes a fix in a fenced code block. A code_executor agent extracts this code and runs it within a secure Daytona sandbox. If the execution fails, the error output is fed back to the bug_fixer for another attempt. The process continues until the code passes or the maximum number of turns is reached, at which point the sandbox is automatically deleted.

  11. Overview of the Declarative Builder

    The Declarative Builder provides a code-first approach to defining dependencies for Daytona sandboxes using the Daytona SDK. It supports two primary workflows: building declarative images on demand when creating sandboxes, and creating pre-built snapshots for reuse.

    Constraints:

    • Declarative image and Dockerfile builds are supported for container and GPU sandboxes only.
    • VM snapshots (Linux VM and Windows) cannot be built from a Dockerfile. For custom Linux VM images, use a public/private registry or create a snapshot from an existing sandbox.
    • Declarative images are cached for 24 hours and reused when running the same script on the same runner.

  12. Overview of Devin Outposts on Daytona

    Devin Outposts allows you to move the execution environment (the 'session machine') of a Devin AI session from Cognition's infrastructure to your own Daytona sandboxes. While the agent loop (planning and model calls) remains hosted by Cognition, all shell commands, checked-out repositories, and browser automation run within a Daytona sandbox. Each session is assigned its own sandbox created from a defined snapshot, which is stopped when the session sleeps and deleted when the session terminates.