Application Workloads

This guide explains how to manage application workloads on devices using Nexigon. Unlike system updates which replace the entire OS image, application workloads are individual applications that run on top of the base system and can be deployed, started, stopped, and rolled back independently.

Rugix Apps

For devices running Rugix, we provide a ready-made recipe that installs device commands for managing Rugix Apps — individual application workloads that run alongside the base system.

For Rugix Bakery, the recipe is available in the nexigon-rugix repository. For Yocto, the meta-nexigon-rugix layer in meta-nexigon provides the equivalent.

The recipe adds the Nexigon commands. The image must also include a configured Rugix Apps runtime, such as Docker and Docker Compose. Nexigon OS includes this runtime by default.

The recipe installs the following device commands:

When these commands are available on a device, the Nexigon UI shows an Applications tab on the device details page with a live view of installed apps, their status, and action buttons.

For fleet-wide application workflows, you can use Operations with device command steps. For example, an operation can deploy an app to a canary ring, wait for devices to report the expected app state, and then advance to a larger rollout ring.

Deploying Applications

To deploy an application from a Nexigon repository:

1. Upload a Rugix App bundle (.rugixb) to a package version in your repository
2. In the Nexigon UI, open the device’s Applications tab and click Deploy Application
3. Select the package and version to deploy

The deploy dialog walks through package selection, version selection, and shows live deployment logs. The underlying command (nexigon.rugix-apps.deploy) can also be invoked programmatically via the API.

For hash-verified deployment, attach the bundle hash to the asset metadata in the package version:

{
  "rugix": {
    "bundleHash": "sha512-256:..."
  }
}

Then enable metadata hashes in the Bakery layer:

[parameters."nexigon/nexigon-rugix-apps"]
use_bundle_hash = "true"

With this option, the deploy command passes metadata.rugix.bundleHash to Rugix Ctrl when the metadata is present. If it is absent, the command omits the hash argument and Rugix Ctrl performs its normal signature verification. The option defaults to false for compatibility with existing images. Nexigon OS enables it by default.

Hash verification checks that the downloaded bundle matches the metadata received over the authenticated Nexigon connection. It does not replace an independent publisher signature; use Rugix bundle signing for production trust once a signing trust root is configured.

Application Lifecycle

Applications have their own lifecycle managed by Rugix’s orchestrator:

• Running — the application is active
• Stopped — the application is installed but not running
• Failed — the application encountered an error

You can start, stop, rollback, and remove applications directly from the UI or via device commands.

Custom Application Updates

For non-Rugix application workloads, you can use Nexigon repositories as an artifact store and build your own update mechanism. The general approach:

1. Upload application artifacts (binaries, containers, configs) to a package version
2. Tag the version to control rollout (e.g., latest, stable, canary)
3. Poll from the device using nexigon-agent repositories issue-url to get download URLs
4. Install the artifacts using your own tooling

You can implement this as a shell script, a systemd timer, or a custom service. The Nexigon repository API provides version resolution, asset download URLs, and metadata — how you install the artifacts is up to you.