Authentication

Daytona uses two kinds of credentials: project API keys (rlp_...) that authenticate you to the platform API, and per-sandbox access tokens (rlpv_...) that grant direct access to a single sandbox's toolbox. Day to day you will mostly work with API keys; the SDKs manage per-sandbox tokens for you.

API keys

An API key is a bearer credential scoped to a single project. Every REST call to https://api.rl.trydaytona.com — creating sandboxes, managing volumes, listing images — is authenticated with one. Keys are prefixed rlp_ and the full value is shown exactly once when the key is created, so copy it immediately.

You mint keys in the dashboard at https://app.rl.trydaytona.com under Project → API Keys, or programmatically via the management API.

On raw HTTP requests, pass the key in the Authorization header:

curl https://api.rl.trydaytona.com/vms \
  -H "Authorization: Bearer rlp_..."

The SDKs accept the key directly, or fall back to the environment variables RLP_API_KEY (preferred) or DAYTONA_API_KEY. The API URL likewise falls back to RLP_API_URL / DAYTONA_API_URL.

from rlp import Daytona, DaytonaConfig
 
# Explicit configuration
daytona = Daytona(DaytonaConfig(
    api_url="https://api.rl.trydaytona.com",
    api_key="rlp_...",
))
 
# Or rely on RLP_API_URL / RLP_API_KEY from the environment
daytona = Daytona()

import { Daytona } from '@rlp/sdk'
 
// Explicit configuration
const daytona = new Daytona({
  apiUrl: 'https://api.rl.trydaytona.com',
  apiKey: 'rlp_...',
})
 
// Or rely on RLP_API_URL / RLP_API_KEY from the environment
const implicit = new Daytona()

Scopes: organizations → projects → keys

Daytona organizes everything into a simple hierarchy: an organization contains projects, and each project owns its own resources — sandboxes, volumes, secrets, object stores, container registries, and images. An API key belongs to exactly one project, and a request made with that key can only see and modify that project's resources. There is no cross-project access via API keys; use separate keys per project.

Management operations — creating organizations and projects, inviting members, and minting API keys — are performed through your dashboard login (OIDC), not with API keys. This keeps a leaked runtime key from being able to escalate into account administration. See Organizations for details.

Per-sandbox access tokens

When you create a sandbox, the response includes an access_token prefixed rlpv_.... This is a credential scoped to that single sandbox, intended for calling its toolbox (exec, files, git, sessions) directly — for example, from a process that should be able to drive one sandbox but must not hold a project-wide key.

Like API keys, the token is returned only once, in the create response. If you plan to call the toolbox directly, store it at create time. If you use the SDKs, there is nothing to do: they capture the token from the create response and use it automatically.

Key hygiene

API keys are long-lived bearer credentials, so treat them like passwords. A few practical rules:

• Rotate by replacement. Create a new key, deploy it, then delete the old one from the dashboard. Deleting a key immediately revokes it.
• Never embed keys in client-side code — browsers, mobile apps, or anything you ship to users. Keys belong on servers and in CI secrets stores.
• Use environment variables (RLP_API_KEY) rather than hardcoding keys in source, so keys never land in version control.
• Scope by project. Since keys are project-scoped, isolating environments (dev/staging/prod) into separate projects also isolates the blast radius of a leaked key.
• Prefer per-sandbox tokens (rlpv_...) when a component only needs to talk to one sandbox's toolbox.