Skip to main content
June 30, 2026
Toggleable components — enable or disable individual components per install

​
Toggleable components

In enterprise software, custom agreements for gating product features are common. Now you can skip deploying unneeded parts of your app to a customer.

​
App Config

Mark a component toggleable in your app config, with an optional default_enabled starting state:
components/observability.toml
name            = "observability"
type            = "helm_chart"
toggleable      = true
default_enabled = false

​
Install Config

You can manage an install’s toggled components by install.toml config files via CLI and API at PATCH /v1/installs/{install_id}, or in the browser via the Dashboard. A component’s enabled state is stored as an install input. For install.toml config-managed installs, set the state per component in a [component_toggles] section:
install.toml
name = "customer-acme"

[component_toggles]
observability = true
certificate   = false
You can also toggle a single component imperatively from the dashboard or CLI: 
nuon installs components toggle --install-id <install-id> --component-id <component> --enable
nuon installs components toggle --install-id <install-id> --component-id <component> --disable
Newly enabled components are deployed and newly disabled ones are torn down, all within one workflow. Enabling or disabling a component also runs its pre/post lifecycle actions when defined. Dependency rules, lifecycle hooks, and per-install behavior are all covered in the Toggleable Components guide — see it for the full reference.

​
Kubernetes contexts

You can now bind a component to a cluster produced by a peer component through a named Kubernetes context. Define a context that points at a terraform_module or pulumi component exposing a cluster output, then have other components opt into it by name:
metadata.toml
[[kubernetes_context]]
name      = "data-cluster"
component = "data-eks"
This decouples where a component deploys from how its cluster is provisioned, so several components can target different clusters defined elsewhere in the same app. See the Kubernetes contexts reference.

​
YAML and HCL inputs

Inputs now support yaml and hcl types in addition to string, number, list, json, and bool. Nuon validates the value’s syntax when it’s set, so a malformed Helm values block or tfvars snippet is caught at configuration time instead of mid-deploy. 
[[inputs]]
name = "helm_values"
type = "yaml"

[[inputs]]
name = "network"
type = "hcl"