Import new Version of Module

The Import New Version wizard allows you to update an existing module in the Nexus Module Store with a new Docker image version. Since modules are Docker containers, newer versions can be pulled from public registries (such as Docker Hub), your internal container registry, or the Nexus platform registry.

By importing a new version, you can keep your modules up to date with the latest features, bug fixes, and security patches. Once imported, updated versions can be rolled out to devices using the Update Center.

Step-by-Step: Import New Version Wizard

To import a new version of a Module into the Nexus Module Store, navigate to the Module Store. You can then find the module you want to update using the filtering options in the topbar. Once you have selected the Module you want to update, you can click the “+” button next to the version dropdown in the module details panel. This starts the Import New Version wizard.

Step 1 – Select Version

Choose the new Docker image version to import.

• The wizard will show all versions available in the selected repository.

• Each Docker repository can contain multiple versions (tags) of the image.

• Select the version (e.g., 2.0.0) that you want to import.

This ensures that Nexus tracks the exact release being deployed. Avoid ambiguous tags such as latest since they cannot be properly versioned in the Update Center.

Step 2a – Define Specifications (Module is stored in Platform Registry)

Provide or update the metadata that describes the new version of the module:

• Module Name & Description – Human-readable details for easier identification.

• Image Tag – Pre-filled with the repository and version selected in Step 1.

• Vendor – Define the provider of the module (e.g., your company name or third-party vendor).

• Category – The category cannot be changed for modules that have allready been imported. If you want to permanently change the capabilities of the modules, you should delete the exsisting module, then import it again.

• Logo – Upload a logo or specify a URL to visually identify the module.

• Nexus SDK – Enable this if the module has been implemented using Nexus SDK to unlock advanced monitoring and log streaming features.

Step 2b – Define Specifications (Module is stored in Public Docker Registry)

Provide or update the metadata that describes the new version of the module:

• Module Name & Description – Human-readable details for easier identification.

• Image Tag – Update the image tag, so that it points to a new version in the public docker repository,

  • Please use Image Tags that uses a specific version of the docker image. In most cases the Image tag has the following form: <repository_name>/<container_name>: <version_info>-<additional_tag> Here are some valid examples: grafana/grafana:11.4.0-ubuntu

    apache/kafka:3.9.0

    timescale/timescaledb:2.17.2-pg16

  Please avoid using any Tag that references the "latest" version of a docker module, example grafana/grafana:latest-ubuntu. The nexus platform will not be able to track the exact version being deployed to devices, and therefore a module with the latest tag cannot be updated using the Update Center.

• Vendor – Define the provider of the module (e.g., your company name or third-party vendor).

• Category – The category cannot be changed for modules that have allready been imported. If you want to permanently change the capabilities of the modules, you should delete the exsisting module, then import it again.

• Logo – Upload a logo or specify a URL to visually identify the module.

• Nexus SDK – Enable this if the module has been implemented using Nexus SDK to unlock advanced monitoring and log streaming features.

Step 3 – Configure Parameters

Nearly any application requires some sort of configuration to be able to run. This is no different to Modules or Containers. The Parameters Tab allows you to specify the Configuration required by the module, and even set default values for these settings. In Nexus Module Parameters can be provided in 2 ways:

• Twin - The configuration parameter is set in the Twin of the module, and provided at module startup as a Twin.

• Environment (Variables) - The configuration parameter is stored as an environment variable, and can be accessed by th Module or container as such.

Example of Parameters include Database connection string, activation date, link to dashboard, detection mode, etc. You can define configurable parameters by click the Add Parameter button and specifying the following properties for each parameter:

• Parameter Type – Specify the type of the parameter e.g. String, Int, Decimal, Bool, DateTime, Uri(URL), Secret, SingleSelect, MultiSelect, List.

• Name – The Name that the parameter will get in the Twin or Environment Variable.

• Display Name - User friendly name of the parameter, only used in Nexus to provide better context for users.

• Default Value - Optionally specify a default value for the Parameter. This value will be used, if the Paramter value is not changed when the module is used as an Application or by a Device Configuration.

• Parameters can be marked as Required and exposed to either Environment Variables (Env) or Digital Twin (Twin).

Step 4 – Preview & Confirm

On the last page of the Import New Version wizard, review all details before finalizing:

• Module Details – Name, description, type, category, and location (displayed as the module card in the Module Store).

• Parameters – Configurable parameters with default values (displayed as they would appear in the UI).

Once verified, click Done to finalize the import. The new version will be added to the Module Store and available for deployment.

Next Steps After Import

Once a new version has been imported:

• It will appear in the Module Store under the existing module entry.

• Older versions remain available for reference or rollback.

• The new version can be deployed to devices that uses the module using the Update Center.