Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.nuon.co/llms.txt

Use this file to discover all available pages before exploring further.

​
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, 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
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_targets]]
namespaces = ["api", "workers"]
name      = "github"
key       = "app-key"
Setting [[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 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.