Repositories

Repositories allow you to store versioned artifacts and other assets — such as OS images, configuration files, or AI models — in a flexible and structured way. While commonly used to distribute assets to devices, repositories are designed as a general-purpose solution for artifact management. They support metadata, lifecycle tracking, and access control, making them suitable for a wide range of use cases — from automated deployment pipelines to customer-facing download portals.

info

Repositories and projects can be freely mixed and matched. For example, you may use the same repository for multiple projects, or use a single project with multiple repositories. This decouple artifact management from device management and allows for more flexible deployment strategies. For instance, you can use a single repository to store your firmware images and link that to multiple projects corresponding to testing and production environments or to multiple different customer projects.

Within repositories, assets are organized in a hierarchical structure:

• Repositories are isolated namespaces for managing and controlling access to packages. Repositories often reflect team, product, or tenant boundaries. As such, repositories are the primary unit of governance, defining ownership and access policies.
• Packages are groups of related assets that evolve together — for example, binaries for different architectures of the same tool.
• Versions are typically immutable snapshots of a package’s assets at a specific point in time.

Each version can have zero or more tags, such as latest or v2.0.1. Tags serve as human-readable, semantic references and must be uniquely associated with a version within the scope of a package. Tags can be either locked or floating:

• Locked tags are stable and always point to a specific version (e.g., v2.0.1).
• Floating tags may change over time to point to different versions (e.g., latest).

Naming constraints for repositories, packages, and asset filenames follow the hierarchy:

• Repository names must be unique within a Nexigon instance.
• Package names must be unique within the scope of a repository.
• Asset filenames must be unique within the scope of a version.

Within a Nexigon instance, specific assets can then be referenced using an asset path of the form:

<repo>/<package>/<version-tag>/<asset-filename>

For example, the latest AARCH64 binary of the Nexigon CLI might be referenced as:

nexigon/nexigon-cli/latest/aarch64-unknown-linux-musl/nexigon-cli

Analogously, packages and versions can be identified by package paths and version paths.

This hierarchical structure and flexible tagging provides a scalable way to manage assets across teams, products, and environments.

Visibility

Repositories can be public or private. By default, packages inherit the visibility of repositories. Public packages can be accessed by anyone without any authentication. In contrast, private packages require authentication.

Assets

Assets are binary blobs stored within a repository. They are stored in a content-addressable way: Each asset is uniquely identified by its content hash, enabling efficient deduplication, integrity validation, and caching.

Assets are not owned by versions, but rather assigned to them. As such, a single asset can be assigned to multiple versions — for example, when the same file appears unchanged across several releases. In addition to the storage and performance benefits, this approach also enables metadata — such as SBOMs, vulnerability lists, test reports, or analysis results — to be attached directly to the asset itself. That metadata then automatically applies to all versions referencing the asset, ensuring consistency.

note

The demo instance does not support asset uploads.

To upload an asset, use the following command:

nexigon-cli repositories assets upload <repo name or ID> <path>

This command will return the ID of the asset. If the asset already exists within a repository, it will return the ID of the existing asset.

To download an asset, use the following command:

nexigon-cli repositories assets download <asset path or ID> [<output path>]

To resolve an asset path to its ID, use the following command:

nexigon-cli repositories assets resolve <asset path>

To get information about an asset, use the following command:

nexigon-cli repositories assets info <asset path or ID>

Packages

To create a package, use the following command:

nexigon-cli repositories packages create <repo name or ID> <package name>

To resolve a package path to its ID, use the following command:

nexigon-cli repositories packages resolve <package path>

To get information about a package, use the following command:

nexigon-cli repositories packages info <package path or ID>

Versions

To create a new version, use the following command:

nexigon-cli repositories versions create <package path or ID>

To resolve a version path to its ID, use the following command:

nexigon-cli repositories versions resolve <version path>

Note that you can use this command to check whether a version with a tag exists.

To get information about a package version, use the following command:

nexigon-cli repositories versions info <version path or ID>