ornn) to sign in from a terminal and run tenant-scoped reservation, access, and billing commands through the same web authorization layer as the browser app.
Easy Install
Install from the hosted web app:- prints a short Ornn Compute welcome banner and login prompt
- requires Node.js 20 or newer and
npm - installs
@ornncompute/cliglobally - installs the
ornncommand - adds the npm global bin directory to your shell profile if needed
- records the host that served it as
authBaseUrlin~/.config/ornn/config.json
ORNN_INSTALL_BANNER=0 to skip the banner or ORNN_INSTALL_ANIMATION=0 to keep the banner static in scripted installs.
After install, restart your shell or source the updated profile, then run:
Browser login
ornn login uses a browser device flow:
- The CLI asks the web app for a one-time device code.
- The CLI opens a browser to
/cli/device/<code>when possible. - You sign in with the normal Ornn web login flow.
- Once the browser session is authenticated, the CLI device request is approved automatically.
- The CLI stores the approved session in
~/.config/ornn/auth.json.
Commands
listings and exchange. Older names availability and bid remain as aliases (availability → listings, bid → exchange).
Bid and reservation list commands return a bounded page (500 rows by default).
Use --limit and --cursor to traverse older history: pass the final row ID
from one page as the next page’s cursor. Exact show and
reservation checkout commands work independently of the selected page.
--json on read/show/list commands and transaction handoffs when you need structured stdout for scripts. Errors and login/browser progress go to stderr.
Run ornn --help or <command> --help for the full command list.
Staff-only fleet cleanup, enrollment, Commerce linking, and deployment commands
are documented in the repository operator runbook rather than this
tenant-facing command reference. Fleet cleanup uses a generated per-node policy:
every discovered account, key, workload, service, runtime object, path, and drive
must be kept, removed, replaced, erased, or explicitly ignored before the exact
recorded plan can be approved. Coverage gaps such as advanced SSH, unmodeled
mounts, network state, IPC/swap, or active block stacks must also be explicitly
ignored with a reason. In-band cleanup never erases the system drive, and only
device-confirmed capabilities are offered for stronger data-drive erasure.
Cleanup receipts are retained as audit evidence. Receipt validation never
blocks fleet enrollment or deployment; invalid or unavailable receipts produce
warnings during enrollment and the installer uses its legacy sanitizer.
Launch and connect
ornn nodes launch registers or reuses your SSH public key, selects VM or Bare
Metal access, queues the launch, and can wait until SSH is ready. Use
--mode vm for VM access and --mode bare-metal for direct host access. If you
pass a private key path by mistake and the matching .pub file exists, the CLI
uses the public key file and refuses to upload private key material.
Use --network private, --storage-load-drive-id, and
--storage-save-drive-id to select private networking and storage volume intent
for launches that already support those options in the web app.
Use ornn ssh <node-id> to connect directly. Passing a reservation id also
works when exactly one active node in that reservation is SSH-ready.
Reboot and hard reset
Cycle a live node without releasing the reservation:ornn nodes reboot cycles the operating system on the host and leaves the
tenant user, home directory, authorized SSH keys, and attached Ornn volumes
in place. ornn nodes hard-reset wipes tenant data on the host (user, home,
authorized keys, and /tmp, /var/tmp, /dev/shm residue), reboots, and
re-pushes the reservation’s active SSH keys on reconnect. Use hard reset to
return a Bare Metal host to a clean state without giving up the reservation;
copy anything you want to keep off the host first.
Monitor node health
ornn metrics shows the same tenant-safe live health signal as Observability:
GPU utilization, GPU memory, GPU power, GPU throughput in TFLOP/s, heartbeat
time, and live/stale/offline status. Use history for tenant-safe historical
telemetry and watch after SSH to keep a terminal view of whether the node is
healthy under load.
Clusters from the CLI
ornn clusters mirrors the web Orchestration console. Use eligible-nodes to see
same-island nodes before launch, add-node or remove-node to manage a live
cluster, and teardown to release it. Kubernetes credentials are exported with
kubeconfig; Slurm credentials expose an SSH login command.
Slurm and Kubernetes shortcuts
ornn slurm and ornn kubernetes are shortcuts for the same operations as
ornn clusters ... --type slurm and ornn clusters ... --type kubernetes. Use
them when you already know which cluster type a reservation runs so you can
skip the --type flag. Both groups accept --json on every subcommand.
launchprovisions the cluster on the reservation.teardownreleases the cluster without releasing the reservation.statusshows the current cluster state.credentialsprints connection details for the cluster.ornn slurm sshopens (or prints, with--print) an SSH session to the Slurm login node.ornn kubernetes kubeconfigwrites a kubeconfig to--output(or stdout) for use withkubectl.
<command> --help without
one prints usage and exits.
Networks and storage
ornn networks mirrors the customer Network console for private networks and
reservation network attachment. ornn storage volumes manages storage drives
that can be selected at node launch. ornn storage deploy creates the
reservation-scoped colocated bucket/prefix placement and moves it into
pre-positioning. ornn storage buckets connect s3|r2
registers S3-compatible sources and scoped credentials for later deployment to a
reservation. ornn storage buckets connect gcs registers a customer-owned GCS
bucket for the same deploy flow through GCP Storage Transfer Service; the source
bucket must allow the Storage Transfer service account to read it. Use
--url to paste supported provider console URLs, and --verify
to check S3-compatible credentials during registration.
ornn storage buckets verify confirms Ornn can access the source
before deployment. Use update-credentials to repair stale S3-compatible keys,
and disconnect to remove the Ornn connection without deleting customer
bucket data. Customer image profiles are disabled on main, so image
commands are not exposed.
Use ornn storage files upload before or during a direct FUSE mount. Every
mounted node sees the file on its next lookup. You do not need to remount. A
direct FUSE drive attaches to one reservation by default; pass --all-nodes
when deploying to fan the same mount out across every compatible node in the
node group. Avoid concurrent writes to the same file path because object storage
is not a POSIX shared filesystem.
Deploy a connected bucket once before uploading. Ornn imports it into an
Ornn-managed colocated working copy. That copy remains durable across detach
and later mounts. Detach flushes every mounted node before releasing the
volume. Ornn does not write changes back to your original bucket.
Environment variables
ORNN_AUTH_BASE_URL: web/auth origin used byornn login. Unset, it falls back to theauthBaseUrlthe installer recorded inconfig.json, then tohttp://localhost:3000.ORNN_API_BASE_URL: optional web API origin for CLI commands. Defaults toORNN_AUTH_BASE_URL.ORNN_CONFIG_HOME: directory for CLI auth state. Defaults to~/.config/ornn.
Troubleshooting
Login opens the wrong host
Check the origin the installer recorded, and whether an environment variable is overriding it:Browser does not open
Use the manual URL fallback:Login expires
Runornn login again. Device login requests are short-lived by design.
You are logged in but commands say unauthorized
Confirm the account and tenant:/api/cli/*, so they reuse the same tenant and role checks as the web app.