Authentication

Saved profiles, BYOK provider keys, machine credentials for CI, and the resolution rules that decide which org and workspace a command runs against.

The first-time login flow is covered in the Quickstart. This page covers everything else: switching profiles, BYOK provider keys, machine credentials, and the precedence rules that decide which org and workspace a command runs against.

Profiles

A profile is a saved bundle of platform URL, API key, and default org/workspace/project. Profiles live under ~/.dreadnode/, and the most recent successful login becomes active.

Inside the TUI:

/login re-authenticates or switches to a different platform profile
/logout disconnects the active profile
/profile opens the saved-profile picker
/workspace <key> switches the active workspace and restarts the runtime
/workspaces lists available workspaces
/projects [workspace] lists projects in the current or named workspace

Ctrl+W opens the workspace and project browser if you’d rather click than type.

Use dn login when you want a profile saved before launching the TUI, or when you’re driving the CLI from automation.

Save the default profile

# Browser device-code flow (recommended)
dn login

# Paste an existing API key non-interactively
dn login dn_key_abc123

Either form saves a profile under ~/.dreadnode/ and becomes active for later commands.

Name a second profile

You can keep multiple accounts or deployments side-by-side. Pass --profile at login to create a named slot, then select it on later commands with the same flag:

dn login --profile work
dn login --profile personal dn_key_xyz789

# Run against a specific profile without switching the active one
dn evaluation list --profile work

Profile names default to your username when --profile is omitted.

Self-hosted platform

Point the CLI at a custom platform URL with --server. Combine with --profile to keep the self-hosted profile separate from your SaaS one:

dn login --server https://dreadnode.acme.internal --profile acme-prod

--organization, --workspace, and --project set the saved profile’s defaults so later commands don’t need them:

dn login --profile lab --organization acme --workspace research --project webapp-audit

Check current context

dn whoami prints the active profile, user, org, workspace, and project — useful for confirming which account a command is about to run against:

$ dn whoami
work  profile
  user       alice
  email      alice@example.com
  org        acme
  workspace  research
  project    webapp-audit
  server     https://app.dreadnode.io

Add --json for scripting.

Log out

The CLI does not ship a standalone dn logout. Disconnect from inside the TUI with /logout, or overwrite the saved profile by running dn login --profile <name> again.

Provider presets and BYOK

/secrets is the quickest way to verify whether provider-backed models are ready to use. Provider presets show whether you have stored the canonical environment variable a provider expects.

Supported providers: anthropic, openai, google, mistral, groq, custom.

Provider	Typical credential shape
anthropic	`sk-ant-...`
openai	`sk-...`
google	`AIza...`
mistral	`mistral-...`
groq	`gsk_...`
custom	custom provider key

Seeing a preset as configured means the secret exists in your user secret library. It does not mean every runtime has already injected it — secret injection happens when a runtime or evaluation is created with specific secret_ids.

Scope resolution

Scope values layer on every command: explicit flags (--workspace lab) beat environment variables (DREADNODE_WORKSPACE=lab), which beat saved profile defaults. --profile and --server are mutually exclusive, and --api-key requires --server.

If you don’t pass any scope flags, the CLI resolves them from the active profile:

it picks an organization you can access
it prefers the workspace marked as the default workspace
it uses the workspace’s default project when the platform can provide one

That’s why later commands often work without --organization, --workspace, or --project every time.

Environment variables

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

A shell that exports these values behaves like a disposable profile:

export DREADNODE_SERVER=https://app.dreadnode.io
export DREADNODE_API_KEY=dn_key_...
export DREADNODE_ORGANIZATION=acme
export DREADNODE_WORKSPACE=main

dn evaluation list

Raw credentials for CI

CI and short-lived shells should skip saved profiles and pass --server with --api-key:

dn task sync ./tasks \
  --server https://app.dreadnode.io \
  --api-key "$DREADNODE_API_KEY" \
  --organization acme \
  --workspace main

Raw-credential commands never touch ~/.dreadnode/, so parallel CI jobs don’t race on profile writes.

Machine API keys

For CI, trace exporters, or other machine users, create scoped user API keys instead of sharing your interactive one. Scoped keys can be restricted to one organization, one workspace, or a subset of scopes — see Users for the management surface.