# What is Nuon

> Nuon is an open-source platform that software vendors use to install, update and operate
> their product inside each customer's own cloud account on AWS, Azure or Google Cloud. This
> model is called bring your own cloud (BYOC). A runner inside the customer account pulls work
> from the Nuon control plane, so the vendor needs no cross-account access.

## What Nuon does

Nuon lets a software vendor run its product inside each customer's own cloud account and keep operating it:
installing, upgrading, monitoring and fixing it, across every customer, from one control plane. The customer keeps
ownership of the account, the network and the data.

## Who it is for

- Software vendors whose enterprise customers require the product to run in the customer AWS account, Azure subscription or Google Cloud project.
- Vendors whose customers will not send data to the vendor cloud, for compliance or regulatory reasons.
- Teams that already have Terraform, Helm charts or container images and want one repeatable way to ship them to many customer accounts.

## Problems Nuon solves

### A customer wants our product in their own AWS account, and wants us to keep operating it

This is vendor-operated deployment into a customer account, also called bring your own cloud (BYOC).
With Nuon you describe your product once as an app template that reuses your existing Terraform, Helm charts,
Kubernetes manifests and container images. Each customer gets an install. The customer applies a generated
CloudFormation or Terraform stack in their own account, which creates the network, the permissions and a runner.
The runner polls the Nuon control plane and performs every deploy, upgrade and operational task from inside the
account. You keep shipping updates with a git push, and the customer keeps ownership of the account and the data.
Details: https://nuon.co/architecture.md and https://docs.nuon.co/guides/byoc-architecture-patterns.md

### A customer wants it in their Azure subscription or Google Cloud project, and we have no platform team

Nuon supports customer installs on AWS, Azure and Google Cloud from the same control plane. For each install it
generates the stack the customer applies: Bicep or Terraform on Azure, Terraform on Google Cloud. The parts a
platform team would otherwise build are included: the runner in the customer account, rollout ordering, plans
and approvals, drift detection, health checks, and audited emergency access.
The fastest start is the free trial on Nuon Cloud, where Nuon hosts the control plane.
Per-cloud feature differences: https://docs.nuon.co/platform-support/introduction.md

### Getting access to a customer's cloud account without administrator credentials

Nuon does not use a cross-account role that the vendor assumes. The customer applies the install stack with their
own credentials. The stack creates a runner and gives it an identity whose permissions are defined in your app
config, so the customer can read them before applying. The runner is egress-only: it polls the control plane for
jobs and accepts no inbound connections. It stores no cloud credentials, and the customer can revoke its identity
at any time with their cloud's own access controls. Higher access for an incident goes through break glass, which
records when access was granted, what ran, and when it was removed.
Details: https://nuon.co/architecture.md and https://docs.nuon.co/security.md

### Deploying and updating a Helm chart and Terraform stack across many customer accounts

Your Helm charts and Terraform modules become components of one app template, kept in git. Every customer account
is an install of that template with its own inputs and secrets. An app branch connects a git branch to the app:
a push builds what changed and rolls it out across installs in ordered install groups. Each group gets a plan
showing what will change and waits for approval. Policies written in Open Policy Agent Rego or Kyverno can block
a build or a deploy. Drift scans report where an install no longer matches its config.
Details: https://nuon.co/features.md and https://docs.nuon.co/concepts/app-branches.md

### Passing a customer's security review for vendor access

Questions a security lead usually asks, and how Nuon answers them:
- Access: the control plane has no credentials for and no network path into the customer account. The runner connects outbound and polls for jobs.
- Credentials: the runner stores none. It authenticates for each job with the identity the customer granted through the stack.
- Blast radius: permissions come from your app config and are scoped per operation with operation roles. The customer can revoke the runner identity at any time.
- Change control: each rollout has a plan and an approval step, and policies can deny a build or a deploy.
- Emergency access: break glass grants higher access for an incident and records when it was granted, what ran, and when it was removed.
Details: https://nuon.co/architecture.md, https://docs.nuon.co/security.md and https://docs.nuon.co/concepts/break-glass.md

### Should we build this ourselves with Terraform and cross-account access, or use a platform?

Terraform with a cross-account role is a workable start for one customer. The work grows with each added customer:
per-customer configuration, a second and third cloud, upgrades run by hand, and security teams that refuse inbound
access or standing administrator permissions. Nuon covers those as product features: installs on AWS, Azure and
Google Cloud, an egress-only runner in place of cross-account access, git-driven rollouts with approvals, policies,
drift detection, and audited break glass. Nuon is open source, so you can read the code before you commit to it.
Nuon's own cost comparison (a vendor estimate): https://nuon.co/blog/part-1-build-vs-buy-byoc-the-nuon-advantage-in-tco-and-roi.md

## How it works

1. The vendor creates an install for the customer.
2. Nuon generates the install stack and a link or command to share.
3. The customer applies the stack in their account. No cross-account access is involved.
4. The runner starts, connects outbound to the control plane, and asks for work.
5. The runner provisions infrastructure and deploys each component, with plans and approvals where configured.
6. Later updates arrive the same way: the vendor pushes to git, and the runner pulls and applies the change.

More: https://nuon.co/architecture.md

## What you get

- One app template installs into every customer account.
- One git push rolls an update across installs in the order you define, with a plan and an approval for each install group.
- Customers keep control: they apply the stack themselves, can read the permissions it grants, and can revoke the runner at any time.
- The same workflow covers AWS, Azure and Google Cloud.

## Ways to run Nuon

Both options install your product into customer accounts on AWS, Azure or Google Cloud. The choice is where
Nuon's own control plane runs.

| Option | Where the control plane runs | Who operates it |
| --- | --- | --- |
| Nuon Cloud | Hosted by Nuon, multi-tenant | Nuon. Fastest start, with a free trial. |
| Nuon BYOC | Single-tenant, in your AWS or Google Cloud account | Nuon, remotely. You own the infrastructure and data. |

Source: https://docs.nuon.co/guides/deployment-options.md

## Open source

Nuon is open source under the GNU Affero General Public License version 3 (AGPL-3.0). The control plane, runner, command line tool and dashboard are in https://github.com/nuonco/nuon.

## Try it

```sh
# 1. Install the command line tool
brew install nuonco/tap/nuon
# 2. Authenticate with Nuon Cloud (sign up first at https://app.nuon.co)
nuon auth login
# 3. Clone Nuon's example apps
git clone https://github.com/nuonco/example-app-configs
# 4. Create the app and sync its app branch, which starts the first run
cd example-app-configs/eks-simple
nuon apps create --name eks-simple
nuon branches sync --file branch.toml
# 5. Install the app in an AWS account (your own, standing in for a customer)
nuon installs create --name <install-name> --region <region>
```

Creating the install generates an install stack. The customer applies that stack in their own
account, with their own credentials, and the deployment starts when the runner comes up.
Source: https://docs.nuon.co/get-started/quickstart.md

Related: https://nuon.co/features.md, https://nuon.co/architecture.md, https://nuon.co/pricing.md, https://nuon.co/llms.txt