Configuring Inputs & Secrets

Inputs

Inputs are defined in an inputs.toml file in the root of your app config 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, Azure Resource Manager (Bicep), Terraform), 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

For manually applied installs, customer-facing inputs are modified through the install stack. Changes trigger redeployment of dependent components.

AWS Cloud-Connection Stack Parameters

For AWS installs provisioned through a cloud connection, configure root and nested CloudFormation parameters directly in the Git install config. Nuon input declarations are not required:

name = "acme-production"
app_branch = "main"
cloud_connection = "acme-aws"

[cloudformation.root.parameters]
RunnerRootVolumeSize = "60"

[cloudformation.nested_stacks.VPC.parameters]
VpcCIDR = "10.42.0.0/16"

[cloudformation.nested_stacks.RunnerAutoScalingGroup.parameters]
InstanceType = "m7i.large"

[cloudformation.nested_stacks.database.parameters]
InstanceClass = "db.r7g.large"
BackupRetentionDays = "14"

Keys must be parameter names declared in the target template. Values are strings and may be literals or Nuon templates referencing state available before stack deployment, for example "{{ .nuon.inputs.inputs.instance_class }}". Root parameters are passed on stack creation and update, not embedded as defaults. Nested parameters are merged into the generated nested-stack resource and take precedence over app-configured values and automatic root/output wiring. Nested targets use the app’s custom_nested_stacks names from stack.toml, not AWS-generated physical stack names. VPC and RunnerAutoScalingGroup are reserved built-in targets. A parameter-only change retains the nested stack’s template URL, index, and other app-configured parameter values. Unknown targets and undeclared parameter names fail generation rather than being silently ignored. The cloudformation block requires an AWS cloud_connection in the install config. The connection must already exist in the organization and be verified; reference it by name or ID. This block does not configure Azure or GCP deployments. It is supported only by Git-backed install config sync. nuon installs sync rejects configs containing this block before applying any installs; commit the config to its app branch instead. Approving a new Git install config creates the install and automatically queues stack-only provisioning. Changes to an existing cloud-connected install config automatically queue stack reprovisioning. Nuon applies the managed stack; these workflows do not provision the sandbox or deploy app components. Unchanged configs do not queue another stack workflow, and retries reuse the same workflow. Omitting cloudformation.root.parameters preserves saved root overrides; an empty table clears them. Omitting cloudformation.nested_stacks preserves saved nested overrides; providing it replaces the saved nested override set, and an empty table clears that set. These are overrides over the app defaults, not replacements for app stack entries. Explicit literal empty-string values are passed through, rather than treated as missing. A template referencing an empty install input still follows normal input-default resolution; use a literal "" when you need to clear a parameter value. Literal credentials are plaintext config data, even when CloudFormation masks them with NoEcho. Prefer secret ARNs to literal credentials in Git. Passing an ARN does not import the secret automatically: the template or runtime still needs to read it, with the appropriate Secrets Manager and KMS permissions.

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"

[[secret.kubernetes_sync_targets]]
namespaces = ["api", "workers"]
name      = "github"
key       = "app-key"

Setting [[secret.kubernetes_sync_targets]] syncs the secret as a Kubernetes Secret object after sandbox provisioning, using the details provided. This approach allows for easy definition of secrets in whatever shape is desired and enables reflection of secrets across different namespaces. We support multiple [[secret.kubernetes_sync_targets]] entries. We also support the following method which is less flexible:

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"

This approach creates or upserts the secret into a secret with the secret in a value 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.

Connect Your App

Install with a Customer

Day 2 Operations

Integrations

Advanced

Inputs

Customer-Facing Inputs

AWS Cloud-Connection Stack Parameters

Input Groups

Variables

Secrets

Using Secrets in Components

Changing Secrets

​Inputs

​Customer-Facing Inputs

​AWS Cloud-Connection Stack Parameters

​Input Groups

​Variables

​Secrets

​Using Secrets in Components

​Changing Secrets

Inputs

Customer-Facing Inputs

AWS Cloud-Connection Stack Parameters

Input Groups

Variables

Secrets

Using Secrets in Components

Changing Secrets