Introduction

What is Daytona?

Daytona is a cloud platform for running code in hardware-isolated sandboxes. Each sandbox is a Firecracker microVM with its own kernel, filesystem, and network — not a container sharing a host kernel. You create sandboxes from any OCI image, a Dockerfile, or a snapshot, and for images the platform has already cached, a sandbox is typically running in about 100 milliseconds.

Sandboxes are designed to be treated as cheap, disposable compute: create one to run a single command and delete it milliseconds later, or keep one alive for days as a long-running development environment. The same API scales from a single sandbox to very large fleets, which makes Daytona a natural fit for AI agents, untrusted code execution, evaluation pipelines, and reinforcement-learning workloads that need thousands of isolated environments.

Every sandbox exposes a toolbox API — command execution, file transfer, git operations, long-running sessions, and SSH — that works on any image with zero changes. You do not need to bake an agent, SSH server, or SDK into your image; bring a stock python:3.12-slim and it just works.

Why sandboxes?

Modern workloads increasingly involve running code you did not write: AI-generated programs, user-submitted scripts, agent tool calls, and third-party plugins. Running that code in a shared process or even a container leaves too much attack surface. Daytona's answer is hardware isolation — each sandbox boots its own kernel inside a Firecracker microVM, so code inside one sandbox cannot observe or affect another sandbox or the host.

Because isolation is enforced by the hypervisor rather than by policy inside a shared kernel, you can safely:

• Execute AI-generated or user-submitted code without reviewing it first.
• Give agents a full Linux machine — shell, filesystem, network, even a Docker daemon — without risking your infrastructure.
• Run many mutually-untrusting tenants on the same platform.

Key capabilities

• Quickstart — create your first sandbox and run a command in under five minutes.
• Creating sandboxes — every create parameter: image sources, burstable vs dedicated resources, persistence, spot pricing, Docker-in-sandbox, and environment & secrets.
• Lifecycle — stop and start, pause and resume, fork, and VM snapshots.
• Volumes — persistent, shareable storage mounted into sandboxes.
• Object stores — mount S3-compatible buckets directly into a sandbox's filesystem.
• Secrets — attach credentials that untrusted code inside the sandbox can use but never read.
• SDKs — Python (rlp-sdk, module rlp) and TypeScript (@rlp/sdk).
• API reference — the full REST surface at https://api.rl.trydaytona.com.

How it works

You interact with Daytona through the REST API or an SDK. Creating a sandbox is asynchronous: the API accepts your request, returns a sandbox ID immediately, and boots the microVM in the background. The SDKs poll for you, so a call like daytona.create(...) simply returns a ready sandbox.

from rlp import Daytona, CreateSandboxFromImageParams
 
daytona = Daytona()  # reads RLP_API_KEY / RLP_API_URL from the environment
sandbox = daytona.create(CreateSandboxFromImageParams(image="python:3.12-slim"))
 
result = sandbox.process.exec("python3 -c 'print(21 * 2)'")
print(result.result)  # "42"
 
daytona.delete(sandbox)

import { Daytona } from '@rlp/sdk'
 
const daytona = new Daytona() // reads RLP_API_KEY / RLP_API_URL from the environment
const sandbox = await daytona.create({ image: 'python:3.12-slim' })
 
const result = await sandbox.process.executeCommand("python3 -c 'print(21 * 2)'")
console.log(result.result) // "42"
 
await daytona.delete(sandbox)

The first time your project uses a given image, Daytona pulls it from the registry and converts it into its boot-optimized format. That happens once — every subsequent sandbox from the same image starts from the fleet-wide cache in roughly 100 milliseconds. Once a sandbox is running, toolbox calls (exec, files, git, sessions, SSH) go directly to it.

Note: Cold creates (an image the platform has never seen) take as long as the pull and conversion require. If you need consistently fast creates for a burst of work, warm the image first — see Images.

Next steps

1. Quickstart — get an API key, install an SDK, and run your first command.
2. Authentication — how API keys, projects, and per-sandbox tokens work.
3. Core concepts — Sandboxes, Images, and Snapshots.