Pause & Resume

Pause captures a sandbox's entire runtime state — guest RAM, device state, and therefore every running process — to durable storage, then shuts the machine down. Resume restores that state so execution continues exactly where it left off: running processes keep running, open file descriptors stay open, in-memory caches and REPL sessions are intact. Unlike stop/start, which is a clean shutdown and reboot, pause/resume is a freeze-frame.

This is the right tool when the expensive thing about your sandbox isn't the disk but the warm state on top of it: a loaded model, a long-running agent mid-task, a dev server with a populated cache. Pause/resume requires a persistent sandbox (persistent: true at create — see Persistent Sandboxes).

How it works

POST /vms/:id/pause moves the sandbox through running → pausing → paused. During the pause, Daytona writes the guest's RAM and device state to durable storage alongside the sandbox's existing write layer. POST /vms/:id/resume restores memory and continues execution; the SDK resume() waits until the sandbox is running again.

Timing and cost characteristics worth knowing:

• Pause time scales with RAM. A sandbox with more allocated memory takes proportionally longer to pause, since its RAM is what's being captured.
• Resume takes seconds, also dependent on RAM size.
• A paused sandbox bills like a stopped one — storage only, no compute.

Restrictions in v1

Pause is refused with 409 Conflict (surfaced by the SDKs as a not-supported error) when the sandbox:

• is not persistent,
• has one or more attached volumes, or
• has a Docker data device (docker_data_mib).

Sandboxes with volumes or Docker can still use warm stop/start — you lose the processes but keep the filesystem.

start() from paused — the escape hatch

Calling start() on a paused sandbox discards the captured memory and cold-boots the sandbox from its (intact) filesystem. Use this when the frozen processes are no longer useful — for example, the paused state references something that's gone — but the disk contents still matter. It's a one-way door: once cold-booted, the memory image is not recoverable.

Examples

Pause a sandbox mid-computation and resume it later with its processes still running:

from rlp import CreateSandboxFromImageParams, Daytona
 
daytona = Daytona()
sandbox = daytona.create(CreateSandboxFromImageParams(
    image="python:3.12-slim",
    persistent=True,
))
 
# Start a long-running background job inside the sandbox.
sandbox.process.exec("nohup python train.py > /tmp/train.log 2>&1 &")
 
sandbox.pause()              # freeze RAM + processes; free the compute
 
# Later:
sandbox.resume(timeout=120)  # the training process continues where it stopped

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(
  'nohup python train.py > /tmp/train.log 2>&1 &',
)
 
await sandbox.pause()        // freeze RAM + processes; free the compute
 
// Later:
await sandbox.resume(120)    // the training process continues where it stopped

# Pause
curl -X POST https://api.rl.trydaytona.com/vms/$SANDBOX_ID/pause \
  -H "Authorization: Bearer $RLP_API_KEY"
 
# Resume
curl -X POST https://api.rl.trydaytona.com/vms/$SANDBOX_ID/resume \
  -H "Authorization: Bearer $RLP_API_KEY"

Note: the top-level client offers the same operations as daytona.pause(sandbox) and daytona.resume(sandbox, timeout).

Spot sandboxes are auto-paused on reclaim

If a persistent spot sandbox is reclaimed by the platform, it is automatically paused rather than deleted — you can resume() it later and continue where the reclaim interrupted it. See Spot Sandboxes.

See also

• Stop & Start — filesystem-only parking, works with volumes and Docker.
• Fork — duplicate the frozen state into a new sandbox instead of just parking it.
• VM Snapshots — named, restorable captures of disk or memory+disk state.