Persistent Sandboxes

By default a sandbox is ephemeral: its writable filesystem lives on host-local storage and disappears when the sandbox is deleted — there is no way to "turn it off and come back later". Setting persistent: true at create time changes that. The sandbox's write layer is placed on durable network-backed storage, which decouples the sandbox's data from any particular host and unlocks a much richer lifecycle.

Durability is one of three independent create-time axes — alongside resource mode and pricing tier — that you mix per sandbox. See Choosing sandbox options for how they combine.

What persistent: true gives you

Because the filesystem survives independently of the compute, a persistent sandbox supports operations an ephemeral one cannot:

• Warm stop / start — stop() releases the compute (you stop paying for CPU and memory) while keeping the filesystem intact; start() boots it again later, possibly on entirely different hardware. Processes do not survive a stop — the sandbox reboots with its disk as it was.
• Pause / resume — pause() additionally preserves memory and running processes; resume() continues them exactly where they left off.
• Fork — duplicate the sandbox (RAM and filesystem) into a new, independent sandbox.

Persistence is a create-time property of the sandbox itself. It is different from volumes, which are named storage attached into sandboxes and shared across them — a persistent sandbox makes the whole machine durable.

Tradeoffs

Persistence is not free, and it is worth understanding the two costs before enabling it everywhere:

• Slightly slower creation. Persistent sandboxes cold-boot (v1), so they don't get the fastest cached-image create path. For short-lived, disposable work, ephemeral sandboxes remain the faster and cheaper choice.
• Storage is billed while stopped. A stopped persistent sandbox costs nothing in compute, but its durable storage is billed for as long as the sandbox exists. Delete sandboxes you no longer need; a stopped sandbox is never auto-pruned, so it will sit (and bill for storage) until you delete it.

Failure semantics

Persistence also changes what a hardware failure means. If the host running a persistent sandbox fails, the sandbox transitions to stopped — its filesystem is safe on network storage, and a subsequent start() brings it back on healthy hardware. A persistent sandbox is never lost to host failure and is never auto-deleted while stopped. (An ephemeral sandbox on a failed host is simply gone, which is the flip side of its speed.)

Example

Create a persistent sandbox, do some work, stop it to release compute, and start it again later:

from rlp import Daytona, CreateSandboxFromImageParams
 
daytona = Daytona()
sandbox = daytona.create(CreateSandboxFromImageParams(
    image="python:3.12-slim",
    persistent=True,
))
 
sandbox.process.exec("pip install requests && echo done > /root/setup.log")
 
sandbox.stop()    # compute released; filesystem kept; storage still billed
sandbox.start()   # boots again — /root/setup.log is still there
 
print(sandbox.process.exec("cat /root/setup.log").result)  # "done"

import { Daytona } from '@rlp/sdk'
 
const daytona = new Daytona()
const sandbox = await daytona.create({
  image: 'python:3.12-slim',
  persistent: true,
})
 
await sandbox.process.executeCommand('pip install requests && echo done > /root/setup.log')
 
await sandbox.stop()   // compute released; filesystem kept
await sandbox.start()  // boots again — the file survives
 
const r = await sandbox.process.executeCommand('cat /root/setup.log')
console.log(r.result)  // "done"

curl -X POST https://api.rl.trydaytona.com/vms \
  -H "Authorization: Bearer $RLP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"image": "python:3.12-slim", "persistent": true}'

Combining with other features

Persistence composes with most other create options, with a few interactions to know about:

• Volumes and Docker devices work with warm stop/start. However, a sandbox with attached volumes or a Docker data device cannot pause or fork (v1) — see Pause & resume and Docker in sandboxes.
• Persistent + spot is a deliberate combination: if the platform reclaims a persistent spot sandbox, it is paused rather than deleted, and you can resume it when convenient. See Spot sandboxes.
• The Docker data device is always ephemeral, even in a persistent sandbox — it is recreated fresh on every boot.