# Nuon pricing

- You can try Nuon yourself for free. Sign up at https://app.nuon.co to start a trial on Nuon Cloud. No credit card is required.
- Pricing is available from the sales team: https://nuon.co/contact-sales
- Nuon is open source under AGPL-3.0. The code is at https://github.com/nuonco/nuon

## Common questions

### Can customers turn off vendor access?

Yes. The runner is the only entity with permissions in normal operations and connects outbound-only over HTTPS. Provisioning roles can be removed after setup, and break-glass access requires customer approval.

### Can customers scan our images in their own registry?

Images are imported and scanned in the vendor's repository, then the runner syncs them into the customer's registry (ECR, GAR, or ACR) so the customer can scan them with its own tools. Policies such as signed images can be enforced.

### Where do state, secrets, and the control plane live?

The control plane runs in the vendor's own account and holds Terraform state. Secrets stay in the customer's environment; the runner syncs them into the cluster without the control plane seeing them.

### Do you have SOC 2, a trust center, and an NDA?

Nuon has a trust center at trust.nuon.co with security documentation, and an MNDA is available to countersign. The SOC 2 audit is underway (Type I and Type II) along with an independent pen test.

### Is Nuon a subprocessor? Who do customers contract with?

When the control plane runs in the vendor's own cloud, Nuon is not a subprocessor. End customers contract with the vendor. Nuon Cloud is typically used only for trials.

### Can customer data stay in their own infrastructure?

Yes. The app runs in the customer's cloud account, and customers connect their own databases, internal registries, and code hosting by supplying them as inputs and sharing permissions inside their VPC.

### Can we prevent the vendor from reading customer PII inside an install?

Yes. Secrets stay in the customer environment, and actions and access can be scoped so the vendor cannot read application data or PII. Customers can also require break-glass approval for elevated access, and isolate installs in a separate account or VPC when compliance needs it.

### Can we enforce cluster and app policies in customer installs?

Yes. Policies can run in the compute environment (for example Kyverno and Kubernetes RBAC) and govern updates and actions, such as blocking public S3 buckets, new operators, or unwanted ingress. Customers can contribute their own policies or use an open-source catalog.

### How do updates reach every customer without pet environments?

App branches map installs to release channels (daily, weekly, or patch-only). Customers can set release windows, and the runner can be disabled between updates when they want zero activity.

### How do vendors and customers see health, logs, and audit?

Native actions and health checks run inside the customer account and produce a full audit log the customer can see. Telemetry can also go straight to the vendor's Datadog or Grafana using a per-install secret.

### How do we debug issues in customer installs?

Common paths are a Datadog or other agent in the install, scheduled health-check actions, and action scripts or ad-hoc actions that pull pod logs and cluster state through the runner. A resource catalog for live cluster visibility is on the roadmap.

### How can our SaaS reach services inside a customer install?

Customers can open a port, or the preferred pattern is for the install to initiate an outbound connection (for example websockets). Vendors also use Tailscale or reverse-proxy patterns built with container actions so the vendor cloud can reach the install without standing inbound access.

### How do we upgrade databases and other infra in the customer cloud?

Use action scripts or runbooks for steps like RDS upgrades, handle upgrades inside the app itself, or change an input (such as an app release version) so dependent components redeploy.

### Where does the runner live, and how is it updated?

The runner runs on a VM in the same customer VPC as the vendor's app. Its code auto-updates as a container, and the VM image is replaced through an auto scaling group.

### How do we enable features per customer?

One app with toggleable components and inputs lets features be enabled per customer at install time and changed later, which redeploys dependent components. Runbooks can handle one-off enablement.

### How do we roll out changes across many installs?

App branches group installs for staged rollouts. Installs can be labeled and batched, snowflake or pet installs can be updated manually, and every change shows a plan before it applies.

### How do we detect drift if a customer changes the cluster under us?

Enterprise change controls include drift detection that alerts when someone changes managed resources outside Nuon, for example deleting a node pool or editing a Kubernetes manifest.

### How do we alert on install downtime?

Scheduled health-check actions run in the customer runner on a cron, fail when the install is unhealthy, and can ping an API or notify Slack. Many vendors also deploy Datadog or similar into the install alongside Nuon actions. A first-class notification system is on the roadmap.

### Which deployment models should we offer first?

Most vendors start with vendor-managed single-tenant and one-click BYOC into a fresh customer account, then add customer-controlled networks, bring-your-own VPC, and bring-your-own-cluster options as they move upmarket, all driven by customer inputs.

### Can the app run in a customer-provided VPC?

Customer-provided VPCs, clusters, and egress allow lists are supported.

### Can customers bring their own buckets, keys, or other shared services?

Yes. Customer inputs cover bring-your-own bucket, key, domain, cluster ID, and connection strings for services such as Postgres or Redis. The same app config serves every install; each customer supplies their own values.

### Can only part of the stack run in the customer cloud?

Yes. An app can package only the pieces that must run in the customer's cloud, such as a worker or data plane, while the rest stays on the vendor's cloud. For the tightest security and control, the vendor's entire control and data planes can also run in the customer's cloud.

### Can customers keep using our SaaS UI while only the data plane runs in their cloud?

Yes. A common pattern is for the vendor's cloud UI and SSO to stay the entry point, while the data plane or other sensitive components run in the customer's account. Networking can use outbound connections from the install, VPC endpoints, or a tunnel so customers do not need standing inbound access.

### How do we support GPUs or specialized node pools in customer installs?

Sandboxes and components can provision GPU or other specialized node pools (for example Karpenter or cloud-native node groups) as part of the install, or accept a customer-provided cluster that already has them. Quotas and IAM for those pools still need to be available in the customer account.

### Can we ship a GA default app and a lockdown enterprise variant?

Yes. Vendors commonly maintain a default app for most customers and a stricter enterprise variant with tighter permissions, fewer optional components, and policy defaults for regulated installs. Inputs and toggleable components also let one app cover both without a full fork.

### Which clouds can installs run on?

Installs are supported on AWS, Azure, and GCP, each with its own sandbox for base infrastructure plus cloud-specific components. Vendors typically use one app per cloud with inputs for choices like bring-your-own VPC.

### Where can the Nuon control plane itself run?

Nuon deploys the control plane into the vendor's own AWS or GCP account using Nuon itself, for stronger security and less reliance on Nuon Cloud. Most customers, especially larger vendors, use this option. Startups and trials typically run the control plane on Nuon Cloud. Azure support is under development.

### Do you support more than Terraform?

Terraform, Pulumi, Helm, Kubernetes manifests, container images, and Lambda are all supported as components. Additional initialization, setup, and configuration steps, such as database dumps or Temporal setup, run as action scripts and runbooks inside the customer environment.

### Can we use OpenTofu instead of Terraform?

Vendors choose Terraform or OpenTofu in their app config. OpenTofu has not been tested yet, but no problems are anticipated.

### Do you support air-gapped or true on-prem installs?

After the initial vendor app installation, the customer can disable the runner for no vendor access. Customers can also operate an install from an air-gap bundle and CLI instead of a runner connected to the control plane, along a spectrum from vendor-managed to customer-managed.

### Can we deliver through AWS or Azure Marketplace?

Some vendors already sell through cloud marketplaces, but native marketplace delivery, including Azure Managed Applications, is on the roadmap.

### How much faster is this than building BYOC in-house?

Most vendors have their app running on Nuon in a day or two, and installs become a one-click stack for the customer instead of custom Terraform and screen-share sessions. Building BYOC in-house usually takes longer to value and costs more; see the [BYOC cost calculator](https://nuon.co/tools/byoc-cost-calculator-lite) and this [build vs buy TCO post](https://nuon.co/blog/part-1-build-vs-buy-byoc-the-nuon-advantage-in-tco-and-roi/).

### What if we need an exit path?

The control plane runs in your account, Terraform state can be imported and exported, and the platform is fully open source, so there is always a path to self-host.

### What does the customer install experience look like?

Out of the box, you hand the customer a one-click CloudFormation link, Terraform stack, or Azure template that sets up permissions and the runner. They enter inputs in the stack, or in a custom portal if you build one.

### How fast can we get a real install running?

Most vendors have a working app in a day or two, with a proof of concept and a shared Slack channel. Forward-deployed engineering is optional for a fee, used for integration work, and scoped to the vendor's level of involvement.

### How do we adopt Nuon without a rip-and-replace?

Existing environments can be adopted by importing Terraform state, by standing up a new install and migrating data, or by running Nuon alongside current production tooling.

### Can we build our own portal and support tooling?

Yes. Everything in the control plane is available through the API and CLI. Vendors build their own installers, support tools, and customer portals on top.

### Can AI agents work with Nuon through MCP?

Yes. Nuon has an MCP server so agents and coding tools can work with a vendor's own Nuon org alongside the CLI and API. See the [agents guide](https://docs.nuon.co/guides/agents/overview).

### How is Nuon priced?

A platform fee covers support and the control plane in your account or our cloud, plus per-customer production install licensing with volume discounts. Optional forward-deployed engineering is scoped per customer based on their level of involvement.

### Why do vendors put high-throughput workloads in BYOC?

When a feature moves huge I/O, for example about 1M events per second for usage metering, keeping that path in the customer cloud is cheaper and faster than shipping the data back to the vendor SaaS. The same pattern shows up in observability-style workloads.

Source: https://nuon.co/pricing