Skip to content

Managing runtimes

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

Use the CLI to manage runtime compute and the TUI or App to attach an interactive session. A runtime’s credential belongs to the sandbox, not to whichever client asked for it, so another device owned by the same user can connect without interrupting the first.

Terminal window
dn runtime list
dn runtime list --mine
dn runtime list --json
dn runtime get airt-scout-80

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. get takes either the runtime key shown in the list or its UUID.

A runtime belongs to whoever created it. You can see your colleagues’ runtimes, because reading spans the workspace, but you cannot start, pause, resume, or reset one — those answer 403. Runtimes you do not own are marked read-only in the list, and --mine leaves them out altogether. With --json, each row carries owned_by_me and created_by.

From the TUI, press Ctrl+R (or /runtimes) to open the runtimes screen. Type into the search row to filter by runtime ID, project, provider, or state — structured filters like state:running, provider:e2b, project:default, and connected:yes work in the same field. The list refreshes automatically every few seconds, and n creates a new runtime in the active project without leaving the screen.

Dreadnode TUI runtimes screen

Terminal window
# start a specific runtime by its key, as shown in `dn runtime ls`
dn runtime start airt-scout-80
# ...or by UUID
dn runtime start 7c1e2d4f-9e0a-4b6d-8c3f-2a1b5d7e9f01
# 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 leaves the live sandbox untouched and returns its credential. Retrying start after a lost response is safe: the retry returns the same credential and disconnects nobody.

Runtime credentials belong to the user who started the current sandbox. Another device signed in as that user can attach; another workspace member cannot. Reset the runtime when ownership needs to change.

If the durable configuration, capability set, or build source changed since the sandbox was provisioned, the CLI reports the drift but does not rebuild automatically. Applying the change costs everything inside the current sandbox, so use an explicit reset:

Terminal window
dn runtime reset airt-scout-80 # prompts; -y to skip
dn runtime start airt-scout-80 # provision against the current config

From the TUI, use the runtime’s Reset action, then start it.

<target> is read as a runtime key or UUID first, and falls back to a project. When a project has several runtimes, name the one you want directly rather than passing --runtime-id.

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

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 suspends the sandbox without losing state. Credits stop accruing immediately. Resume restores the same sandbox — session history, capability bindings, and working state all come back.

Terminal window
dn runtime pause airt-scout-80
dn runtime resume airt-scout-80
dn runtime keepalive airt-scout-80 --extend-seconds 900

Resume restores compute but does not return a credential. Run dn runtime start airt-scout-80 afterward when the caller needs one. Fetching it disconnects nobody.

Extend expiration (+5 min) pushes the sandbox’s expiry window out when you need more time. Sandboxes start with a one-hour window by default, and the platform caps any extension at your organization’s sandbox runtime limit — and, on the hosted platform, at what your remaining credits cover. Use it proactively; the sandbox is terminated automatically when it times out, and termination is final for that sandbox.

Reset discards the current sandbox and returns the runtime to idle without losing the runtime’s identity, bindings, or project association. It also destroys that sandbox’s credential, which disconnects every attached client — reset is how access is withdrawn. 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.

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.

Running out of credits terminates the sandbox. The record may show it paused with a pause_reason of insufficient_credits — that marks why compute stopped, but the sandbox itself is gone. After a top-up, start the runtime again: durable configuration and capability bindings come back with the fresh sandbox, in-sandbox working state does not.

Runtime records can’t be deleted — an idle runtime holds no compute and costs nothing, and the record is removed with its project. To reclaim compute, reset the runtime or delete the sandbox directly:

Terminal window
dn sandbox delete 3f8a1c2e-7b4d-4e0f-9a6c-1d2e3f4a5b6c

Deleting a sandbox is the CLI equivalent of a reset: the runtime returns to idle and keeps its identity and bindings.