CLI

The dreadnode CLI (aliased as dn) does two different jobs:

• bare dn launches the app, resumes a session, or runs a one-shot --print prompt
• dn <subcommand> talks to the platform control plane and registry

The rest of the reference lists every subcommand group in the sidebar. This page covers the conventions every subcommand inherits.

Shared platform flags

Every subcommand that hits the Dreadnode platform accepts the same identity and scope flags:

Flag	Purpose
--profile <name>	use a saved profile from ~/.dreadnode
--server <url>	platform API URL
--api-key <key>	raw API key (requires --server)
--organization <slug>	organization scope
--workspace <slug>	workspace scope
--project <slug>	project scope

Explicit flags win over environment variables, which win over saved profile defaults. See Authentication for the full precedence rules, validation, and profile model.

Environment variables

The DREADNODE_* vars split into two families.

Platform — read by dn login, every platform subcommand, and SDK scripts:

Variable	Meaning
DREADNODE_SERVER	platform API URL
DREADNODE_API_KEY	platform API key
DREADNODE_ORGANIZATION	default organization
DREADNODE_WORKSPACE	default workspace
DREADNODE_PROJECT	default project

Local runtime — read when launching or connecting to the agent runtime started by dn serve:

Variable	Meaning
DREADNODE_RUNTIME_URL	client URL to connect to
DREADNODE_RUNTIME_HOST / DREADNODE_RUNTIME_PORT	server bind address
DREADNODE_RUNTIME_TOKEN	optional bearer for the runtime
DREADNODE_RUNTIME_ID	sandbox detection

DREADNODE_SERVER_HOST, DREADNODE_SERVER_PORT, and SANDBOX_AUTH_TOKEN stay accepted for one release with a deprecation warning — prefer the DREADNODE_RUNTIME_* names.

Registry references

The capability, dataset, and model groups accept any of these reference forms:

• name
• name@version
• org/name
• org/name@version

task resolves the latest visible version; scripts and automation use name@latest.

Registry verbs at a glance

The four registry groups share a verb vocabulary:

Verb	What it does
init	scaffold a new local artifact directory
inspect / validate	check a local artifact before publishing
push	publish one new artifact version
sync	bulk-publish a directory of artifacts
info	show a published artifact’s metadata and versions
pull / download	fetch a published artifact locally without activating it
install	download and activate a capability (capabilities only)
publish / unpublish	change cross-organization visibility

--publish on push or sync is the shortcut for uploading and making the artifact public in one step.

Common confusion points

• --server is the platform API URL. The runtime host uses --runtime-server.
• dn serve starts a local runtime server. dn runtime list inspects hosted runtime records.
• dn sandbox expects a provider sandbox ID, not an internal database UUID.
• dn capability install ./path activates a local capability; dn capability pull org/name@ver only downloads it.
• dn airt run and dn airt run-suite launch attacks; the rest of dn airt reviews assessments, reports, analytics, and findings.