Nexigon CLI

Nexigon CLI manages Nexigon Hub resources from a workstation or automation job. It can also forward device ports to your local machine for SSH and other network services.

Installation and Setup

Next describes unreleased Nexigon CLI changes. Authentication inspection, organization selection, and the scheduling and retention commands require a build from a matching development revision of the Nexigon source. Those changes are not included in Nexigon CLI 0.6.1. For current release downloads, use Nexigon CLI 0.6.

For checksums and other builds, see Nexigon CLI releases.

On Linux and macOS, make the downloaded binary executable:

chmod +x nexigon-cli

The examples below run it from the download directory as ./nexigon-cli. On Windows, use .\nexigon-cli.exe. You can also place the binary in a directory on your PATH and run it as nexigon-cli.

Configure Nexigon CLI

Create a user access token in the web interface. Nexigon CLI 0.6 and later also accept an organization API token, whose access is restricted by its policy.

Run:

./nexigon-cli configure

Enter your Nexigon Hub URL and API token. The command saves them to ~/.nexigon/cli.toml:

hub-url = "https://eu.nexigon.cloud/"
token = "u_sk_..."

Keep this file private because it contains the token.

Select a Configuration File

An explicit --config path takes precedence. Otherwise, Nexigon CLI uses .nexigon-cli.toml in its current working directory if present, followed by ~/.nexigon/cli.toml.

Run ./nexigon-cli configure --local to save a configuration in the current directory. If this directory is a Git repository, add .nexigon-cli.toml to .gitignore to keep the token out of commits. Without --local, configure updates the global file even when a local configuration takes precedence.

For an explicitly selected configuration:

./nexigon-cli --config ./production-cli.toml auth status

Authentication and Organization Selection

Run the following command to verify the configured token against Nexigon Hub:

./nexigon-cli auth status

The JSON output identifies the authenticated actor as UserToken or OrganizationApiToken, with its token ID and the corresponding userId or organizationId. It does not disclose the secret token.

A user token can access more than one organization. Resource commands require --organization <org-id> to select the organization whose resources you intend to operate. In the web interface, open that organization and copy the org_… segment from the page URL. For example:

./nexigon-cli --organization <org-id> projects list
./nexigon-cli --organization <org-id> projects info <project-id>
./nexigon-cli --organization <org-id> projects create "Production"
./nexigon-cli --organization <org-id> repositories create "Firmware"
./nexigon-cli --organization <org-id> devices info <device-id>

With an organization API token, omit --organization: the token selects its own organization. If you supply the option, it must match that organization.

Organization selection constrains resource lookups as well as listing and creation. A resource ID from another organization returns NotFound, even when the user has access to both organizations. The token still needs its usual permissions for each operation.

Project and repository creation now use the organization option instead of a positional organization ID. For example, replace projects create <org-id> "Production" with projects create "Production" --organization <org-id>. The Agent’s local repositories create command also requires --organization <org-id>.

configure and auth status do not require an organization. Raw actions execute uses its API input exactly as supplied and does not apply the option or send an organization header. Organization tokens remain restricted to their own organization.

The examples in the following sections assume an organization API token. With a user token, include --organization <org-id> in each resource command. For the transport-level behavior, see Organization Scope.

For automation, prefer an organization API token. Publishing to an existing package needs repository view and manage_assets, plus package view and manage_versions, scoped to the target repository and package. Creating a package also requires repository manage_packages. Unrelated organization, project, and device permissions are not needed.

Publish Package Versions

Follow Publish a Package Version to create a release, upload and attach several files, add tags, and verify a download. The guide also shows how to read IDs from Nexigon CLI’s JSON responses.

Port Forwarding

Follow Establish a Remote Connection for SSH, local HTTP forwarding, multiple ports, browser URLs, and troubleshooting.

Schedule Builds from CI

Use the version ID returned by creation when changing a particular build’s deadline. A floating tag might select a different build later.

# Retain a new nightly build for seven days.
nexigon-cli repositories versions create firmware/controller \
  --name nightly --tag nightly,reassign --delete-after 7d

# Reset a particular build's deadline to fourteen days from now.
nexigon-cli repositories versions schedule-deletion <version-id> --delete-after 14d

# Cancel this deadline. Package retention still applies.
nexigon-cli repositories versions schedule-deletion <version-id> --cancel

Durations must be positive. Use seconds (s), minutes (m), hours (h), days (d), or weeks (w), including combinations such as 2h30m. A day is 24 hours and a week is seven days. Calendar months and years are not supported. The Nexigon CLI computes the deadline using its current clock immediately before sending the request. Rescheduling counts from now, not from the previous deadline.

For an absolute deadline, use --delete-at when creating a version or --at when scheduling an existing version. Timestamps must include a timezone:

nexigon-cli repositories versions schedule-deletion <version-id> --at 2027-01-31T00:00:00Z

Choose one of a duration, an absolute deadline, or cancellation. Creation stores the deadline atomically with the new version, so a rejected deadline leaves no version behind. Scheduling requires the same package permission as manual version deletion.

See scheduled version deletion for tag removal, cancellation, and asset cleanup behavior.

Preserve Releases and Retain Routine Builds

Seal a completed release to permanently protect its contents and prevent deletion. Complete its contents and metadata first; sealing cannot be reversed.

Configure retention per package. Either exceeded limit deletes an unsealed version; sealed versions are excluded and do not count toward the limit.

# Keep at most 100 unsealed versions and expire builds older than 30 days.
nexigon-cli repositories packages set-retention firmware/controller --max-versions 100 --max-age-days 30

# Permanently preserve a completed release and cancel any scheduled deletion.
nexigon-cli repositories versions seal <version-id>

# Disable the package policy. Explicit deletion schedules still apply.
nexigon-cli repositories packages set-retention firmware/controller --disable

set-retention replaces the policy. Supply only --max-versions or --max-age-days to use a single limit. Changes apply to existing versions on the next cleanup run. Seal releases before enabling a policy that could delete them. Use packages info to inspect the saved policy and versions info to inspect protection.

See sealed versions and version retention for editing, tagging, deletion, and storage cleanup behavior.

Command Help

Run ./nexigon-cli --help to list command groups, or append --help to a subcommand for its arguments.