Skip to main content
Company

Introducing App Branches

Deliver to a fleet of customer accounts, seamlessly

Matt Schultheiss portrait

Matt Schultheiss

Product Marketing Manager

· 4 min read

You’ve deployed your software into a customer's cloud account.

Deploying into ten customers’ accounts is where the model tends to break down. Each customer brings its own:

  • VPC
  • Egress allowlist
  • Identity provider
  • Compliance requirements
  • Release windows

So you patch per environment. A hotfix reaches three customers and not the other seven. There is no clean way to push one change across all of them and know what happened.

App Branches are Nuon's continuous delivery system for a fleet of customer installs. You connect a Git branch to your Nuon app, and a `git push` starts one coordinated update workflow across your customer fleet.

Rolling Out to a Fleet of Customers

Nuon CLI, or anything that can call Nuon's API or command line, can start the same rollout, so a release process that already knows when to ship can drive it directly.

Ordered Deployment Groups

A deployment group is a group of customer installs you are deploying to. Most engineering teams create deployment groups based on sensitivity level, with the most sensitive customers getting updates last.

The plan computes the diff and stops for your approval, so no customer's infrastructure is touched until someone advances the rollout from the dashboard or through the API.

Want a canary? Give your first group a deliberately narrow label selector and use the next group's gate as your decision point.

Pull Request Previews

Open a pull request against a tracked branch and Nuon runs it plan-only, commenting the

result back onto the pull request: a `## Nuon Preview — <AppName>` comment with a config-diff table broken out by Section, Added, Changed, and Removed, plus a `nuon/preview` commit status moving from pending to success or failure.

Git-Managed Customer Env Configs

The other half of customer fleet management is per-install configuration: inputs, labels, which components are toggled on, and for whom.

A dedicated configuration repo works well here, since customer-specific settings often want tighter permissions than your app config. Push a change and Nuon syncs it; a branch run picks up a `sync install configs` step.

The files carry `[labels]`, `[aws_account]`, `[inputs]`, `[stack_overrides]`, `[component_toggles]`, and per-component Helm values.

So one customer's inputs get the same pull request review, and the same diff, as a change to the app itself.

Getting Started

A branch is a name, a repo, and a list of groups. Here’s a branch from Nuon's own `eks-simple` example app:

branch.toml


For your own app, point the repo block at your config repo, use `[connected_repo]` if it is private, then run `nuon apps sync`, label your installs, and push.

---

Bring Your Own Cloud (BYOC) has always promised that your customers get your software in

their own cloud account without you giving up the ability to ship. App Branches delivers on the second half of that promise: the deployment velocity of a single centralized service, across a fleet you do not own, without hand-building a release pipeline for every customer you sign.

Check out the docs to learn more !

Ready to get started?

Deploy your application into customer clouds

See how Nuon can help you unlock BYOC deployment for your entire customer base.

Newsletter

Subscribe to our newsletter

Too much email? Subscribe via RSS feed