Skip to main content

Software Updates

This guide explains how to manage and distribute software updates using Nexigon repositories.

What are repositories? Repositories store versioned artifacts (called assets) such as OS images, configuration files, binaries, and AI models as well as their metadata such as SBOMs. They provide:

  • Hierarchical organization of packages and versions.
  • Flexible tagging for release management.
  • Content-addressable storage for deduplication and integrity.

Nexigon implements a flexible system to organize artifacts: A repository can contain multiple packages, each package can have multiple versions, and each version can have multiple assets attached to it. Each version can be assigned multiple tags such as v1.2.4 or stable. Tags can either be locked or floating. Locked tags are bound to a specific version and cannot be assigned to another version (e.g., v1.2.4 or build-20260112-101202). Floating tags can be reassigned and move from version to version (e.g., stable or beta).

Packages and versions can be created through Nexigon's UI as well as the CLI.

Polling-Based Software Updates​

Nexigon does neither prescribes the format of software updates nor how they are installed. Instead, it provides flexible building blocks to build OTA update workflows on-top. A typical workflow may poll for updates through Nexigon and use device properties for configuration as well as device events to report telemetry.

If you want to see a full-blown example, check out the nexigon-rugix-ota update script that implements full A/B system updates using Rugix. The script is easily adapted for RAUC, SWUpdate, or any other solution you may want to use. Generally, polling-based updates have the following structure:

  1. Determine the update configuration (could be hard-coded). Such an update configuration can, for instance, specify the tag of the version that should be installed on a device.
  2. Fetch information about the desired version through Nexigon.
  3. Compare the current version and the desired version. If they disagree, install the update.

To query information about the desired version as well as to obtain a download link for an asset, Nexigon Agent provides an issue-url command. For instance, the nexigon-rugix-ota update script mentioned above determines the desired version based on a Rugix Bakery build information file associated with a version as follows:

build_info_url=$(nexigon-agent repositories issue-url "<repo>/<package>/<tag>/<system-name>.build-info.json" | jq -r '.url')
build_info=$(curl -sSfL "$build_info_url")

desired_version=$(echo "$build_info" | jq -r '.release.version')

The desired version is then compared to the version of the system built into the active system through Rugix Bakery.

tip

Nexigon's repository functionality can be used to distribute updates and other assets of various types to devices. For instance, the same functionality can be used to distribute packages, containers, and configuration files. If you want an easy start, consider using the Nexigon template for Rugix Bakery.

Release Workflow​

Here is an example shell script for a release workflow using Nexigon:

#!/usr/bin/env bash

set -euo pipefail

REPOSITORY="repo_Y3Kjs4KvpcVPbTqUruH8wA"
PACKAGE="$REPOSITORY/example-pkg"

# Version to release, e.g., obtained with `git describe`.
version=$(git describe --always)

# Create a new version with an appropriate, locked tag. Note that we do not
# assign the `latest` tag here. There are no assets yet and we would not like
# clients/devices to pick up this new version without assets.
version_id=$( \
    nexigon-cli repositories versions create $PACKAGE --tag $version,locked \
    | jq -r '.versionId' \
)

# Now, upload and assign the assets.
asset_path="assets/example-asset"
asset_id=$( \
    nexigon-cli repositories assets upload $REPOSITORY $asset_path \
    | jq -r '.assetId' \
)
nexigon-cli repositories versions assets add $version_id $asset_id $(basename $asset_path)

# After uploading and assigning all the assets. We tag the version with the
# `latest` tag. Note that this will atomically reassign the `latest` tag thereby
# making the new version the latest version.
nexigon-cli repositories versions tag $version_id --tag latest,reassign

This script assumes that a version with the respective locked tag does not already exist. If you want to upload assets to an already existing version, you can use versions resolve to check whether the version already exists.

One way to implement a multi-stage release process is to tag the new version with testing or staging first. You can then deploy the version, e.g., to canary devices or within a staging environment, and run additional tests. Only after validating the version, you then promote the version to latest or stable.

We are using a similar script to upload and release Nexigon CLI and Nexigon Agent. The Nexigon template for Rugix Bakery contains scripts that showcase how to implement a multi-stage release workflow with CI.