App and Install Life Cycle

Understand the life cycle of app templates and installs in Nuon.

App templates and installs in Nuon follow a defined life cycle. You package your app template in git, and Nuon builds an artifact for each component. From that template you create one install per customer, roll updates out to them with approvals, and operate them over time.

App life cycle

Package your app

Package your app template as a set of TOML files in a git repository. These files define the app’s sandbox (for example VPC, networking and Kubernetes infrastructure), components, inputs, variables and other configuration. Components can point to your existing Terraform modules, Helm charts, Kubernetes manifests or other infrastructure-as-code. For examples, see the example app templates on GitHub.

The sandbox sets the base infrastructure each install gets: networking, permissions, and compute such as a Kubernetes cluster when your app needs one. Some sandboxes, like AWS Min, create no cluster at all. A sandbox can also reuse infrastructure the customer already has, such as an existing VPC or cluster.

Sync and build

When an app’s app branch first runs, Nuon syncs the app config to the control plane and builds each component. Each build produces an OCI artifact, which the control plane stores in a container registry such as AWS ECR.

After that, every push to the tracked git branch starts a branch run that rebuilds what changed. Some changes live outside the files Nuon watches, so a branch run can’t see them:

What changed	What rebuilds it
TOML files, or files they reference such as Helm values	The next branch run, automatically
Source in another git repository, such as a Terraform module or Helm chart	A forced rebuild
Source in your app repository whose config did not change	A forced rebuild, after you push the branch

To force a rebuild of every component, run nuon branches trigger --branch-id <branch> --force, or trigger the branch from the dashboard.

When a component’s source lives in your app repository, set its branch to the branch your branch file tracks. Each branch run then builds the component from that run’s commit. With a different branch, the component builds from the latest commit on that branch instead.

branches/main.toml

[connected_repo]
repo      = "acmeco/my-app"
directory = "."
branch    = "main"

Install life cycle

Create an install

An install is one deployment of your app template into a customer’s cloud account. It inherits the sandbox and components defined in the app template and deploys the latest build of each component.

Each install starts with the inputs your app template defines, such as API keys, cloud region, node instance size or the product release to run. Inputs are how you tailor an install to each customer. You fill them in when you create the install in the dashboard, or set them in an install config when you create installs at scale.

Deploy it

An install’s life cycle is managed by workflows. The first one, the install workflow, provisions everything in order:

The customer applies the install stack in their own cloud account, which creates the roles and starts the Nuon runner. The runner then provisions the sandbox, syncs secrets and deploys each component. Terraform, Helm and Kubernetes manifest steps pause on a plan for your approval before they apply.

Update with change controls

Because app templates live in git, an update is a push. A push to the tracked branch starts a branch run that builds what changed, then plans and deploys it across your installs one install group at a time. An update can be a new release of your product, a component upgrade or an infrastructure change such as a new Kubernetes version.

Every install group waits on a plan approval by default, so you review the diff, such as a Terraform plan or a Helm diff, before anything reaches a customer. You can auto-approve plans on an install, or let a group’s plan approve itself when every policy check passes.

Policies written in OPA Rego or Kyverno validate changes before they deploy. For example, a policy can block a new Ingress or a change to container resource requests and limits.

Operate and remediate

Once an install is running, these tools keep it healthy:

Health checks

Live health for every component, with alerts to Slack and webhooks.

Actions

Scripts that run on a schedule, around a deploy or by hand, such as checking load balancer health.

Runbooks

Multi-step procedures you run on demand, such as a restart followed by a check.

Operation roles

Scoped permissions per operation, with elevated roles the customer turns on when needed.

Actions can also remediate what monitoring finds, either automatically or when someone runs them from the dashboard. Each run records its logs step by step.

When a task needs more access than the runner normally has, use an elevated role. The role ships in the install stack disabled. The customer turns it on for the task, then turns it off again, and every use shows up in their audit logs.