Feature flags you can run, inspect, and keep boring.
In Nona, most flags are boolean config entries scoped to an environment. That gives teams the control they need for toggles, kill switches, and release gates without adopting a full experimentation platform.
Feature flag basics
The useful part of feature flags is operational control.
Feature flags are often introduced for release management, but the day-to-day value is simpler: you can change application behavior without shipping a new artifact. That gives teams a safer way to merge code, disable risky paths, stage UI changes, and separate deployment from release.
Nona focuses on the core version of that workflow. A flag is a typed value in an environment, protected by an API key and readable from the application at runtime. That makes it easy to understand, easy to self-host, and easy to replace later because the read path is plain HTTP or OpenFeature.
What teams use it for
Nona works best when the flag decision is simple, environment-scoped, and operationally important.
- Kill switches for risky code paths
- Staged frontend release gates
- Backend route and job toggles
- Environment-specific enablement
- Operational toggles that need fast rollback
What you get in the implementation
Nona keeps feature flagging close to configuration instead of building a separate rule engine. The upside is a small, inspectable system with clear runtime behavior and fewer concepts for teams to operate.
Boolean entries
Most flags are boolean config entries, which keeps the read path simple and easy to test.
Scopes
Mark flags as client, server, or all so frontend apps never receive backend-only controls.
Environments
Use separate values for development, staging, production, and any other runtime environment.
OpenFeature
Use Nona through OpenFeature providers when you want a vendor-neutral feature flag API in application code.
Rollback
Pair flags with Nona history and releases when a config change needs a quick path back to a known-good value.
Plain HTTP
Services that do not need an SDK can still read flags directly from the environment-scoped REST API.
The flag model
Create a boolean entry such as Features:Checkout.
Choose whether it is client-readable, server-only, or shared.
Fetch the value from your app over HTTP, an SDK, or OpenFeature.
Toggle it in the dashboard when the release plan changes.
Reading a flag, in code
A flag check is a typed config read — no separate flag SDK to learn, and the same call whether it's a raw HTTP request or the JavaScript client.
curl "https://nona.example.com/api/environments/production/parameters/Features%3ACheckout" \ -H "X-Api-Key: your-api-key"
const checkout = await nona.getConfigValue("Features:Checkout");
if (checkout.contentType === "boolean" && checkout.value === "true") {
// show the new checkout flow
}Important limitation
Nona is not a targeting engine. Feature flags are environment-scoped values, not runtime evaluations against user IDs, segments, cohorts, or percentage-rollout rules. If you need that model, put it above Nona in application logic or choose a full feature-management platform.
Frequently asked questions
Is Nona an open source feature flag system?
Yes. Nona is open source under the Apache 2.0 licence and can be self-hosted with Docker. Feature flags are one of its primary use cases, alongside broader remote configuration.
How do feature flags work in Nona?
A Nona feature flag is usually a boolean parameter such as Features:Checkout. Your app reads it from a Nona environment, then uses the value to enable or disable code paths without a redeploy.
Does Nona support OpenFeature?
Yes. Nona includes OpenFeature providers for JavaScript server applications, JavaScript browser applications, and .NET services, so application code can use the OpenFeature API while Nona remains the backing provider.
Can Nona do percentage rollouts or user targeting?
Not by itself. Nona flags are environment-scoped runtime values. It does not include built-in percentage rollout, per-user targeting, segmentation, experimentation, or analytics pipelines.
When should I choose Nona instead of a hosted feature flag platform?
Choose Nona when you want self-hosted, inspectable, straightforward flags and config in your own infrastructure. Choose a hosted feature-management platform when you need advanced targeting, experiments, analytics, or vendor-operated uptime.
Start with one kill switch.
Add one boolean flag, read it from a real app path, and practice turning it off without a deployment.
Get started