Stop & Start

Stopping a sandbox shuts down its virtual machine and releases the CPU, memory, and network identity it was using, while keeping its filesystem intact on durable storage. Starting it later boots the same filesystem again, so everything you installed or wrote to disk is exactly where you left it. This makes stop/start the cheapest way to keep an environment around between work sessions without paying for idle compute.

Stop and start are available only for persistent sandboxes — sandboxes created with persistent: true. See Persistent Sandboxes for what that flag does and what it costs.

How stop works

POST /vms/:id/stop kills the sandbox's compute but preserves its write layer. The sandbox moves through running → stopping → stopped, and stays stopped indefinitely — Daytona never auto-deletes a stopped persistent sandbox.

Two things to keep in mind:

• Processes do not survive a stop. Stop is a shutdown, not a freeze. If you need running processes and in-memory state to survive, use Pause & Resume instead.
• Ephemeral sandboxes cannot stop. A sandbox created without persistent: true has no durable write layer, so the API refuses the stop with 409 Conflict (the SDKs surface this as a not-supported error). Delete it and recreate instead.

How start works

POST /vms/:id/start boots the stopped sandbox again. Because the filesystem lives on durable storage rather than on any particular machine, the sandbox may come back on different hardware than it ran on before, and it always gets a fresh IP address. Anything that cached the old network identity (long-lived connections, addresses you wrote down) needs to reconnect after a start; preview endpoint URLs and tokens stay stable across a warm stop/start.

The SDK start() call waits until the sandbox is running (or raises after timeout seconds).

Billing while stopped

A stopped sandbox bills storage only — you pay for the disk space its filesystem occupies, and nothing for CPU or memory. This is what makes stop/start a good fit for environments you use intermittently.

Examples

Stop a persistent sandbox at the end of a task and start it again the next day:

from rlp import CreateSandboxFromImageParams, Daytona
 
daytona = Daytona()
sandbox = daytona.create(CreateSandboxFromImageParams(
    image="python:3.12-slim",
    persistent=True,
))
 
# ... do work ...
 
sandbox.stop()          # frees compute; filesystem is kept
 
# Later — possibly from a different process:
sandbox = daytona.get(sandbox.id)
sandbox.start(timeout=120)   # boots again, waits until running

import { Daytona } from '@rlp/sdk'
 
const daytona = new Daytona()
const sandbox = await daytona.create({
  image: 'python:3.12-slim',
  persistent: true,
})
 
// ... do work ...
 
await sandbox.stop()    // frees compute; filesystem is kept
 
// Later — possibly from a different process:
const revived = await daytona.get(sandbox.id)
await revived.start(120)   // boots again, waits until running

# Stop
curl -X POST https://api.rl.trydaytona.com/vms/$SANDBOX_ID/stop \
  -H "Authorization: Bearer $RLP_API_KEY"
 
# Start again later
curl -X POST https://api.rl.trydaytona.com/vms/$SANDBOX_ID/start \
  -H "Authorization: Bearer $RLP_API_KEY"
 
# Poll until the status is running again
curl https://api.rl.trydaytona.com/vms/$SANDBOX_ID \
  -H "Authorization: Bearer $RLP_API_KEY"

Note: daytona.stop(sandbox) and daytona.start(sandbox, timeout) are equivalent client-level helpers if you prefer calling through the top-level client.

Choosing the right lifecycle operation

Stop/start is one of three ways to put a sandbox aside. Pick based on what you need to survive:

Stop/start also works in cases pause refuses in v1 — sandboxes with attached volumes or a Docker data device can always warm stop/start.

See also

• Persistent Sandboxes — the persistent: true flag and its tradeoffs.
• Pause & Resume — when processes must survive.
• Fork — duplicate instead of parking.