Skip to main content
Config files allow you to define a BYOC application using .toml files. Under the hood, Nuon will handle keeping your configuration in sync.

Create an app

Create a local App directory - Create a directory and name it after your App. This directory will contain your App’s configuration files.
nuon
mkdir your-app
cd your-app
Config files are used to sync the configuration for a single App. The app name must be the same as the directory you created above.
nuon
nuon apps create --name=your-app

Sync an App

To sync an app, and it’s configuration run:
nuon
nuon apps sync

Breaking up Config Files

Since configs can get complex as your application grows, we follow a structured approach to organize your configuration files. Create a components directory in your project root with individual files for each component. e.g., components/helm_deploy.toml.
components/helm_deploy.toml
#:schema https://api.nuon.co/v1/general/config-schema?type=helm
name           = "whoami"
type           = "helm_chart"
chart_name     = "whoami"
namespace      = "whoami"
storage_driver = "configmap"

[public_repo]
repo      = "nuonco/demo"
directory = "eks-simple/src/components/whoami"
branch    = "main"

[[values_file]]
contents = "./whoami.yaml"
See our example-app-configs repository for common directory structures.

Reference

Input Config

Define inputs for an app using inputs.toml file. To configure a sensitive api_key and vpc_id input:
inputs.toml
#:schema https://api.nuon.co/v1/general/config-schema?type=inputs
[[input]]
name = "vpc_id"
description = "vpc_id to install application into"
default = ""
sensitive = false
display_name = "VPC ID"
type = "string"

[[input]]
name = "api_key"
description = "API key"
default = ""
sensitive = true
display_name = "API Key"
type = "string"
Inputs are not required, unless you are using a Sandbox that requires Inputs. e.g., root_domain for the aws-eks-sandbox.

Sandbox Config

Define the sandbox for an app using a [sandbox] block. To define an aws-eks-sandbox Sandbox:
sandbox.toml
#:schema https://api.nuon.co/v1/general/config-schema?type=sandbox
terraform_version = "1.11.3"

[public_repo]
directory = "."
repo      = "nuonco/aws-eks-sandbox"
branch    = "main"

[vars]
cluster_name         = "n-{{.nuon.install.id}}"
enable_nuon_dns      = "true"
public_root_domain   = "{{ .nuon.inputs.inputs.root_domain }}"
internal_root_domain = "internal.{{ .nuon.inputs.inputs.root_domain }}"

[[var_file]]
contents = "./sandbox.tfvars"
Nuon maintains managed Sandboxes for the platforms we support.
Notice how variables can be defined in the vars block and with var_file.

Component Config

You can define components by creating <component>.toml files in a components directory. Components must declare a type field and any relevant component-specific configuration.
Each component will have dependencies automatically defined based on the order in the config file. Learn more about depencencies here.

Terraform Module Component

To define a terraform module component use the terraform_module type. To configure a terraform component using a connected repo:
components/terraform.toml
#:schema https://api.nuon.co/v1/general/config-schema?type=terraform
name = "terraform"
type = "terraform_module"
terraform_version = "1.11.3"

[connected_repo]
directory = "infra"
repo = "org/repo"
branch = "main"

[env_vars]
AWS_REGION = "{{.nuon.install.sandbox.account.region}}"

[vars]
account_id = "{{.nuon.install.sandbox.account.id}}"

Helm Chart Component

To define a helm chart component use the helm_chart type. To configure a helm chart in a connected repo:
components/helm.toml
#:schema https://api.nuon.co/v1/general/config-schema?type=helm
name = "helm"
type = "helm_chart"
chart_name = "chart-name"

[connected_repo]
directory = "helm"
repo = "org/repo"
branch = "main"

[values]
"api.ingresses.public_domain" = "{{.nuon.install.sandbox.outputs.nuon_dns.public_domain.name}}"

Kubernetes Manifest Component

To define a kubernetes manifest component use the kubernetes_manifest type.
manifest-db-secret.toml
#:schema https://api.nuon.co/v1/general/config-schema?type=kubernetes-manifest

name   = "grafana_secrets"
type   = "kubernetes_manifest"
dependencies   = ["grafana_postgres"]

namespace = "grafana"
manifest = """
# Secret for Grafana's internal database connection
apiVersion: v1
kind: Secret
metadata:
  name: grafana-postgres-secret
  namespace: grafana
type: Opaque
stringData:
  GF_DATABASE_URL: "postgres://grafana:grafana@postgresql.grafana.svc.cluster.local:5432/grafana?sslmode=disable&connect_timeout=10"
"""

Docker Build Component

To define a docker build component use the docker_build type. To configure a docker build component from a private repo:
components/docker_build.toml
name = "docker_build"
type = "docker_build"

dockerfile = "Dockerfile"

[connected_repo]
directory = "deployment"
repo = "powertoolsdev/mono"
branch = "main"

Container Image Component

To define a container image component use the container_image type. To configure a public container image:
components/container_image.toml
name = "container_image"
type = "container_image"

[public]
image_url = "kennethreitz/httpbin"
tag = "latest"
To configure a container image from an ECR repo:
components/container_image_ecr.toml
name = "container_image_ecr"
type = "container_image"

[aws_ecr]
iam_role_arn = "iam_role_arn"
image_url = "ecr-url"
tag = "latest"
region = "us-west-2"

Install Config

You can create and manage Installs by creating <install>.toml files in an installs directory managed separately from the app configs. An Install config must declare a name field and any relevant install-specific configuration. The inputs are defined as a list of input groups. This is just for logical grouping, and inputs from different groups can be defined together. Note that if an input is defined multiple times, the last defined value would be used. When you generate a config, inputs will be grouped together, reflecting the input groups you have defined in the app config. Sensitive inputs will be excluded, to avoid saving them in plain text in version control. When syncing install config files, sensitive inputs will be ignored. They can still be managed manually via the Dashboard.
Currently only AWS installs are supported using Install config files.
Generate an Install Config File To manage existing installs using CI, use the CLI command nuon installs generate-config to export an existing install to stdout. Create a TOML config file for the install in the installs folder of your app’s config and paste the stout.
mkdir -p installs
touch installs/<install-name>.toml
nuon installs generate-config -i <install-name> > installs/<install-name>.toml
Update an Install The nuon installs sync command can be used with a single install config file or with a directory containing multiple install config files.
nuon installs sync -a <app-name-or-id> -d <path-to-file-or-dir>
In the dashboard, see the newly-created workflow to track the install’s upgrade process. An Example Install Config File
installs/install.toml
#:schema https://api.nuon.co/v1/general/config-schema?type=install

name = "<install-name>"

# configure Auto Approval settings for an install
approval_option = "prompt" # set this to "approve-all" to enable auto approval

[aws_account]
  region = "us-east-1"

[[inputs]]
  input_string = "sample"

[[inputs]]
  input_number = "100"
  input_bool   = "true"
  input_json   = '{"key": "value"}'
All input values should be defined as strings. They will be parsed into the correct type by Nuon.
I