Nuon is designed to lift and shift your existing application and infrastructure code, so you can quickly create one or more BYOC deployable versions of your product.
What Is An App?
When you first set up Nuon, you will map your existing product into one or more Apps. An App is a fully configured version of your product that can be installed into your customer’s cloud account.How do you configure an App?
Each App is represented as multiple configuration.toml
files and collectively known as an App Config
.
Each App consists of the following parts:
Sandbox
- The base infrastructure layer e.g., AWS EKS, Azure AKSRunner
- The Nuon service that manages the installInputs
- Customer-provided input values specific to each install e.g., app release, domain nameComponents
- Your application e.g., Helm, manifests, load balancers, certificates, Terraform
Sandbox
The Sandbox is the base layer of each App and is responsible for setting up any shared infrastructure to configure an install. In most cases, Sandboxes consist of the following resources:- Basic cloud account access and controls (such as IAM on AWS)
- Basic network infrastructure (such as an AWS VPC)
- Compute infrastructure (such as a Kubernetes or ECS cluster)
Inputs
Inputs allow you to define different inputs that customers can provide to a App. This enables you to create “configuration” knobs that your customers can manage to control your application. Inputs are commonly used to:- Allow users to select regions and provide access to an account
- Customize app & infrastructure versions, such as pinning a Kubernetes cluster version
- Re-use existing infrastructure, such as providing a
vpc_id
that has been granted access
Components
Components are used to connect your existing application and infrastructure code to your Nuon App. Components allow you to:- Import existing images, or build Dockerfiles and sync these artifacts into customer accounts
- Deploy Helm charts
- Deploy Kubernetes manifests
- Deploy Terraform code
READMEs
When running an App in an Install, you often need to document important info. e.g., the app’s access URL, the install state, links to documentation. It can also be nice to have some level of programmability, such being able to render a button that will trigger an Action. Additionally, this documentation must be rendered per-Install because certain values — such as URLs — will be different for each Install. App READMEs were introduced to support this. Each App has areadme
text field where you can define a Markdown document which will be rendered in the Dashboard for each Install of that App. You can use all valid Markdown, including HTML. You can also use variables, so that the document will be custom-rendered for each Install.
See the Using READMEs guide for more details.
App Management
The CLI exposes many operational commands to manage Nuon Apps. To see all available commands, run:nuon apps --help
.
App Management Commands
Commands for creating, deleting, and viewing apps. Create a local App directory - Create a directory and name it after your App. This directory will contain your App’s configuration files.Pinning an App
You can pin an App, which will set its ID as a default argument to all app commands. This is helpful to avoid having to pass-a
to each command.
Each example below assumes you have run
nuon apps select
first.Configuration
You can view various configs for an app and sync configuration files using the CLI. Sync - Sync config files to the Nuon control and data plane Sync all config files in the current directory:The output of the following 2 sub-commands are JSON so to improve readability, use
jq
or python
App Metadata
You can add the following metadata to your application, which is used in installers:display_name
description
metadata.toml