the cli

one binary, two homes: preinstalled in every machine, downloadable for your own computer. same verbs everywhere.

what it is

a thin SSH client for the platform's command console. it speaks plain SSH and forwards commands verbatim: ironwire list does exactly what ssh dashboard@ironwire.sh list does. the same binary runs on your laptop and inside every machine; the only difference is who you are (your SSH key on the laptop, the machine's own identity inside a VM).

inside every machine

mounted read-only at /opt/ironwire (executable: /opt/ironwire/bin/ironwire), already on your PATH in login shells:

$ ironwire list
NAME             STATUS     IMAGE        IP           FLAGS  URL
web              running    ubuntu       10.0.0.2     -      https://web.alice.ironwire.xyz
worker-1         running    ubuntu       10.0.0.3     -      —

zero setup: the injected IRONWIRE_* variables tell it where the platform is and pin its host key, and the machine authenticates with its own per-boot key, rotated every boot and never written to disk. the platform always knows which machine is acting; machine sessions are scoped to your account and are never admin.

on your own computer

<DOWNLOAD: ironwire CLI binaries (linux/macos, amd64/arm64) — add links>

grab the binary. put it on PATH. point it at the platform:

$ mkdir -p ~/.config/ironwire
$ echo "control=ironwire.sh:22" > ~/.config/ironwire/config
$ ironwire list
NAME             STATUS     IMAGE        IP           FLAGS  URL
web              running    ubuntu       10.0.0.2     -      https://web.alice.ironwire.xyz

env vars win over the file: IRONWIRE_CONTROL=ironwire.sh:22. on your laptop the CLI is you: your SSH key, your permissions, no orchestration gate.

why use the cli

fleet verbs are convenience: ironwire list beats typing the ssh prefix. run and cp are the point: streams and files across machines, which a one-shot can't do.

run: a command on another machine, stdio streamed, exit code handed back. pipe data in, pipe results out, branch on failure: ironwire run worker -- ./job.sh < input.json.
cp: files and directories to a machine, without scp setup or key juggling.

script the fleet with it: deploys, CI, controller machines driving workers. interactive work stays on ssh and the dashboard.

commands

same verbs as the SSH one-shots: create, list, info, stop, start, restart, pause, resume, resize, copy, rm, env, ports, stats, usage, whoami, images, drive, and friends. forwarded verbatim, so the command reference applies unchanged:

$ ironwire usage
2/5 machines · 3 vCPU in use (max 8/machine) · 4.0/8.0 GiB · 15.0/25.0 GiB disk

note what a machine may do depends on its orchestration switch. every machine can read and introspect (list, info, stats, usage, whoami, images, plus env and ports). lifecycle verbs like create, stop, and rm require orchestration on that machine.

run & cp (CLI-only verbs)

two verbs exist only in the CLI; they move data and streams, which a console command can't:

$ ironwire run <machine> -- <cmd...>
$ ironwire cp <local-path> <machine>:<remote-path>

run executes a command on a machine as root, streams stdin/stdout/stderr, and forwards the exit code as its own, so scripts can branch on success. the argv is space-joined on the way to the guest, so inline quoting and pipes are unreliable. for anything non-trivial, ship a script with cp and run that:

$ ironwire cp ./setup.sh worker:/root/setup.sh
$ ironwire run worker -- bash /root/setup.sh

note run and cp target machines you own. like lifecycle verbs, they require orchestration when invoked from a machine's CLI.

JSON output for scripting

set IRONWIRE_FMT=json (or pass --json) for machine-readable output. structured verbs return typed objects; everything else wraps its text as {"ok":true,"message":"<text>"}, errors come back as {"ok":false,"error":"<msg>"}:

$ IRONWIRE_FMT=json ironwire env list
{"ok":true,"env":[{"name":"DATABASE_URL","value":"postgres://db.example/app"}]}

success always carries "ok":true; branch on that one field. the remote exit code becomes the CLI's local exit code.

how it updates

nothing to maintain. inside machines the CLI lives on the platform's read-only system volume and updates whenever the platform does. info <name> shows a machine's system version on its system: line. a downloaded laptop binary is yours to update: grab a new one when the platform moves.

agents

running agents? give them the ready-made skill instead of prose: agent skills.