Skip to content


This configuration allows the definition of shared parameters and secrets which can be used in other configurations. Parameters defined on a certain level can be used by other configurations on the same level and all children levels.

qbee parameters configuration

Parameters and secrets can be used in other configurations by use of $(parameter) placeholders.

For example: In file distribution we can use it to select a source file or populate its template parameters with shared parameter value.

Using parameters in the file distribution template


Secrets work just like parameters with the exception that they cannot be retrieved once saved and will be redacted from the logs created by the device. A device will only receive values for secrets when requesting its configuration. From the API and UI perspective, only the internal reference of the secret will be returned.

For example: Setting a secret value to "abc123" (once saved), will return the secret's reference instead of its value.

qbee secrets are not shown in the configuration

The reference is just a random value used to identify the secret in qbee internal secret storage and cannot be used to guess the value of the secret.

Secrets are immutable, therefore setting a new value for a secret, will override the existing reference with a new reference value. Saving a secret reference, will keep the underlying secret value unchanged.

Extending parameters configuration

Parameters defined on a parent level can be overridden.

For example: Let's say that we have defined the following parameters on the "All devices" level:

  • brand="My Brand"
  • db-user="dbUser"

And decided that we need to change the branding only for devices under group_A. We would achieve that by setting only "brand" parameter to a new value - "Custom Brand". The result would be, that devices under group_A would now get the following parameters:

  • brand="Custom Brand"
  • db-user="dbUser"

Device resolved parameters (system parameters)

As of agent version 2024.05, the qbee agent can make use of locally resolved parameters for ease of defining configuration. Eg. if you have a fleet of devices where you want to install a certain package, but the system architecture differs, you could refer to package files throught their Package Manager defined architecture (ie. instead of my-software_1.0.0_amd64.deb you could use my-software_1.0.0_$(sys.pkg_arch).deb). This would allow you to set up the same configuration across system architectures.

Parameters vs. system parameters

Locally resolved system parameters are not set in the "Parameters" section, but rather used directly in the other configuration sections (eg. File Distribution, Software Management etc).

The currently supported system parameters are:


The system hostname


The package architecture as reported by the package manager of the system, eg. amd64


The package type for the system, eg. deb or rpm


The operating system of as reported by uname -s


The architecture of the system as reported by the kernel (uname -m)


Canonified version of kernel name and machine. Essentially the canonified output of uname -sm.


A canonified label indicating the system distribution, eg. ubuntu_20


The current qbee agent version


Full kernel version identifier. Essentially a canonified version of uname -a


The boot time of the system in Unix epoch

Example of how they are resolved locally: