Skip to main content
Daytona is a cloud sandbox backend: instead of running Docker containers locally, OpenClaw creates Daytona sandboxes through the Daytona API and executes commands and file operations over the Daytona toolbox API (HTTPS). No SSH keys or inbound connectivity are required. The plugin reuses the same remote filesystem bridge as the generic SSH backend with a remote-canonical workspace model: the sandbox workspace is seeded once at creation and stays canonical until you recreate it.

Prerequisites

  • Daytona plugin installed (openclaw plugins install @openclaw/daytona-sandbox)
  • A Daytona API key (https://app.daytona.io/dashboard/keys)
  • OpenClaw Gateway running on the host

Quick start

Export DAYTONA_API_KEY in the Gateway environment (or store the key with a SecretRef as above, or as a plaintext string). Restart the Gateway. On the next agent turn OpenClaw creates a Daytona sandbox and routes tool execution through it. Verify with:
New sandboxes block all network egress by default, matching the Docker backend’s no-network stance. If your agents need to install packages or reach the network from inside the sandbox, opt in explicitly with networkBlockAll: false, or grant selective egress with networkAllowList or domainAllowList.

How execution works

  • Sandbox per scope: one Daytona sandbox per sandbox scope (agent, session, or shared). Sandboxes are labeled openclaw.sandbox=1 and adopted across Gateway restarts through the OpenClaw sandbox registry.
  • Exec: each exec call runs inside the sandbox through a Daytona session (or a Daytona PTY when the tool requests a TTY). Exit codes, stdout, stderr, stdin, and terminal resizes all flow through the toolbox API.
  • Files: read, write, edit, apply_patch, and media reads go through the sandbox filesystem bridge, so file tools operate on the remote workspace with the same path and writability rules as the SSH backend.
  • Auto-stop: Daytona stops idle sandboxes automatically (default 15 minutes). OpenClaw restarts a stopped sandbox on the next use, so idle sandboxes cost nothing while state stays warm.

Workspace model

The session workspace is uploaded once when the sandbox is created (remote-canonical, like the SSH backend). Host-local edits made after the seed are not visible remotely until you recreate the sandbox:
This deletes the Daytona sandbox; the next agent turn provisions a fresh one and seeds it from the current local workspace.

Configuration reference

All settings live under plugins.entries.daytona.config:

Lifecycle management

Idle pruning (agents.defaults.sandbox.prune) treats Daytona runtimes the same as Docker runtimes: pruned entries delete the Daytona sandbox.

Cost controls

  • autoStopInterval (default 15 minutes) stops idle sandboxes; stopped sandboxes restart automatically on next use. autoPauseInterval pauses instead, on sandbox classes that support pausing.
  • autoArchiveInterval moves long-stopped sandboxes to cold storage; autoDeleteInterval deletes sandboxes that stay stopped, if you prefer Daytona-side cleanup in addition to OpenClaw pruning.
  • OpenClaw prune (sandbox.prune.idleHours / maxAgeDays) deletes registered sandboxes from the OpenClaw side.

Current limitations

  • Browser sandboxing is not supported on this backend.
  • sandbox.docker.* settings (image, binds, network) do not apply; use snapshot/image and the network allow-list options instead. sandbox.docker.binds is rejected; Daytona volumes cover shared storage.
  • Volume mount paths are reachable from exec commands only; the file tools stay inside the managed workspace mounts.
  • The workspace is seeded once (remote-canonical); there is no mirror mode.
  • Exec stdin is line-oriented text (Daytona session input); binary stdin streams are not preserved byte-for-byte in non-PTY execs.