CLI Reference

The wardn CLI is a thin client — inside cluster shell pods it's pre-wired via WARDN_API_URL/WARDN_TOKEN; outside, pass --api/--token or set the same env vars. Its surface is small today: introspection commands plus the MCP/agent layer.

There are no wardn app, wardn cluster add, wardn deployment, or wardn app rollback commands. Those exist only in old docs — use the REST API for mutations. The list below is the real command tree.

Build / Install

No published binaries yet — build from source:

cd cli
go build -o wardn ./cmd/wardn
sudo install -m755 wardn /usr/local/bin/wardn

Global Flags

Flag	Env default	Description
`--api`	`WARDN_API_URL`	API base URL — e.g. `http://localhost:8080`
`--token`	`WARDN_TOKEN`	Bearer token (a `wrd_` API key)

Inside shell pods both are injected by the server — commands run flagless.

Commands

`wardn whoami`

Show the caller's identity — user id, org role, key scope (when a wrd_ key is in use). Reads GET /auth/me.

wardn whoami

`wardn clusters`

List registered clusters with live status (GET /clusters).

wardn clusters

`wardn status`

API health + who you're authenticated as — a GET /healthz + GET /auth/me combo.

wardn status

`wardn can-i <permission>`

Check a permission via POST /auth/can-i. --scope defaults to org; --on targets a cluster or deployment (cluster/namespace).

wardn can-i deployment:sync --scope deployment --on prod-cluster/default
# {"allowed": true}

`wardn mcp` — agent-facing group

Bare wardn mcp runs the stdio MCP proxy — point an MCP client's command/args at it; the proxy injects the stored wrd_ key on every request.

Subcommand	Behavior
`wardn mcp login`	Device-flow browser login — mints a scoped `wrd_` key, stores to `~/.config/wardn/credentials.json`. Flags: `--api-key` (store an existing key), `--name`, `--scope`/`--on` (org\|cluster\|deployment + target), `--role` (read\|sync\|admin), `--expires-days`, `--auth-url` (env `WARDN_AUTH_URL`)
`wardn mcp logout`	Remove stored credentials
`wardn mcp status`	Show + verify the stored credential against the API
`wardn mcp proxy`	Explicit stdio proxy (aliases: `serve`, `stdio`) — same as bare `wardn mcp`

wardn mcp login --role sync --scope deployment --on prod/default

`wardn version`

Print the build-stamped version (dev for local builds).

What's planned

App/cluster/deployment write commands (wardn app sync, wardn cluster add) land when the API surface stabilizes — track them on the Roadmap. Until then, drive mutations with curl against the REST API — the CLI's introspection commands are thin wrappers over it anyway.

Using the CLI in CI

# GitHub Actions — check a scoped permission before acting
- name: Check deploy permission
  env:
    WARDN_API_URL: ${{ secrets.WARDN_API_URL }}
    WARDN_TOKEN: ${{ secrets.WARDN_TOKEN }}
  run: wardn can-i deployment:sync --scope deployment --on prod-cluster/default

Getting Started — install Wardn and deploy your first app
MCP Server — the agent-facing half of the CLI
Applications API — the REST calls behind can-i/clusters
Configuration — App CRD spec

CLI Reference

On this page