Skip to main content
Limited design-partner access 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. 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

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.
Use a supplied credential in place of <api-token>. 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 <api-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, 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 before evaluating nitsor up, or return to Integrations and public interfaces 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