Daytona SDK Compatibility

If you already have code written against the official Daytona SDKs, it can run against this platform without modification. A compatibility facade speaks the Daytona wire protocol (v0.190.x) for sandbox and snapshot management, and the agent running inside every sandbox is the real Daytona daemon — so toolbox operations (exec, files, git, sessions) are byte-compatible, not emulated.

This page describes what the facade supports, where its semantics differ, and when you should reach for the native SDK (rlp-sdk for Python, @rlp/sdk for TypeScript) instead.

Drop-in setup

Point the official Daytona SDK at the compatibility endpoint and authenticate with a project API key:

export DAYTONA_API_URL=https://api.rl.trydaytona.com/daytona
export DAYTONA_API_KEY=rlp_...

With those two environment variables set, existing Daytona code works as-is:

from daytona import Daytona, CreateSandboxFromSnapshotParams
 
daytona = Daytona()  # reads DAYTONA_API_URL / DAYTONA_API_KEY
 
sandbox = daytona.create(CreateSandboxFromSnapshotParams(snapshot="python:3.12-slim"))
result = sandbox.process.exec("echo hello from daytona")
print(result.result)
sandbox.delete()

import { Daytona } from '@daytonaio/sdk'
 
const daytona = new Daytona() // reads DAYTONA_API_URL / DAYTONA_API_KEY
 
const sandbox = await daytona.create({ snapshot: 'python:3.12-slim' })
const result = await sandbox.process.executeCommand('echo hello from daytona')
console.log(result.result)
await sandbox.delete()

Supported surface

• Sandboxes — create, list (with pagination and id/name filters), get, delete, start, stop, and the toolbox proxy URL. All toolbox calls (exec, file operations, git, sessions) go straight to the genuine Daytona daemon in the sandbox.
• Port preview URLs — GET /sandbox/:id/ports/:port/preview-url returns a preview URL plus token. Requesting it registers the port as a private preview endpoint (callers must present the token via x-daytona-preview-token); ports are never silently made public.
• Snapshots (Daytona dialect: image aliases) — create (from a registry reference or an inline Dockerfile), list, get, delete, activate, and build logs (build-logs / build-logs-url).

Facade semantics

Sandbox create accepts the standard Daytona fields, with the following behavior:

Two semantic constants to be aware of:

• Facade-created sandboxes are always dedicated (fixed-size) and always full price — burstable mode and the spot tier exist only in the native API.
• Facade-created sandboxes are not persistent, so start on a stopped one and warm stop return a 501 explaining the limitation; warm stop/start works only for sandboxes created persistent via the native API. Deleting and recreating is the ephemeral equivalent.

Not supported (returns 501 with a named error)

Endpoints outside the surface above return 501 Not Implemented with a Daytona-shaped error naming the operation, so failures are explicit rather than silent:

Any other Daytona route not listed on this page also answers 501.

When to use the native SDK instead

The facade covers the common create/exec/delete loop. The native SDK unlocks everything the platform adds beyond Daytona's model:

• Burstable vs dedicated resource modes and fractional CPU guarantees
• Persistent sandboxes with warm stop/start, and spot pricing
• Port exposure and Docker-in-sandbox
• Volumes, object stores, and secrets
• VM-state snapshots (disk and full-memory) and fork

Both APIs manage the same sandboxes under the hood, authenticated by the same rlp_ project keys — you can start with Daytona-compatible code and adopt native features incrementally.