Skip to main content
Noxus renders configuration forms for you from typed schemas — no frontend code. There are three levels of configuration, all built with the NCL config language (Parameter + display= widgets) from noxus_sdk.ncl:
  • Plugin-level config — settings that belong to the whole plugin.
  • Node config — per-node settings, including bindable inputs.
  • Dynamic config — config computed server-side at edit time.

Plugin-level configuration

Plugin config lives on a PluginConfiguration subclass, which you pass as the type parameter of BasePlugin[...]. Its fields are Parameter(...) — the same NCL widgets you use everywhere.
Override validate_config to gate the install. When a plugin declares config, the platform calls validate_config before moving the plugin to running — if it returns valid=False, or if config was never set, the plugin sits in missing_config until an admin provides a valid configuration.

Reading plugin config in a node

Plugin config is delivered to every call on the execution context as ctx.plugin_config (a dict of the saved values):

Node configuration with NCL

Node config is a NodeConfiguration subclass; each field is a Parameter(...) with an optional display= widget. Values round-trip to the worker and reach the node as self.config.
Common widgets from noxus_sdk.ncl: Fields without a display still render with a default widget for their type.

Conditional visibility with VisibleIf

Show or hide a field based on another field’s value with a VisibleIf rule (noxus_sdk.ncl) — evaluated in the form as the user edits, no round-trip:

Bindable inputs (V2 nodes)

On a V2 node, mark a config field Parameter(bindable=True) to make it a bindable input — in the editor it accepts a literal or a :var[...] reference to an upstream output. It still arrives on self.config. See the overview for the full V2 node shape.

Dynamic configuration (get_config)

To compute config server-side at edit time — e.g. fetch select options from an upstream API, or toggle field/connector visibility based on other values — override get_config. It runs in the worker; mutate the response and return it.
The response exposes config (the serialized fields), config_values (the saved values), and — for V1 nodes — inputs/outputs you can flip visible on. The platform only wakes the worker for this when a ConfigSelect has no static values, so static nodes never pay the round-trip.

Runtime Safety

  • Validate at the boundary. Use validate_config on plugin config and NodeConfiguration field types to reject bad input before it reaches your code.
  • Sanitize before external calls. Never interpolate raw config strings into shell commands, URLs, or queries unchecked.
  • Mask secrets. Any credential-like field must use ConfigPassword so it is hidden in the form. For true integration secrets, prefer an integration credential over a config field.

Publishing & Versioning

Package, version, and roll out configuration changes safely.