Frequently Asked Questions

After the initial install of app in a customer cloud account, the customer can scale the ASG to 0 which shutdowns the EC2 VM and the runner. This prevents any egress connectivity from the customer VPC

The customer can temporarily scale the ASG to 1 to enable outbound access for provisioning and updates.

Nuon currently only support GitHub.

If you have a requirement for GitLab or Bitbucket, please let us know.

No, the runner is outside of the installed app but still in the customer's cloud account.

By default, the runner is part of an Auto Scaling Group (ASG) and EC2 VM created by a CloudFormation stack that is generated by the Nuon control plane. The software vendor shares the stack with their customer who deploys it in their cloud account.

The stack creates a Runner Management Mode (mng) systemd service that orchestrates and manages the runner container within a docker systemd service.

The mng daemon is responsible for fetching the install runner image version from the Nuon control plane and overseeing the lifecycle of the runner process.

Unlike traditional cloud-agnostic solutions like Terraform, Nuon is purpose-built to enable software vendors to offer their software in customer clouds.

While Terraform is a tool for provisioning infrastructure, Nuon is a platform for distributing software.

• Scope: Terraform manages raw infrastructure resources (VPC, RDS, S3); Nuon manages the entire Application Lifecycle (Infra + Code + Config) as a single unit across many disparate environments.

• State Management: Terraform uses a single state file per environment that requires manual locking/concurrency handling; Nuon uses Workflows to manage state, allowing for complex dependencies and cross-environment rollouts.

• Permissions: Terraform requires high-privilege credentials (IAM/Service Accounts) to push changes; Nuon uses a "Pull-based" Runner architecture, which is significantly easier for your customers’ security teams to approve.

• Directionality: Terraform is a "Push" tool (you run it from a central CI/CD); Nuon is a "Control Plane" that orchestrates "Installations" in remote accounts that you do not own.

• Durable Execution: Unlike Terraform's "fire-and-forget" scripts that fail on transient errors, Nuon's Temporal-backed engine ensures deployments are natively resumable and persistent until completion.

Nuon integrates with external infrastructure resources such as AWS Route 53, Azure DNS, and third-party networking solutions.

The runner is governed by a Runner Management Mode (mng) systemd service in the ASG EC2 VM that orchestrates and manages the runner container within a docker systemd service.

The mng daemon is responsible for fetching the install runner image version from the Nuon control plane and overseeing the lifecycle of the runner process including changing its version and restarting it.

When a new release of the Nuon control plane is deployed, the runners are updated as well.

Roles & Permissions

The runner uses different IAM roles for different jobs like provision, de-provision, maintenance and break glass for emergency repair.

• Provision and de-provision roles require the highest permissions since they create and destroy cloud resources.

• The maintenance role can be less permissive since they update specific components or run actions (scripts).

The software vendor defines these roles as part of the app configuration — so the roles and permissions are not defined by Nuon.

Break glass roles are enabled in CloudFormation by the customer and can be referenced in your action (scripts) configurations. These roles provide temporary elevated access to the software vendor for emergency situations or critical deployments.

Shutdown the Runner

The customer can also scale the ASG to 0, which shuts down the EC2 VM with runner preventing the vendor from running any jobs on the customer install. When maintenance is needed, the customer can scale up the ASG.

The runner is governed by a Runner Management Mode (mng) systemd service in the ASG EC2 VM that orchestrates and manages the runner container within a docker systemd service.

The mng daemon is responsible for fetching the install runner image version from the Nuon control plane and overseeing the lifecycle of the runner process including changing its version and restarting it.

Nuon uses two types of runners to execute different phases of deployment: build runners (org runners) and install runners.

Build Runner (Org Runner)

The build runner executes build operations for your application components. It's status is visible as an icon in the left navigation bar of the dashboard home.

Key Characteristics:

• One per organization - Shared across all apps and installs in your org

• Runs in the Nuon's control plane

What it does:

• Builds container images (OCI artifacts) from the components' source code

• Executes Docker builds

• Runs Terraform/Helm packaging operations

• Creates component releases

• Stores build artifacts in the org's container registry — to be used by customer installs

Example: If you change a component's TOML and run nuon apps sync, the build runner in your org executes the build job and creates a new container image for the component and stores it in the org's container registry.

Install Runner

The install runner deploys (installs) your application into customer cloud infrastructure. It's status is visible as an icon in the left navigation bar of the install page of the dashboard.

Key Characteristics:

• One per install - Each customer cloud install has its own runner

• Runs in the customer's cloud infrastructure (customer's AWS/Azure account

What it does:

• Deploys Helm charts to customer Kubernetes clusters

• Applies Terraform to customer cloud accounts

• Manages Kubernetes manifests

• Syncs secrets to customer namespaces

• Executes action scripts like health checks

• Manages Day-2 operations (updates, rollbacks)

Example: When a customer provisions an install, an install runner is deployed into their VPC in an ASG EC2 VM to handle all deployment operations.

How They Work Together

Build Phase: Build runner (org) compiles your code and creates release artifacts

Deploy Phase: Install runner (customer) deploys those artifacts into customer infrastructure

This separation ensures:

• Build artifacts are created once, deployed many times

• Customer credentials never leave their infrastructure

• Each customer install is isolated

• Builds can be shared across multiple customer installs

Cloud providers have infrastructure as code offerings to deploy any cloud-native app, but do not focus on day-2 operations and do not support other clouds like Nuon.

Yes, Nuon automates both infrastructure provisioning and application deployment. This includes managing Kubernetes clusters, networking policies, and runtime configurations.

We have software vendor customers who use Nuon for their single-tenant SaaS offering as well as BYOC in customer clouds.

Nuon has not been approached to power a multi-tenant SaaS offering yet.

Yes, we have an Azure sandbox.

https://github.com/nuonco/azure-aks-sandbox

A sandbox is Nuon-developed Terraform that creates and destroys infrastructure than your app run ons. Kubernetes is the most common type of sandbox but we also have a minimum sandbox without Kubernetes that can be used along with components to provision other infrastructure like AWS ECS, serverless, and VMs.

This is a new feature and is changing rapidly. Please check back for more information.

Yes, we have a Google Cloud sandbox.

https://github.com/nuonco/gcp-gke-sandbox

A sandbox is Nuon-developed Terraform that creates and destroys infrastructure than your app run ons. Kubernetes is the most common type of sandbox but we also have a minimum sandbox without Kubernetes that can be used along with components to provision other infrastructure like AWS ECS, serverless, and VMs.

We also have a sample Nuon app config for Google Kubernetes Engine (GKE).

https://github.com/nuonco/example-app-configs/tree/main/gke-simple

Kuberenetes is a not requirement for your app.

The Nuon configuration for your app's underlying infrastructure is called a sandbox.

The sandbox is Terraform to deploy whatever infrastructure your app needs.

All sandboxes set up cloud resources expected and required by the Nuon control plane including:

• A container registry e.g., AWS ECR

• IAM policy for registry access and IAM policy attachments for the provision, maintenance, and de-provision roles for the runner to create and destroy cloud resources

• DNS resources including a private and optional public hosted zone

Nuon maintains Kubernetes sandboxes for AWS EKS and Azure AKS and a minimum sandbox without Kubernetes, where you can define one or more Nuon TOML components for any other infrastructure your app requires. e.g., AWS EC2 VM, AWS ECS, S3, serverless, etc.

Currently, we do not support Pulumi.

However, depending on your infrastructure needs, this might not be that important because in the Nuon model, we provide much of the base infrastructure for your application.

All that is needed at the IAC layer is your app infrastructure not the whole VPC, compute clusters and other larger parts of an IAC presence. This is because we provide pre-built Terraform-based sandboxes and app components for the common cases that are production hardened for customer installs.

We do not see much demand for Pulumi, but you could support it today via actions (scripts) for day-1, but would not have as nice of an experience as we provide with Terraform directly.

If your secrets are accessible from an API-endpoint, you can create a Nuon Action script to retrieve the secret's values and use jq and the AWS CLI to write them to AWS Secrets Manager. Afterwards, the secret is available for use by other actions and components.

Requirements:

• Retain permissions in the Runner maintenance role that allow you to create secrets (example).

• Retain permissions to retrieve AWS SM secrets, typically scoped to an install by tags org naming convention (see example above).

• The values you want to store are accessible to the runner over the network: typically this means an API endpoint, which is the case in this example.

If in your case, you can fulfill these requirements, then you can write a nuon action that reads the values and writes them to secrets manager in the same account as the install. Typically, the action outputs would contain the ARN (aws cli output) which you can then use in other actions or components. Nuon action lifecycle triggers are a useful feature for controlling when this action runs (e.g. after a sandbox provisions or before a component is deployed).

An example flow:

1. Before the sandbox is provisioned, run an action to create or update a secret with a value from the api. e.g. an action hits acme.example.org/v1/license?install_id={{.nuon.install.id}}. and stores the value in secrets manager in a secret named /{{.nuon.install.id}}/license-key.

2. An action runs before the helm deployment that requires the license key and upserts it into a secret.

3. The helm deployment can then refer to the license key (e.g. existingSecret or envFrom w/ a secretRef)

Short answer: No

Permissions

With Nuon, the software vendor does not have direct access (e.g., cross account permissions) to the customer account. Instead, the customer deploys a CloudFormation stack that creates a ASG EC2 VM and a runner service in a container.

The runner uses different IAM roles for different jobs like provision, de-provision, maintenance and break glass for emergency repair.

• Provision and de-provision roles require the highest permissions since they create and destroy cloud resources.

• The maintenance role can be less permissive since they update specific components or run actions (scripts).

The software vendor defines these roles as part of the app configuration so they are defined by Nuon.

Break glass roles are enabled in CloudFormation by the customer and can be referenced in your action (scripts) configurations. These roles provide temporary elevated access to the software vendor for emergency situations or critical deployments.

Shutdown the Runner

The customer can also scale the ASG to 0, which shuts down the EC2 VM with runner preventing the vendor from running any jobs on the customer install. When maintenance is needed, the customer can scale up the ASG.

An install is initiated by the vendor through the dashboard or CLI.

Inputs

The vendor enters inputs, which are variable parameters the vendor and/or the customer entered when initiating an instance.

Example inputs are machine type, app release version number, license key, domain, VPC id, Kubernetes cluster name, LLM model, vendor role ARN, etc.

Inputs designated in app config as customer-facing, are not created or seen by the vendor. Instead, they are entered by the customer as part of the CloudFormation stack when deployed in the customer cloud account.

Install Lifecycle

After the vendor enters inputs, Nuon generates a CloudFormation slack, which they share with the customer.

When the customer deploys the CloudFormation stack, the VPC, subnets, IAM roles, ASG EC2 VM and Nuon runner are created. The runner phones home to the Nuon control plane and executes the job steps to create resources as defined in the app configuration.

There is one runner for each customer install of an app.

You do not create a new install, but rather:

• Ensure the changed component is re-built, either with nuon apps sync or in the dashboard

• Navigate to the component page of the install and redeploy with the latest build

• Be sure to check the box for dependencies so the workflow progresses through the completion of the install

When iterating on a new app, you’ll get one install with the sandbox spun up, and then keep pushing updates to the same install until your changes do what is expected.

Workflows orchestrate the entire lifecycle of customer installs - from provisioning infrastructure, to deploying components, to running operational tasks, to tearing everything down. They coordinate operations across the control plane and customer environments using Temporal for reliability.

An install is an instance of your app in a customer cloud account.

Installs are dynamic to each customer by way of inputs, which are variable parameters the vendor and/or the customer entered when initiating an instance.

Example inputs are machine type, app release version number, license key, domain, VPC id, Kubernetes cluster name, LLM model, vendor role ARN, etc.

You need to reprovision a customer install when you change any of the following in your app:

• stack.toml

• runner.toml

• permissions directory's contents

Reprovisioning is not required if you change components or actions, in which case use the CLI and run nuon apps sync and re-deploy the component or re-try the action. Components, unlike actions which are scripts stored in the Nuon database, do require a build before deploying, and builds are done automatically when component TOML is changed, or manually in the app dashboard to create the new OCI artifact that is required for deployment.

You need to reprovision a customer install's sandbox when you change anything in the sandbox.toml

• Variables including templated from inputs e.g.., Kubernetes version

• The git repository or branch of the sandbox

Reprovision sandbox is a menu item in the Manage drop-down in the Sandbox section of your install in the dashboard.

This is normal operating behavior.

De-provisioning destroys the app's components and sandbox (e.g., Kubernetes) but not the runner.

The runner is created and destroyed by the CloudFormation stack. Delete the stack and the resources it creates will be deleted. e.g., VPC, subnets, IAM roles, and ASG EC2 VM.

You probably have another workflow running. Workflows are currently single-threaded by design, to prevent collision.

Go into the install's workflow view in the dashboard, and cancel the other workflow that is still executing.

In this example, a Helm deployment has a pod in CrashLoopBackoff status, so after fixing the component and attempting to redeploy, it is pending until you cancel the failing component.

Components do have timeouts so eventual this would have failed, allowing the next workflow to execute.

Yes.

The vendor can share the Rego and Kyverno policies included in the app config that is used to install in the customer's VPC.

Alternatively, if the app config is configured to use the customer's existing VPC or Kubernetes cluster, their existing policy engine and policies will be applied to the app install.

Yes, Nuon integrates with Kyverno and Open Policy Agent (OPA) to enforce identity-based security policies across all deployed environments. Customers can define access restrictions, compliance rules, and resource limits dynamically.

The policies defined in the app are cloud-agnostic.

The Kyverno policies are defined in the policies.toml and policies sub directory at the root of your app configuration.

# policies

[[policy]]
type     = "kubernetes_cluster"
contents = "./disallow-ingress-nginx-custom-snippets.yaml"

Yes, Nuon works within customer-defined firewall policies, including private subnets and VPN-based access controls.

The Nuon runner also only has egress-only access to the Nuon control plane so no ports need to be opened for Nuon to operate.

Split plane scenarios like AI, observability, and database apps can include VPNs like Tailscale for private connectivity between the vendor-hosted control plane and the customer-hosted data plane.

Yes, customers of software vendors using Nuon to install their apps into customer cloud accounts, own and control the IAM roles that grant access.

The customer creates these roles when deploying the CloudFormation stack provided by the software vendor - and the roles are granted to the Nuon runner inside the customer cloud VPC.

The customer can scale down the ASG EC2 VM to turn off the runner and prevent access to the customer's cloud by the Nuon control plane.

Nuon operates under a least-privilege model, ensuring no unnecessary permissions are granted.

Yes, Nuon supports OpenID Connect (OIDC) integration, allowing customers to use their existing identity providers for authentication and access control to the Nuon control plane.

Nuon Cloud, our SaaS offering, uses Auth0 as the Identity Provider (IdP).

Nuon BYOC, our Nuon-managed, vendor-hosted offering, supports any OIDC provider. e.g., Okta, Auth0.

Vendor apps deployed by Nuon into customer cloud accounts can continue to use whatever authentication and access control they require.

Yes, Nuon supports hybrid deployment models, allowing organizations to run part of their workloads in their cloud or on-premises environments while connecting securely to customer's cloud-hosted components.

This is useful for regulated industries requiring local data processing while leveraging cloud scalability.

Common use cases are AI, database, observability, or analytics apps where the customer wants to host the data plane but wants the vendor to host the control plane.

Here is an example app configuration that separates ClickHouse's control and data planes, with the data plane installed in a customer cloud.

The runner does not use cross-account permissions. Instead, IAM roles are defined in the vendor's app configuration.

When the vendor initiates a customer install, the Nuon control plane generates a CloudFormation stack which the customer deploys into their cloud which creates a VPC, subnets and grants the IAM roles and permissions to the runner and not directly with the vendor.

Vendors can however implement cross-account access by defining a component that performs role delegation to a user in the vendor's cloud account.

In the app's config, secret names and metadata (not the actual secrets) are added to the secrets.toml as part of the app configuration.

name          = "cockroachdb_admin_pw"
display_name  = "CockroachDB Admin PW"
description   = "Password for the default cockroachdb admin user. This password is used to access the cluster admin."

kubernetes_sync             = true
kubernetes_secret_namespace = "cockroach"
kubernetes_secret_name      = "admin-pw"

When the customer deploys the CloudFormation stack sent by the vendor, the customer is prompted to enter values for the secrets specified in secrets.toml, which are then stored in AWS Secrets Manager.

If kubernetes_sync is set to true, Nuon has an additional workflow step to sync that secret to a specific Kubernetes namespace with the deployed app. This workflow step is run after the provisioning of a Kubernetes sandbox and uses the key of value when creating the Kubernetes secret.

You can reference secrets in components and actions using templating.

In Helm where the secret is synced to a Kubernetes namespace

# Helm values.yaml
...
service:
  port: 80
  targetPort: 3000

secrets:
  botTokenSecret: bot-user-oauth-token

# Helm template

apiVersion: apps/v1
kind: Deployment
...
      containers:
        - name: slack-app
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          ports:
            - containerPort: {{ .Values.deployment.containerPort }}
          env:
            - name: SLACK_BOT_TOKEN
              valueFrom:
                secretKeyRef:
                  name: {{ .Values.secrets.botTokenSecret }}
                  key: value

In a Terraform component where the secret is pulled from AWS Secrets Manager

# terraform
name              = "open_webui"
type              = "terraform_module"
terraform_version = "1.13.5"

...

[vars]
...
openai_secret_arn = "{{ .nuon.install_stack.outputs.openai_api_key_arn }}"

Nuon is a platform, with configurations at the control plane and your app-level, to make it secure and trustworthy for your customers.

Secrets and sensitive values are entered by the customer and stored in AWS Secrets Manager, and never accessible by you (the vendor) and only accessed by the Nuon runner which is isolated in the customer's VPC.

Nuon actions — scripts that the runner executes in the customer VPC — are logged by Nuon, so the maintenance and break-glass IAM roles defined in the app configuration must be scoped properly to prevent accessing resources that they should not have access to.

Nuon's control plane does not have to run in Nuon's cloud. Nuon BYOC is our offering where Nuon's product deploys Nuon's control plane in the vendor's cloud account. This allows their customers to only have to trust and verify the vendor's cloud and not another cloud like Nuon.

See this docs link for more information about Nuon security & trust.

While Nuon does not generate SBOMs, our policy engine can detect and enforce SBOM.

e.g., Policy examples vendors using Nuon can enforce:

• "Require all images to have an SBOM before deployment into customer VPC"

• "Only allow CycloneDX format SBOMs"

• "Block deployment entirely if no SBOM is present"

You the vendor would need to come up with SBOM yourselves for each individual image component and Nuon can help your customers verify with policies. This can be particularly important due to the executive order in US  & upcoming regulations in EU with CRA.

Yes, you can use any terminal-based AI agent to learn from other Nuon example app configs, sandboxes, Nuon's docs, and Nuon's OSS repo — to quickly build TOML files that comprise a Nuon app configuration.

See our docs for more information about our AGENTS.md and CLAUDE.md files in our example apps repo.

The cloud is defined in the sandbox so you would define an app for each cloud.

In the app configuration, you specify the sandbox in the sandbox.toml

# sandbox

terraform_version = "1.11.3"

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

Nuon provides AWS and Azure sandboxes in our GitHub nuonco.

You create the app with the CLI.

nuon apps create -n <app name>

You should make the app name the same as the directory name which is required for the subsequent nuon apps sync step.

If there are no installs based on an app, you can delete it and its components and actions with the CLI.

nuon apps delete -a <app name> --confirm

It will take several seconds as it also deletes the components first, so refresh the dashboard UI or nuon apps list.

For new trial users or in development environments where you are iterating on an app, there is a handy command to clean up your Nuon org.

You sync the app with the CLI. You must first create the app with CLI as well.

nuon apps sync

You must be in the directory of your app and the directory name must match the app name.

Update the TOML files of your local app.

You then update the app with the CLI.

nuon apps sync

You must be in the app directory and it must be the same name as your app in the Nuon control plane.

Syncing an app performs validation of the syntax of the app's TOML files.

The Nuon control plane creates builds for each component. A build creates an OCI artifact that is stored in the Nuon org's container registry like AWS ECR.

The artifacts are used by Nuon to provision and update an install in the customer's cloud.

If you update the app's configuration, you must run nuon apps sync to trigger a re-build of any changed components.

Nuon automatically detects and re-builds components if their TOML files or referenced files like Helm values change.

However, you must manually rebuild in the dashboard (or with the CLI) when:

• Git repository source code changes (e.g., Terraform modules or Helm charts)

• Source code in your app repository changes (push your branch first, then rebuild)

You may have incorrect templating/interpolation when referencing outputs from a component. In particular, be sure outputs is part of the templating.

# correct
cluster_arn             = "{{ .nuon.components.cluster.outputs.cluster_arn }}"

# incorrect
cluster_arn             = "{{ .nuon.components.cluster.cluster_arn }}"

You probably built a Nuon app from scratch, and are missing the permissions directory with the TOML files defining the runner's IAM roles and permissions.

deprovision.toml
deprovision_boundary.json
maintenance.toml
maintenance_boundary.json
maintenance_policy.json
provision.toml
provision_boundary.json

Copy the permissions directory from one of Nuon's sample apps.

Nuon provides these IAM roles as examples and you and your customers should define the required permissions for your app. In general, provision and deprovision need the highest permissions to create and destroy cloud resources. Maintenance and break glass roles can be scoped accordingly.

Nuon has a beta customer dashboard where customers click vendor-initiated install links that prompt for any customer facing inputs.

Contact sales if you are interested in this beta feature.

Besides bundling your observability product of choice into your Nuon app config, you can use Nuon action scripts to execute commands in the customer's VPC.

Logs are returned and stored in the Nuon data plane.

Software vendors can have Nuon deploy the Nuon control and data planes into their cloud account so no log data is stored in Nuon's cloud.

Yes, Nuon collects infrastructure logs for an install's sandbox, components and actions.

The vendor can view these logs in the dashboard.

Be default, Nuon does not collect application-level logs from the vendor's app.

If you use action scripts to debug and troubleshoot, e.g., kubectl or psql, log results will be stored in Nuon along with infrastructure logs. You can scope the permissions of the Maintenance IAM role to prevent what resources the vendor can debug or touch.

Nuon uses Go templating, so add the component output into the other component or action.

Below is a health check action TOML file with an environment variable called ENDPOINT that takes the EC2 component's public_ip output variable as a default value.

[steps.env_vars]
ENDPOINT = "{{.nuon.components.ec2.outputs.public_ip}}"

Here is the ec2 component's Terraform outputs.tf with the public_ip

output "public_ip" {
  value = module.ec2_instance.public_ip
}

There are open standards like VEX (Vulnerability Exploitability Exchange)  that you as the vendor can use so scanners ignore them. Almost all scanners these days are aware of it.

All you would need to do is attach a VEX document alongside your OCI artifact for scanners to ignore it.

If a vendor's customers are ok with it, the vendor can include an observability tool's agent as a component in the app configuration — to monitor the vendor's app. Example observability tools include Datadog, Grafana, Honeycomb, SolarWinds.

The agent then sends logs and metrics to the observability provider's cloud.

The runner frequently sends its status to the Nuon control plane.

When you nuon apps sync, the new component  will be built. But yes, you will need to deploy it and any dependents to each install.

The software vendor's customer needs to white label the IP addresses of the Nuon control plane and the observability vendor's cloud.

The runner assumes the maintenance role when executing action scripts to troubleshoot and debug.

Vendors can define a break glass role with additional permissions than the maintenance role — to execute more expansive action scripts.

These roles are granted by the customer through the Stack and can be revoked at any time.

Yes, we use Nuon to install the Nuon control plane in a software vendor's cloud. The software vendor must be a qualified prospect or a customer with a paid license.

This offering is called Nuon BYOC.

At the moment, no. We have a roadmap item to remove AWS dependencies from our control plane and documented Helm charts to install the Nuon infrastructure.

Presently, Nuon can only install the Nuon control plane into a software vendor's AWS cloud. This offering is called Nuon BYOC.

So Nuon-managed, self-hosted.

The software vendor could scale down the AWS ASG VM once the Nuon runner has completed the install of the Nuon control plane, so air-gapped after the install.

The software vendor could scale up the ASG VM to let the runner upgrade Nuon on occasion.

Presently, Nuon can only install the Nuon control plane into a software vendor's AWS cloud. This offering is called Nuon BYOC.

So Nuon-managed, self-hosted.

We have a roadmap item to remove AWS dependencies from our control plane and documented Helm charts to install the Nuon infrastructure.

No. Nuon's control plane can currently only deploy into AWS, Azure, and Google Cloud.

Customer installs done by Nuon can also only deploy into AWS, Azure, and Google Cloud, and not on-premises.

Yes, our SaaS offering is called Nuon Cloud.

Sign up for a free trial here.

No, Nuon will not have full access to a production Nuon BYOC instance.

For some customers, they deploy a dev instance of Nuon BYOC and give Nuon more access, in particular, as users in their org instance, for easier troubleshooting.

Yes, by default, database (PostgreSQL) encryption is on.

Yes, Nuon is open source with an AGPL-30 license.

The GitHub repository is here.

Nuon was developed several years ago, but recently open-sourced in December 2025.

We are currently working on removing AWS dependencies so that Nuon can be self-hosted or run in a fully air-gapped environment.

Startups often Nuon Cloud because they have very few customers and do not want to incur the cloud expense, since Nuon is a beefy stack including Temporal, RDS, and ClickHouse.

Nuon BYOC is where Nuon deploys the Nuon control and data plane into your AWS cloud account.

Established vendors like Nuon BYOC because they control Nuon in their AWS and do not have to rely on Nuon's cloud. They also benefit from Nuon managing their Nuon deployment versus self-hosting Nuon.

You must be a licensed Nuon customer to use Nuon BYOC. Contact sales and share your use case and requirements.

Yes.

That is one of Nuon's use cases.

Nuon is an open-source platform to deploy and manage any cloud-native software app into AWS, Azure, and Google Cloud.

So Nuon can manage vendor and in-house software apps.

Yes.

The DevOps and Cloud Engineering team would configure an app in Nuon's TOML file format, pointing to existing scanned vendor container images, Helm charts, Terraform and day-2 scripts.

Then install the vendor onto the cloud provider of choice for specific departments, regions, or divisions.

No.

When customers self-host a vendor's software there is no restriction on what tooling is used to deploy and manage their software.

If a vendor uses Nuon, they manage their images in Nuon. The same goes if an enterprise uses Nuon to deploy vendor apps - you'd point Nuon to your scanned images.

No, Nuon Cloud is for startups and the self-service trial as part of our product-led growth strategy and open source. We deploy Nuon control plane into the customer's private cloud. This can be done by Nuon using Nuon, or self-hosted with Helm charts.

The infrastructure includes ClickHouse, Temporal, PostgreSQL, our Go API service, and React-based front-end.

If depends on where Nuon is licensed and installed.

Scenario #1: End Customer Deploys Nuon's Control Plane

If the end customer licenses and deploys Nuon, their DevOps and Cloud Engineering staff configure Nuon apps for each vendor's software that they currently self-host.

They benefit from a standard, and cross-cloud way to install and manage their apps.

Scenario #2: The Vendor Deploys Nuon's Control Plane

If the software vendor licenses and deploys Nuon, they configure their app for Nuon, and contractually work with their customers to install and manage their app in the customers' cloud accounts.

Vendors benefit from an incremental revenue stream besides SaaS and self-hosted, and end customers benefit from meeting data residency requirements and shifting the management of the app to the vendor.

Besides being open source, Nuon is pluggable by design, supporting all 3 clouds, Terraform, Kubernetes, Helm, S3, etc.

Our agent (runner) is provisioned by the target cloud with a stack like CloudFormation and polls the Nuon control plane for jobs to deploy or upgrade the vendor app, and perform day-2 ops like run scripts.

Database, Internal Tools Builders, Observability, AI - basically any vendor with a sensitive data plane component and with regulated industry customers.

BYOC is a relatively new deployment option, so there are varying styles and approaches to vendor's offering BYOC.

If there isn't documentation on the vendor website, contact their sales team to learn more.

Questions you should ask include:

• Which clouds they can deploy into?

• Is there a multi-year commitment?

• How automated is their BYOC approach or is it heavily services-based?

• Do they require cross-account access or do they have an agent approach like Nuon?

• Are the control and data planes in the customer's cloud?

You are welcome to recommend the software vendor contact Nuon to learn about using our platform for their BYOC offering.

Alternatively, consider investigating Nuon for use inside your enterprise to more easily and securely install and manage your vendor and in-house developed apps — across multiple cloud providers in your private VPCs.

No.

Contact sales about licensing Nuon.

Nuon Cloud can install Nuon's control plane on AWS, Azure, and Google Cloud, but there currently is an AWS dependency.

Nuon has a Master Service Agreement (MSA) which includes:

• Subscription Period (minimum 12 months)

• Deployment Model (Customer or Provider-Hosted)

• License items and quantities

• Fees

• Standard Terms

The Deployment Model includes a specific Schedule with Provider and Customer Responsibilities and Exclusions.

To learn about pricing and fees, contact sales.

Nuon is FedRAMP compliant but not authorized, since we're self-hosted software. We support deployments on FedRAMP-authorized infrastructure.

Nuon Cloud

Nuon Cloud is a multi-tenant offering of Nuon in our AWS infrastructure. Free trials and smaller-size licensed customers operate in Nuon Cloud.

Nuon has organizational access to troubleshoot a customer's org instance.

Nuon BYOC

Nuon BYOC is where Nuon deploys and manages an instance of Nuon's control plane in a software vendor's cloud.

Nuon will have access to troubleshoot and update Nuon.

Customers can temporarily disable the Nuon runner by changing the desired capacity of the AWS Auto Scaling Group to 0 which will shutdown the EC2 instance with the Nuon runner.

Open Source Support

Nuon supports users of its open source project nuonco/nuon through our Slack community.

You can sign up here: Nuon's Slack community

Feature requests and bugs should be created as GitHub Issues in our open source repository.

Licensed Customer Support

Nuon supports licensed customers with private, shared Slack channel.

Please contact sales to set that up.

You can sign up here: Nuon's Slack community

If you update the secrets, you will need to re-provision, but you don't need to re-create everything. There is a CloudFormation flow to update a stack w/ the new template. the template generated for the re-provision can be used to update the stack. we suggest using the "create a change set" in the AWS console.

• fire off the re-provision flow from the Nuon dashboard

• copy the new stack template

• go to the CF stack in the AWS console and select the root stack

• click "Update stack" > "Create a change set"

• replace the template w/ the new template

This flow will only update the resources that have changed. e.g., it will add the new secrets.