Skip to main content
This guide covers how to configure the three parameterization mechanisms in Nuon: inputs, variables, and secrets.

​
Inputs

Inputs are defined in an inputs.toml file in the root of your app directory:
inputs.toml
[[group]]
name         = "dns"
description  = "DNS configuration"
display_name = "DNS"

[[input]]
name         = "root_domain"
description  = "The root domain for the install."
default      = "app.example.com"
display_name = "Root Domain"
group        = "dns"
required     = true
Use inputs in sandbox or component config:
sandbox.toml
[vars]
public_root_domain = "{{ .nuon.inputs.inputs.root_domain }}"

​
Customer-Facing Inputs

By default, inputs are vendor-facing and set through the dashboard. To allow customers to set an input directly through the install stack (CloudFormation, Bicep), mark it as user_configurable:
inputs.toml
[[input]]
name              = "sub_domain"
display_name      = "Sub Domain"
description       = "The sub domain for the service."
default           = "whoami"
user_configurable = true
Customer-facing inputs can only be modified by the customer through the install stack. Changes trigger redeployment of dependent components.

​
Input Groups

Inputs can be organized into groups to control how they are displayed in the dashboard during install creation:
inputs.toml
[[group]]
name         = "db"
description  = "Database configuration"
display_name = "Database"

[[input]]
name         = "db_password"
description  = "Password for the database."
sensitive    = true
display_name = "Password"
group        = "db"

​
Variables

Variables are managed through the CLI: 
nuon apps variables create --name=external_api_key --value=your-api-key
nuon apps variables list
nuon variables delete --id=app_variable_id
Variables are accessed in config using {{ .nuon.app.variables.<variable-name> }}.
If you add or update a variable after an install has been created, the install’s state must be refreshed before the new value is available. Running a deploy or sandbox provision triggers a state update.

​
Secrets

Secret metadata is defined in a secrets.toml file. The actual values are entered by the customer when deploying the install stack:
secrets.toml
[[secret]]
name         = "github_app_key"
display_name = "GitHub App Key"
description  = "Base64 encoded GitHub App Key"
required     = true
format       = "base64"

kubernetes_sync             = true
kubernetes_secret_namespace = "control-plane"
kubernetes_secret_name      = "github-app-key"
Setting kubernetes_sync = true syncs the secret as a Kubernetes Secret object after sandbox provisioning, using value as the key.

​
Using Secrets in Components

Secrets are referenced as outputs from the install stack:
components/database.toml
[vars]
secret_arn = "{{ .nuon.install_stack.outputs.rds_secret_arn }}"
In Helm charts, reference the synced Kubernetes secret:
deployment.yaml
env:
  - name: API_KEY
    valueFrom:
      secretKeyRef:
        name: vendor-license-key
        key: value

​
Changing Secrets

If you change a secret value outside of Nuon (e.g., directly in AWS Secrets Manager), Nuon will not detect the change. You will need to reprovision the install or manually redeploy dependent components. If secrets are configured to sync with Kubernetes, use the “sync secrets” option in the dashboard.