Skip to content

Linux Sandboxes

View as Markdown

Daytona provides Linux sandboxes as the default sandbox for AI agents. A Linux sandbox is an isolated runtime environment you manage programmatically to run code. Each sandbox has a dedicated filesystem, network stack, and allocated vCPU, RAM, and disk. Agents and developers can install packages, run servers, compile code, and manage processes.

Linux sandboxes run as containers or as Linux virtual machines (VMs). The snapshot sets the sandbox class, and both classes use the same SDKs, CLI, and API. Linux sandboxes start from a snapshot or a Docker image, keep their filesystem across stop and start, and are deleted when a timeout elapses or on request.

TermDescription
SandboxAn isolated Linux environment created on demand to run code.
ContainerA sandbox that runs as a Linux container and shares the kernel of the host. The default sandbox class.
Linux VMA sandbox that runs as a virtual machine with its own Linux kernel. The hardware enforces the boundary between sandboxes.
Sandbox classThe runtime of a Linux sandbox: container or Linux VM. The snapshot sets the class.
ImageA packaged filesystem that defines the software a sandbox starts with. Container sandboxes can start from a Docker image.
SnapshotA pre-configured template that new sandboxes start from.
ToolboxThe Daytona daemon inside the sandbox that serves file, Git, and process requests.

Linux sandboxes are used wherever code must run in a real environment, but you cannot trust the code or you cannot afford for it to affect anything else.

  • Code execution for AI agents: an agent writes code, runs it in a sandbox, reads the output, and decides what to do next. The sandbox gives the agent a real shell and filesystem while keeping its actions away from your infrastructure.
  • Coding agents: an agent clones a repository, installs dependencies, edits files, runs the test suite, and pushes a branch, all inside one sandbox.
  • Reinforcement learning (RL) and evaluation: each episode or test case gets a clean, identical machine created from a shared snapshot, so results do not depend on leftover state and each environment stays cheap.
  • Untrusted user code: online coding platforms, grading systems, code interpreters, and plugin hosts run code submitted by users or generated by a model without exposing other users or the service.
  • Computer-use agents: an agent operates a graphical desktop, a browser, or desktop applications through screenshots and input events.
  • Development environments: a developer gets a preconfigured machine from an image, connects over SSH or from an editor, and previews web applications through a URL.
  • Long-lived and branching agent sessions: a Linux VM sandbox pauses when the agent goes idle and resumes with its processes and memory intact, and is forked to try several approaches from the same point.

Create a sandbox.

  1. Go to Daytona Sandboxes ↗
  2. Click Create Sandbox
  3. Click Create
from daytona import Daytona
daytona = Daytona()
sandbox = daytona.create()

Create a Linux VM sandbox.

Create a Linux VM sandbox.

  1. Go to Daytona Snapshots ↗
  2. Click Create Snapshot
  3. Enter the Snapshot Name, for example my-vm-snapshot
  4. Enter the Image, for example ubuntu:22.04
  5. Select Sandbox Class: LINUX_VM
  6. Click Create
  7. Go to Daytona Sandboxes ↗
  8. Click Create Sandbox
  9. Select the VM Snapshot, for example my-vm-snapshot
  10. Click Create
from daytona import (
Daytona,
CreateSnapshotParams,
CreateSandboxFromSnapshotParams,
SandboxClass,
)
daytona = Daytona()
# Create a Linux VM snapshot
daytona.snapshot.create(
CreateSnapshotParams(
name="my-vm-snapshot",
image="ubuntu:22.04",
sandbox_class=SandboxClass.LINUX_VM,
)
)
# Create a Linux VM sandbox from the snapshot
sandbox = daytona.create(CreateSandboxFromSnapshotParams(snapshot="my-vm-snapshot"))

Daytona provides nested virtualization for Linux VM sandboxes. Nested virtualization exposes KVM (/dev/kvm) inside the guest, so the sandbox can run its own virtual machines with hardware acceleration.

from daytona import Daytona, CreateSandboxFromSnapshotParams
daytona = Daytona()
sandbox = daytona.create(
CreateSandboxFromSnapshotParams(
snapshot="daytona-vm-small",
kvm=True,
)
)

Filesystem persistence keeps the contents of a sandbox’s disk: files, installed packages, cloned repositories, and build artifacts. A sandbox with a preserved filesystem starts with its environment intact, with nothing to reinstall or rebuild.

Linux sandboxes preserve their filesystem across stop and start, archive, and filesystem snapshots created from a sandbox. An ephemeral sandbox is deleted on stop, so its filesystem is not kept. The sandbox classes differ in where the preserved filesystem is stored while the sandbox is stopped:

Sandbox classFilesystem persistence
ContainerFilesystem is preserved through stop and start: it stays on the runner and counts against disk quota while stopped. Archive moves it to object storage and frees the quota, and starting an archived sandbox restores it. Use filesystem snapshots to capture the filesystem.
Linux VMFilesystem is preserved through stop and start: stopping offloads it to nearby storage and releases disk quota, starting restores it. Archive is not needed. Use filesystem snapshots to capture the filesystem.
from daytona import Daytona
daytona = Daytona()
sandbox = daytona.create()
# Write a file to the filesystem
sandbox.fs.upload_file(b"done", "setup.log")
# Stop clears memory and keeps the filesystem
sandbox.stop()
# Start boots the sandbox from its filesystem
sandbox.start()
content = sandbox.fs.download_file("setup.log")
print(content.decode()) # done

Memory persistence keeps the runtime state of a sandbox: running processes, open connections, and everything loaded in RAM. A sandbox with preserved memory continues from the point it was frozen, with processes still running, instead of starting from a clean boot.

Linux VM sandboxes preserve their memory across pause and resume, memory snapshots created from a sandbox, and forks. Memory state is cleared on every stop. The sandbox classes differ in whether memory can be preserved without keeping the sandbox running:

Sandbox classMemory persistence
ContainerMemory persists only while the sandbox is running. Set the auto-stop interval to zero to run indefinitely, or relaunch processes after each start. Pause is not supported.
Linux VMMemory is preserved through pause and resume: pausing freezes the VM with memory intact, resuming continues all processes from the point they were frozen. Use memory snapshots or forks to capture memory.

The following example creates a Linux VM sandbox. Pause requires a non-ephemeral Linux VM sandbox in the Started state.

from daytona import Daytona, CreateSandboxFromSnapshotParams, SessionExecuteRequest
daytona = Daytona()
sandbox = daytona.create(CreateSandboxFromSnapshotParams(snapshot="daytona-vm-small"))
# Start a process that runs in the background
sandbox.process.create_session("keepalive")
response = sandbox.process.execute_session_command(
"keepalive",
SessionExecuteRequest(command="sleep 3600", run_async=True),
)
# Pause keeps the filesystem and memory
sandbox.pause()
# Start resumes every process from the point where the sandbox paused
sandbox.start()
command = sandbox.process.get_session_command("keepalive", response.cmd_id)
print(command.exit_code) # None: the process is still running

A memory snapshot, also called a hot snapshot, saves the filesystem and memory of a started Linux VM sandbox. A sandbox created from a memory snapshot starts with its processes already running. Enable the include memory option when you create the snapshot. Container sandboxes do not support memory snapshots.

A memory snapshot requires a Linux VM sandbox in the Started state. The SDKs do not expose the include memory option, so use the API.

Terminal window
curl 'https://app.daytona.io/api/sandbox/{sandboxIdOrName}/snapshot' \
--request POST \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer YOUR_API_KEY' \
--data '{
"name": "my-vm-snapshot",
"includeMemory": true
}'

A filesystem snapshot, also called a cold snapshot, saves the filesystem of a stopped Linux sandbox. Both sandbox classes support filesystem snapshots. A snapshot without the include memory option is a filesystem snapshot.

A filesystem snapshot requires a sandbox in the Stopped state. An ephemeral sandbox is deleted on stop, so it cannot take a filesystem snapshot.

from daytona import Daytona, CreateSandboxFromSnapshotParams
daytona = Daytona()
sandbox = daytona.create()
# Write a file to the filesystem
sandbox.fs.upload_file(b"done", "setup.log")
# A filesystem snapshot requires a stopped sandbox
sandbox.stop()
sandbox.create_snapshot("my-snapshot")
# A sandbox created from the snapshot starts with the same filesystem
new_sandbox = daytona.create(CreateSandboxFromSnapshotParams(snapshot="my-snapshot"))
content = new_sandbox.fs.download_file("setup.log")
print(content.decode()) # done

Every Linux sandbox moves through a lifecycle. A Linux sandbox can have several different states. Each state reflects the status of your sandbox. A Linux sandbox transitions between states in response to user actions, or automatically when one of its timeouts elapses.

FeatureContainerContainer (ephemeral)Linux VMLinux VM (ephemeral)
Stop and start✓✗✓✗
Pause and resume✗✗✓✗
Fork✗✗✓✓
Archive✓✗✗✗
Delete✓✓✓✓
Filesystem persistence✓✗✓✗
Memory persistence✗✗✓✗
Memory snapshot✗✗✓✓
Filesystem snapshot✓✗✓✗
Nested virtualization✗✗✓✓
Desktop✓ VNC✓ VNC✓ VNC✓ VNC
Sandbox states
StateDescription
Pending BuildThe build is queued.
Building SnapshotThe sandbox is building a snapshot from an image. Container sandboxes only.
Pulling SnapshotThe sandbox is pulling a snapshot.
CreatingThe sandbox is being created.
StartingThe sandbox is starting.
StartedThe sandbox is running and accepts requests.
StoppingThe sandbox is stopping and does not accept new requests.
StoppedThe sandbox is stopped. The filesystem is kept and memory is cleared.
PausingThe Linux VM sandbox is pausing.
PausedThe Linux VM sandbox is paused with its filesystem and memory preserved.
ResumingThe Linux VM sandbox is resuming from the paused state.
ArchivingThe container sandbox filesystem is moving to object storage.
ArchivedThe container sandbox filesystem is in object storage.
RestoringThe sandbox is being restored.
ResizingThe sandbox resources are being changed.
SnapshottingThe sandbox is creating a memory snapshot or a filesystem snapshot.
ForkingThe Linux VM sandbox is being forked.
DeletingThe sandbox is being deleted.
DeletedThe sandbox is deleted.
ErrorThe sandbox hit an error. A recoverable error can be recovered.
State transitions
Initial stateTarget stateTrigger
StartedStoppingA stop is requested, or the auto-stop interval elapses.
StoppingStoppedThe shutdown completes. The filesystem is kept and memory is cleared.
StoppedStartingA start is requested.
StartedPausingA pause is requested on a Linux VM sandbox, or the auto-pause interval elapses.
PausingPausedThe filesystem and memory are preserved.
PausedResumingA start is requested on a paused Linux VM sandbox.
PausedStoppingA stop is requested on a paused Linux VM sandbox.
ResumingStartedThe sandbox resumes from memory and is running.
StoppedArchivingAn archive is requested on a container sandbox, or the auto-archive interval elapses.
ArchivedRestoringA start is requested on an archived container sandbox.
StartedSnapshottingA memory snapshot is requested on a Linux VM sandbox.
StoppedSnapshottingA filesystem snapshot is requested.
StartedForkingA fork is requested on a Linux VM sandbox.
StartedDeletingA delete is requested, or an ephemeral sandbox is stopped.
StoppedDeletingA delete is requested, or the auto-delete interval elapses.
DeletingDeletedThe sandbox is removed and its resources are released.

Wait until a sandbox reaches the started or stopped state. Each method takes a timeout in seconds.

sandbox.wait_for_sandbox_start(timeout=60)
sandbox.wait_for_sandbox_stop(timeout=60)

Stop a sandbox. The sandbox moves to the stopped state when shutdown completes. While a stop is in progress, the sandbox is in the stopping state and does not accept new requests.

Stopping terminates the running container. The filesystem is preserved, but memory state is not. Container sandboxes do not support pause; stop is the way to shut down a container sandbox when it is not in use.

  1. Go to Daytona Sandboxes ↗
  2. Click the stop icon (⏹) next to the sandbox you want to stop
sandbox.stop()

Start a sandbox.

  1. Go to Daytona Sandboxes ↗
  2. Click the start icon ▶ next to the sandbox you want to start
sandbox.start()

Pause and resume a sandbox.

Pause is not supported for container sandboxes. The filesystem can be preserved on stop, but memory state is not. Use stop to shut down a container sandbox when it is not in use.

Fork a sandbox.

Forking is not supported for container sandboxes. Use create snapshot from sandbox to capture filesystem state, then create a new sandbox from that snapshot.

Delete a sandbox.

  1. Go to Daytona Sandboxes ↗
  2. Click Delete next to the sandbox you want to delete
sandbox.delete()
# Block until the sandbox is deleted
sandbox.delete(timeout=60, wait=True)

Daytona stops, pauses, archives, or deletes a sandbox when a timeout elapses. Each timeout is set in minutes. Zero disables auto-stop, auto-pause, and wall-clock TTL. Zero does not disable auto-archive or auto-delete: auto-archive set to zero uses the maximum interval of 30 days, and auto-delete set to zero deletes the sandbox as soon as it stops. To disable auto-delete, set it to -1.

IntervalContainerLinux VMAction
Auto-stop✓ (default 15 minutes)✓Stops the sandbox after inactivity.
Auto-pause✗✓ (default 60 minutes)Pauses the sandbox after inactivity.
Auto-archive✓✗Archives a stopped sandbox.
Auto-delete✓✓Deletes a stopped sandbox.
Wall-clock TTL✓✓Deletes the sandbox at a fixed deadline, in any state.

The auto-pause interval sets the amount of time after which an idle VM sandbox is automatically paused. Auto-pause applies only to VM sandboxes and is mutually exclusive with the auto-stop interval: at most one of the two intervals may be non-zero. Ephemeral sandboxes cannot have auto-pause enabled.

The interval is set in minutes:

  • 0: disables the auto-pause functionality
  • if neither auto-pause nor auto-stop is set, non-ephemeral sandbox classes that support pausing default to an auto-pause interval of 60 minutes with auto-stop disabled

The sandbox pauses after no new events occur for the specified interval. Events include sandbox state changes and interactions with the sandbox through the SDK. Interactions through sandbox previews do not reset the timer.

Auto-pause is not supported for container sandboxes. Use auto-stop to stop a container sandbox after a period of inactivity.

The wall-clock TTL (time-to-live) sets a hard upper bound on how long a sandbox may exist. Unlike the auto-delete interval, which counts time only while the sandbox is stopped, TTL runs as wall-clock time from creation (or from the moment you last set it) and destroys the sandbox in any state: started, stopped, paused, or archived.

Set ttl_minutes when creating a sandbox, or update it later. The value is in minutes:

  • 0: disables the TTL
  • if not set, the sandbox has no TTL deadline

Calling set_ttl after creation resets the deadline from the current moment. Use wall-clock TTL for agent sessions, CI jobs, and any sandbox that must not outlive a fixed deadline.

sandbox = daytona.create(CreateSandboxFromSnapshotParams(
snapshot="daytona-vm-small",
ttl_minutes=120,
))
# Reset the deadline to 60 minutes from now
sandbox.set_ttl(60)