Skip to content
Dreadnode Dreadnode Dreadnode

Managing runtimes

List, start, pause, resume, reset, and connect to workspace runtimes from the CLI and TUI.

Runtime lifecycle work splits cleanly across two surfaces. The CLI lists and creates; the TUI is where live runtimes get connected, paused, resumed, extended, and reset.

List what’s there

Section titled “List what’s there”
Terminal window
dn runtime list
dn runtime list --json
dn runtime get 7c1e2d4f

The list shows every runtime in the active workspace with its status, name, key, and project. Details include the current sandbox, expiry, and billing totals when the runtime is running.

From the TUI, press Ctrl+R (or /runtimes) to open the runtimes screen. Type into the search row to filter by name, key, project, or provider — structured filters like state:running, provider:e2b, project:default, and connected:yes work in the same field.

Dreadnode TUI runtimes screen

Start a runtime

Section titled “Start a runtime”
Terminal window
# start a specific runtime by UUID (or prefix)
dn runtime start 7c1e2d4f


# start the only runtime in a project, or create the first one
dn runtime start my-project


# ensure and start from a runtime.yaml
dn runtime start --file runtime.yaml

Starting an idle runtime provisions a fresh sandbox. Starting a running runtime is a no-op if the durable configuration still matches the live sandbox — if it doesn’t, the old sandbox is replaced.

When a project has multiple runtimes, pass --runtime-id or a --key/--name pair so the CLI knows which one you mean.

From the TUI, select a runtime and press s (or use the detail view’s Start runtime action) to start it.

Connect to a running runtime

Section titled “Connect to a running runtime”

Connection state is tracked separately from runtime state — a runtime can be running without being the one your current TUI session is attached to.

  • From the TUI, press c on a running runtime, or open its detail view and pick Connect.
  • From the App, open the runtime and use the session picker.
  • To connect from a different machine, point dn at the runtime server URL: dn --runtime-server https://… (covered in Local runtime server).

The TUI’s detail view is state-aware: idle runtimes offer Start, running runtimes offer connect/disconnect, pause, logs, reset, and Extend expiration, and paused runtimes offer resume, logs, and reset.

Pause, resume, and extend

Section titled “Pause, resume, and extend”

Pause from the TUI detail view to suspend the sandbox without losing state. Credits stop accruing immediately. Resume restores the same sandbox — session history, capability bindings, and working state all come back.

Extend expiration (+5 min) pushes the sandbox’s expiry window out when you need more time. Use it proactively; the sandbox is terminated automatically when it times out, and termination is final for that sandbox.

Reset for a clean environment

Section titled “Reset for a clean environment”

Reset discards the current sandbox and returns the runtime to idle without losing the runtime’s identity, bindings, or project association. The next start reprovisions fresh compute against the current durable configuration.

Reset from the TUI detail view. The runtime’s own identifier — and anything attached to it, like sessions and capability installs — is preserved.

When a sandbox is terminated

Section titled “When a sandbox is terminated”

Sandboxes transition to the final killed state when they time out, when you delete them explicitly, or when your organization runs out of credits. A runtime whose sandbox was killed returns to idle — a subsequent start will provision a new sandbox.

Credit exhaustion pauses running sandboxes with a pause_reason of insufficient_credits rather than killing them outright, so resuming after a top-up picks up where you left off.

See also

Section titled “See also”