From Helm Chart to BYOC: Deploying Into Your Customer's Cloud

Deploying an app with Nuon to your customer's cloud is a matter of bringing your existing Infrastructure as Code (IaC) and creating some configurable inputs for your customer.

We are making it even easier with the launch of bringyourhelm.com . If your app uses Helm Charts, you can use this site to spin up a proof of concept for BYOC deployment right now!

This post describes the conversion process of going from your existing IaC to a Nuon app config so that you can look under the hood. If you just want to get started, head to bringyourhelm.com or - skip ahead to Automating the Conversion below - .

From your Helm Chart to a Nuon Config

What Nuon provides is a purpose-built control plane for BYOC that enables you to use existing IaC to define your app as configuration files. Nuon uses these config files to handle the orchestration: provisioning your app’s infrastructure on each customer cloud, collecting their inputs, deploying components in dependency order, managing updates, and more.

The provisioned infrastructure includes the supporting stack your Helm chart expects, ingress controllers, DNS, and certificate management, so you don't have to wire that up per customer either.

The Anatomy of a Nuon App Config

A Nuon app is a directory of TOML configuration files stored in git:

bringyourhelm.com creates the configuration files for your app ( metadata , sandbox , runner , stack , break_glass , permissions/ ).

inputs.toml and actions/ are added when the app needs customer configuration or post-deploy automation. Components declare explicit dependencies so Nuon deploys them in the right order.

Full configuration reference is here.

Automating the Conversion

Everything described in this post — reading the Helm charts, classifying values, generating the TOML files, templating values.yaml, adding infrastructure components — follows a systematic pattern.

Authenticate with Github to convert your helm charts, or search for any public Helm chart on GitHub, pick it, configure your target cloud (AWS EKS, Azure AKS, or Google Cloud GKE) and infrastructure mode (default or BYO-VPC), and get a complete set of Nuon config files generated in seconds.

Under the hood, it fetches the chart's Chart.yaml and values.yaml , applies the value classification rules and format gotchas described in this post, and parses the structured output into downloadable files.

What you get: A ZIP containing all the core files ( metadata.toml , inputs.toml , sandbox.toml , runner.toml , stack.toml , break_glass.toml , permissions/ ), component TOMLs with inline Terraform for any detected infrastructure dependencies, a templated values.yaml , and a db-credentials action when a database is detected.

What you still need to do: Review the output. The tool handles the mechanical translation — file structure, TOML syntax, template variable formatting, ingress wiring, and disabling the chart’s subcharts in favor of managed infrastructure. The judgment calls you will make include which additional values should be customer inputs, what default sizing is appropriate for your customers' workloads, and any app-specific configuration (like Gitea's app.ini routing).

Think of it as a first draft from an engineer who is deeply familiar with the Nuon format, but doesn't know your product's operational requirements. It gets you from "I have a Helm chart" to "I can start building my Nuon-powered BYOC proof of concept" in seconds instead of hours.

Converting a Helm Chart — Step by Step

Let’s dive into an example: Gitea , a self-hosted Git service. It's a good example: PostgreSQL (HA) database, Valkey cache cluster, hardcoded admin credentials, ingress, and persistent storage.

What You Start With

Chart.yaml shows the dependencies:

values.yaml — the key sections:

Classifying Every Value

Every value falls into four categories:

• Customer Input — your customer can choose this
• Customer Secret — your customer’s chosen admin password
• Application Component — your application’s infrastructure dependencies

Replacing Subcharts

The chart bundles Bitnami PostgreSQL (HA) and Valkey Cluster subcharts. For a developer's own cluster, these are convenient. For a customer's production environment, they do not make sense. Enterprise customers expect RDS with encryption at rest, automated backups, and Multi-AZ failover. A StatefulSet running PostgreSQL in a pod doesn't meet that bar.

The conversion disables both subcharts and replaces them with Terraform that provisions RDS and ElastiCache. Gitea connects to these managed services through its gitea.config section (which maps to app.ini ), referencing component output variables instead of talking to subchart pods.

The Generated Files

bringyourhelm.com generates a starting set of inputs: subdomain, admin password, and database name. For a production config, you'll want to add more (admin username, admin email, replica count, storage size, etc.) depending on what you want your customers to configure.

The [public_repo] points to your config repo, where the tool generates inline Terraform (a main.tf in the component directory) that creates the RDS instance, security groups, and subnet groups. The [vars] wire into the sandbox and install stack outputs directly — VPC ID, subnet IDs, region. This is the infrastructure plumbing that connects the managed database to the customer's provisioned environment.

bringyourhelm.com automatically detects [helm_repo] or you can use the chart's GitHub repo.

Next the templated values inserted at components/values/gitea/values.yaml

bringyourhelm.com edits the values.yaml with swapped in Nuon variables for BYOC deployment. Here's a snippet of what the generated output looks like:

This handles the mechanical parts: disabling the chart’s subcharts, wiring externalDatabase and externalRedis to the Nuon-created infrastructure, configuring ingress with the customer's domain, and replacing hardcoded passwords with input variables.

For Gitea specifically, the gitea.config section is where it gets interesting. Unlike charts with a simple externalDatabase.host field, Gitea routes database, cache, session, and queue config through its app.ini format. You'd extend the generated values to wire each subsystem explicitly — using the RDS endpoint for the database and ElastiCache for cache, session, and queue (with different Redis database numbers for isolation).

Validate and Deploy

nuon apps sync catches malformed TOML, missing input references, invalid template variables, and unreachable chart sources. It won't catch logical errors — whether 50Gi is the right default for your customers, or whether the Redis database numbers are correct. Review the configs like any IaC PR before it touches a customer's account.

Get Started

Try the tool: bringyourhelm.com — paste a GitHub repo URL or search by name.

Read the docs: Helm Chart Components Guide — the canonical reference for Nuon Helm chart configuration.

See production examples: Nuon’s Example App Configs — we suggest new users try these for reference.