Skip to main content
When you ship an app to customers through Nuon, you create one install per customer. This page covers configuring those installs, labeling them so they’re easy to identify, and monitoring their workflows once they’re running.

​
Install Configs

If you create installs at scale — for example, one per customer in an automated onboarding flow — you can generate install configs programmatically instead of authoring them by hand. Install configs are defined by a JSON Schema that lists every field, its type, and its validation rules. Feed the schema to a code generator, validator, or template engine and produce install configs from your own data. Apply a generated config with the Nuon CLI:
For the full property list, see the Install configuration reference.

​
Labeling installs

Installs support arbitrary key/value labels set via the labels field in the install config. Labels are useful for tagging installs with metadata like environment, region, or version, and they’re surfaced in the dashboard alongside the install.
install.toml
See Label badges for how labels render in install READMEs.

​
Dynamic labels

Label values can use the interpolation syntax to render from install state:
install.toml
Dynamic values are rendered when the install install state changes — deploys, input updates, and config updates all trigger a refresh. The rendered value is displayed in the dashboard and what webhook and Slack label selectors match against. If a template references state that doesn’t exist yet (for example, a component output before its first deploy), the label is skipped rather than failing the sync; it appears once the referenced state is available.

​
Default labels

Labels defined in the app’s default_labels apply to every install and are owned by the app config — an install config cannot override or remove those keys, and a sync that tries to set a different value for one fails with an error.

​
Toggling components

If your app has toggleable components, the install config decides which ones are enabled. Set the state per component in a [component_toggles] section, keyed by component name:
install.toml
See the Toggleable Components guide for how toggles reconcile on sync, dependency validation, and imperative dashboard/CLI toggles.

​
Monitoring in-progress workflows

Once an install kicks off a deploy — or any other workflow — you can monitor progress from the dashboard, via outbound webhooks, or via Slack notifications. Connect your workspace to get real-time deploy notifications — see the Slack integration guide. For programmatic integrations, webhooks deliver the same workflow lifecycle events as CloudEvents over HTTP.

​
Syncing Install Configs from Git

Instead of applying these files one command at a time, you can point your app at a Git repository that holds them. Pushes to that repo then keep every install in sync, and new files propose new installs for approval. Configure it with an installs.toml file or an [installs_config] section in your app config. See the Syncing Install Configs from Git guide for setup and usage.