Releases
How to use config releases, and why they beat conditional parameters for many teams
Nona treats runtime configuration like something you can prepare, snapshot, activate, and patch deliberately. That is a very different operational model from systems where one mutable config surface keeps branching through conditions.
What a release means in Nona
Every environment has one editable working configuration and zero or more immutable releases. Operators make changes in the working configuration, then snapshot those changes as a release. Clients read a release, not the mutable workspace.
That sounds small, but it changes everything operationally. It means you can answer questions like: what exactly was live, what exactly changed, and what exact version should we go back to?
How to use releases in practice
Prepare changes in Parameters
Treat the Parameters page as your working area. Edit values, add new parameters, or adjust a JSON config until the next release looks right.
Create a version by line, not by patch
On the Releases page, click Create a version and enter a major-minor version such as 1.2. Nona normalizes that to 1.2.0 for the first release in the line.
Review in compose mode
Nona takes you back to Parameters in release compose mode. That lets you review the exact values that will be captured before you create the immutable snapshot.
Create, then activate separately
Creating the release stores the snapshot. Activating it is a second deliberate step. That separation is what keeps publishing safer than editing live config branches.
Why releases are better than conditional parameters for many config workflows
Conditional parameters look flexible because they let one key branch by condition, rule, environment, or targeting clause. But flexibility is not free. In many systems, it means the answer to "what value is live?" becomes "it depends on which branch wins at runtime."
Releases are better when your team cares more about operational clarity than about building a mini rule engine into config. Instead of one mutable object with hidden branches, you get explicit snapshots and explicit activation.
The real operational benefits
- You can promote config like software: prepare it, snapshot it, activate it.
- You can reason about incidents with exact versions instead of ambiguous rule combinations.
- You can keep patch lines explicit. 1.1.1 means something concrete in a way that 'the older condition branch' does not.
- You can separate editing from serving, which lowers the chance that unfinished work leaks to clients.
- You can backport safely with Amend without polluting the main working configuration model with permanent conditional branches.
What Amend gives you that conditions usually do not
In many conditional systems, patching an older line means keeping even more branching logic around: more conditions, more overrides, more exceptions, more places for a future operator to miss something.
Nona's Amend flow is narrower and more honest. You pick a source release, Nona loads that exact snapshot into the working configuration, automatically increments the next patch in that line, and lets you create a new immutable release. No hidden runtime branch. No condition tree to mentally simulate.
When conditional parameters are still useful
If your main problem is per-user targeting, cohorts, or runtime segmentation, then a condition-heavy system may still be the right tool. This article is not claiming that branching rules are always wrong.
The point is narrower: for many teams using remote config as operational infrastructure, releases are simpler to run, simpler to debug, and simpler to trust.
Try the release workflow yourself
Nona is open source and self-hosted. Stand it up, create a project, add a couple of environments, and run through the release flow once. The model becomes obvious the moment you activate a snapshot instead of editing a live conditional tree.