nuonco/example-app-configs.
Every pattern shares the same base:
- The customer deploys a stack with their own credentials. It creates the runner and the operation roles it uses.
- The runner connects outbound only, so you need no cross-account access. The customer can turn it off at any time.
- Secrets stay in the customer’s cloud secret manager, and break glass roles cover incidents.
- Customers can export runner audit logs to their own logging backend.
Supported patterns
Dedicated account (full BYOC)
The customer asks: “Run your product in our AWS, Azure, or GCP account, but you operate it.” Build it: Use the stand-alone VPC stack, which creates a new VPC for the install. The sandbox creates the base infrastructure, such as a Kubernetes cluster. Your components deploy your Helm charts, Terraform modules, Kubernetes manifests, and container images on top. Reference apps:eks-simple-auto (AWS), gke-simple (GCP), aks-simple (Azure). See platform support for what each cloud supports.
Existing customer VPC
The customer asks: “Deploy into our VPC and subnets.” Build it: Use the customer VPC stack. On AWS, the Nuon-generated CloudFormation template accepts the customer’s VPC and subnet IDs, and the sandbox attaches to those subnets. The default Terraform stack modules always create a new VPC, so Terraform deployments of this pattern need a fork ofinstall-stacks. See customizing Terraform stack templates.
Reference app: byo-vpc.
Existing customer Kubernetes cluster
The customer asks: “Install into our shared cluster,” or your product is an agent or operator that needs in-cluster access. Build it: Start from the customer VPC pattern, then add custom nested stacks that give the runner access to the cluster. See customer cluster. Reference app:byo-eks.
Agent or worker next to customer data (hybrid data plane)
The customer asks: “Keep our data in our network. Your hosted product can still manage the work.” Build it: Your hosted product stays the control plane for your users. Package the agent or worker that touches customer data as a Helm chart, Kubernetes manifest, or container image component, and Nuon installs and upgrades it in each customer account. To run it in a cluster the customer already has, use the existing cluster pattern. Reference apps:datadog-operator (operator in the customer’s cluster), ecs-simple (ECS).
Self-hosted package you want to operate for the customer
The customer asks: “We run your Helm chart today and own the upgrades. We want you to run it, in our account.” Build it: Wrap your existing Helm chart as a Helm chart component. Add Terraform components for what the chart depends on, such as a database or bucket. You then ship changes by pushing to git, and app branches roll them out with plan review and approvals. See updates and operations.Single-tenant per customer
The customer asks: “We need a dedicated, isolated deployment.” Build it: Every install is its own stack, sandbox, and set of components in one cloud account. Install the same app template into an account you own for a dedicated hosted tier, or into the customer’s account for BYOC. See creating installs.Data residency and region pinning
The customer asks: “Our data must stay in a specific region.” Build it: Each install is created in one region (nuon installs create --region <region> in the CLI), and its resources are created in the customer’s account in that region. To block changes that would create resources elsewhere, add a policy. Policies can check Terraform plans before they deploy. See configuring policies.
Reference app: policies-demo.
Patterns you build with components
No dedicated docs page covers these, but standard Nuon building blocks support them. A Terraform component can create any resource Terraform supports in the customer’s account, using the operation role’s permissions. A custom nested stack creates resources earlier, when the customer deploys the stack with their own admin credentials. Pass outputs to other components with{{.nuon.components.<name>.outputs.<key>}}. See component dependencies and using variables.
Customer-managed encryption key
The customer asks: “Encrypt our data with a key we control and can revoke.” Build it: Accept the customer’s existing key ARN or ID as an input, or create the key in a Terraform component. Grant your components’ operation roles only the key actions they need.Customer-owned storage bucket
The customer asks: “Store our data in a bucket in our account.” Build it: Create the bucket in a custom nested stack, so it exists before any component runs and is created with the customer’s credentials. Or create it in a Terraform component. Reference apps:gcp-gcs-bucket, azure-custom-storage.
Customer database
The customer asks: “Run the database in our account, on our managed service.” Build it: Create the managed database (for example RDS or Cloud SQL) in a Terraform component. Pass its connection details to your Helm chart values with component outputs, as shown in component dependencies.Model provider in the customer account
The customer asks: “Use our own model provider account, such as Amazon Bedrock, for the AI features.” Build it: Create the IAM role or service account for the customer’s model provider in a Terraform component, and pass the endpoint to your app as a component output or install input. Reference app:byo-llm-openui (experimental).