> ## Documentation Index > Fetch the complete documentation index at: https://docs.nitsor.com/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > Nitsor is a pre-release product. Every page in this documentation carries an availability status in its frontmatter (`availability`) and, as the first element of its body, a link labelled `Available now`, `Limited design-partner access`, or `Planned - not available yet`. That label is binding: it says whether a reader can use the behaviour the page describes. > A page written in the present tense is not a claim that the behaviour ships. Where the availability label says `Planned - not available yet`, the page describes a target contract and there is no runnable product, screen, command, or public interface behind it. > Every readiness claim this documentation makes lives on the Product status page. If any statement elsewhere disagrees with the capability status matrix on that page, the matrix is correct. > Reading this documentation grants no product access and no permission. No agent can create or approve a Nitsor release. # Command-line interface > See the five implemented commands, their tested guarantees, and the distribution boundary that prevents public installation instructions. **Status: Limited design-partner access.** Five command families exist and have automated coverage. There is no published release pipeline, so this page does not offer a public installation command. The CLI uses the same request and response contracts described in [Public HTTP API](/reference/api). It authenticates with the same scoped agent credential that page describes; the CLI consumes a credential issued in the dashboard and never mints one. ## Command inventory | Command | What it does | Tested boundary | | ---------------------- | ------------------------------------------------------------------------------------ | ----------------------------------------------------------------------- | | `nitsor login` | Validates a credential against the session route and stores the accepted connection. | Invalid credentials fail; a rejected credential is not echoed to output | | `nitsor projects list` | Lists projects as a table or machine-readable JSON. | Authentication failure, table output, JSON output, and contract parsing | | `nitsor sources list` | Lists registered sources as a table or machine-readable JSON. | Authentication failure, table output, JSON output, and contract parsing | | `nitsor up` | Generates and starts the current self-host dependency stack after preflight checks. | Preflight, digest pins, private secrets, health waits, and repeat runs | | `nitsor version` | Prints the CLI version. | Literal command output | The source list identifies registered sources with status and viewability; JSON includes format, and the table includes file counts. This list does not make every recognized format viewable or production-supported. Login stores credentials in an owner-only file with mode `0600` on supported systems. Command failures use structured issue codes and non-zero exits. Machine-readable output goes to standard output; errors go to standard error. Tests verify that a rejected credential is not echoed to output. The credential is a secret bearer token; treat it like any other secret. ## Distribution and installation **Installation is not a runnable instruction.** The installer logic verifies checksums in tests, but no release pipeline publishes the package and image targets it would download. A copy-and-paste install example would therefore describe an unavailable path and remains forbidden. An authorized design-partner evaluation must receive its build and setup instructions directly, together with the exact version and provenance being evaluated. ## Tested command sequence The following sequence is runnable only with a build, credential, and API origin supplied for an agreed design-partner environment. Process-level tests execute these exact command forms through the packaged CLI and the HTTP router. ```bash theme={"system"} nitsor login --token --base-url --json nitsor projects list --json ``` Use a supplied credential in place of ``. The credential is a scoped, revocable secret token. Never paste a credential into logs, tickets, chat, or shared shell history. Separate process tests also execute `nitsor login --token `, `nitsor projects list`, and `nitsor sources list --json`. The `up` and `version` families remain inventory entries above, not runnable examples: their exact public invocations do not have the same process-level evidence, and no public distribution exists. ## Commands that are absent There is no public command for project creation, storage registration, DICOM registration, branch or commit management, review, consensus, adjudication, release creation, export, upgrade, rollback, or general help. Their absence is deliberate documentation, not an implied alias. ## Common mistakes and limits * JSON output makes automation easier; it does not make the authentication model production-ready. * `nitsor up` starts the dependency stack described in [Self-host mechanics](/reference/self-host), not a complete Nitsor product. * A tested installer script is not a published distribution. * Shared contracts reduce drift, but they do not replace testing against a supported public environment. ## Next step Read [Self-host mechanics](/reference/self-host) before evaluating `nitsor up`, or return to [Integrations and public interfaces](/reference/integrations) for the wider boundary.
OutcomeChoose an implemented command and understand which installation and workflow commands do not exist yet.
AvailabilityLimited design-partner access
AudienceSoftware engineers, Data engineers, Platform engineers, AI agents
PrerequisitesRead the Public HTTP API authentication scheme; Work within an agreed design-partner environment
Last verified2026-08-23