Module Settings

The Module Settings page allows you to fine-tune the configuration of an imported module. Unlike the Import Wizard, which is a guided step-by-step flow, the Module Settings open in a dedicated settings window with multiple tabs for adjusting technical details of the selected module.

It’s important to note that any changes made here apply only to the currently selected version of the module. When you later import a new version of the same module, Nexus will automatically carry over these settings to the new version, ensuring continuity in configuration.

Key Capabilities

• Version-specific configuration – Settings apply per module version, but are reused automatically when importing new versions.

• Container-level control – Configure how the Docker container behind the module behaves, including networking, mounts, and environment variables.

• Parameter mapping – Define runtime parameters, and expose them either as environment variables or as part of the digital twin.

• Structured overview – Tabs organize all configuration options for easy navigation.

Module Settings Window

To edit the settings for a module, you can either select the Module and a specific version in the Module Store or Edit the Module settings from an Application. Settings apply per module version, but are reused automatically when importing new versions of the Module.

Specification

• Update metadata such as vendor, description, logo.

• Toggle Nexus SDK integration if the module supports advanced monitoring features such as log streaming.

Create Options

This is one of the most important configuration tab. The Create Options Tab, lets you control resource access for the module, such as defining ports that should be opened for the module (Eg. to host a webpage) or enable file storage (also known as mounts) to allow the module to read or write files on the disk of the Edge device.

• Define open ports for the container, e.g. enabling external access to an application running inside the module.

• Configure mounts to give the module access to file system paths on the host device. This can be used for:

  • Reading configuration files.

  • Storing log or database files.

  • Accessing persistent data volumes across container restarts.

• Add additional Docker runtime options following IoT Edge and Docker container standards.

Routes

In the Routes tab, you can define how data can flow between modules and between modules and the cloud. In the example screenshot above, you can see that the (Source) MqttClientModule is allowed to write output messages to a queue called streaminglogs. The reader (Destination) of these messages are the DataDistributionModule which reads all module logs from its streaminglogs input queue. Therefore a relationship is established, where the MqttClientModule sends its logs to the DataDistributionModule which is responsible for streaming these logs to the cloud.

• Define message routes between modules using Source → Destination mappings.

• Configure priority and time-to-live for messages.

• Routes are essential for directing how data flows between Nexus modules.

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.

In the example screenshot above the timezone for NodeRED is set as an Environment Variable in a Parameter (TZ = Europe/Copenhagen). Other examples of Parameters include Database connection string, activation dates, link to dashboards, detection modes, 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).

Desired Twin (read only)

The Desired Twin Tab shows a read only Json formatted version of all Parameters exposed as Twin values. The Twin will be pushed to the Module when it starts up, or if any value changes in the Twin.

• Displays a JSON representation of all parameters exposed as Twin values.

• Useful for integration with the IoT Edge Twin model, where modules synchronize configuration with the cloud.

Environment (read only)

The Environment Tab shows a read only Json formatted version of all Parameters exposed as Environment Variables. The Environment Variables are made available to the Module/Docker container, and can be read using many programming languages.

• Displays a JSON representation of all parameters exposed as Environment variables.

• Parameters marked as “Env” will appear here.

• Useful for modules that read environment variables at runtime (e.g., DB connection strings, API keys).

Best Practices

• Always prefer explicit version tags for Docker images (avoid latest). This ensures version tracking works with Update Center.

• Use Mounts for persistent or shared storage needs.

• Store sensitive information (passwords, tokens) as Secrets in parameters for secure handling.

• Document your custom settings for easier troubleshooting and updates.