BarakoCMS.FeatureFlags 4.4.0

dotnet add package BarakoCMS.FeatureFlags --version 4.4.0
                    
NuGet\Install-Package BarakoCMS.FeatureFlags -Version 4.4.0
                    
This command is intended to be used within the Package Manager Console in Visual Studio, as it uses the NuGet module's version of Install-Package.
<PackageReference Include="BarakoCMS.FeatureFlags" Version="4.4.0" />
                    
For projects that support PackageReference, copy this XML node into the project file to reference the package.
<PackageVersion Include="BarakoCMS.FeatureFlags" Version="4.4.0" />
                    
Directory.Packages.props
<PackageReference Include="BarakoCMS.FeatureFlags" />
                    
Project file
For projects that support Central Package Management (CPM), copy this XML node into the solution Directory.Packages.props file to version the package.
paket add BarakoCMS.FeatureFlags --version 4.4.0
                    
#r "nuget: BarakoCMS.FeatureFlags, 4.4.0"
                    
#r directive can be used in F# Interactive and Polyglot Notebooks. Copy this into the interactive tool or source code of the script to reference the package.
#:package BarakoCMS.FeatureFlags@4.4.0
                    
#:package directive can be used in C# file-based apps starting in .NET 10 preview 4. Copy this into a .cs file before any lines of code to reference the package.
#addin nuget:?package=BarakoCMS.FeatureFlags&version=4.4.0
                    
Install as a Cake Addin
#tool nuget:?package=BarakoCMS.FeatureFlags&version=4.4.0
                    
Install as a Cake Tool

<div align="center"> <img src="https://raw.githubusercontent.com/BaryoDev/barakoCMS/master/assets/icon.png" width="96" height="96" alt="BarakoCMS.FeatureFlags logo" /> <h1>BarakoCMS.FeatureFlags</h1> <p><em>Ship it dark, turn it on for some people, then everyone.</em></p> </div>


Create a flag, toggle it, and target it — by tenant, by user, or by percentage rollout. Flags are global with per-tenant targeting, and every decision is made server-side.

Enable it

dotnet add package BarakoCMS.FeatureFlags
builder.Services.AddBarakoCMS(builder.Configuration);

var app = builder.Build();
app.UseBarakoCMS();

The package reference plus a restart is the install. AddBarakoCMS finds every module in the application's dependency context, and BarakoCMS:Modules:Enabled decides which of them run (BarakoCMS__Modules__Enabled=FeatureFlags). Unset, every referenced module runs and the API logs one warning saying so. To name it by hand instead, put modules.Add(new BarakoCMS.FeatureFlags.FeatureFlagsModule()) in the AddBarakoCMS callback; discovery skips a type the host already added. See MODULES.md in the repository.

Endpoints

Method & path Purpose Access
GET /api/feature-flags Flags as evaluated for the caller (superseded by OFREP, below) Anyone (public flags only until signed in)
POST /ofrep/v1/evaluate/flags[/{key}] OpenFeature evaluation (see below) Anyone (public flags only until signed in)
GET /api/feature-flags/admin Every flag with its targeting rules Admin / SuperAdmin held as a global role
POST /api/feature-flags/admin Create or update a flag Admin / SuperAdmin held as a global role
POST /api/feature-flags/admin/{key}/toggle Flip a flag Admin / SuperAdmin held as a global role
DELETE /api/feature-flags/admin/{key} Remove a flag Admin / SuperAdmin held as a global role

Flags are global and their targeting names tenants, so the admin routes answer 403 to an Admin whose role comes only from a tenant membership.

GET /api/feature-flags returns decisions, not rules — the client never learns why it was included, and cannot flip itself in by editing a response.

OpenFeature (OFREP)

The module speaks the OpenFeature Remote Evaluation Protocol, so an OpenFeature SDK with its stock OFREP provider reads these flags with no client of ours. Give the provider the API's origin, https://your-api, as its base URL. Providers append the protocol's own path to the host, which is where the routes are:

Method & path Purpose Access
POST /ofrep/v1/evaluate/flags/{key} One flag, evaluated for the caller Anyone (public flags only until signed in)
POST /ofrep/v1/evaluate/flags Every flag the caller may see, with an ETag; a matching If-None-Match answers 304 Anyone (public flags only until signed in)

The subset covered, stated rather than implied:

  • Boolean flags only. value is true or false, variant is on or off. A string, number or object request for a key answers with the boolean, which an SDK reports as a type mismatch.
  • Reason: always STATIC. The protocol's other reasons (TARGETING_MATCH, SPLIT, DISABLED) would say why a caller got its value, and this module returns decisions, not rules.
  • Errors: FLAG_NOT_FOUND with 404, for a key that does not exist and, to an anonymous caller, for a private one, so the key is not disclosed.
  • Context: only targetingKey is read, only from an anonymous caller, and only to choose the rollout bucket. The tenant and the user always come from the request. A context naming another tenant or user changes nothing, so it cannot be used to read someone else's flags.
  • Not covered: context-based targeting rules, flag metadata, and the provider-side cache configuration endpoint.

GET /api/feature-flags keeps answering through 5.x. It is superseded by the routes above, and every response says so with Link: </ofrep/v1/evaluate/flags>; rel="successor-version".

Public flags

A flag is private until someone publishes it. GET /api/feature-flags is anonymous, because a public page rendering with flags has no user to authenticate, so an anonymous caller is handed only the flags with isPublic: true. Everything else is absent from the response, not returned as false: the key name is the leak, and {"acquisition-of-northwind": false} gives it away just as thoroughly.

Publish one deliberately:

POST /api/feature-flags/admin
{ "key": "new-checkout", "enabled": true, "isPublic": true }

isPublic defaults to false, and the admin upsert replaces the whole flag, so a body that omits the field makes the flag private. Flags created before this field existed read back as private, which is why upgrading discloses nothing that was not already meant to be public.

A flag is not access control

Use a flag to decide whether a feature is available. Keep using roles to decide whether a caller is allowed. A flag that hides an admin button still leaves the endpoint reachable.

Part of barakoCMS

This is an optional module for barakoCMS, an open-source headless CMS for .NET 10. Every module is published under the barakocms-module tag, so a single search on nuget.org returns the whole set.

Contributions are welcome — including a module icon or other design work. See CONTRIBUTING.md.

Licensed under MIT.

If barakoCMS is useful to you, a star on the repository helps other people find it.

Product Compatible and additional computed target framework versions.
.NET net10.0 is compatible.  net10.0-android was computed.  net10.0-browser was computed.  net10.0-ios was computed.  net10.0-maccatalyst was computed.  net10.0-macos was computed.  net10.0-tvos was computed.  net10.0-windows was computed. 
Compatible target framework(s)
Included target framework(s) (in package)
Learn more about Target Frameworks and .NET Standard.

NuGet packages

This package is not used by any NuGet packages.

GitHub repositories

This package is not used by any popular GitHub repositories.

Version Downloads Last Updated
4.4.0 56 10/14/2026
4.3.2 103 10/4/2026
4.3.1 101 9/29/2026
4.3.0 100 9/21/2026
4.0.0 109 9/7/2026
0.2.0 125 8/20/2026
0.1.3 115 8/15/2026
0.1.2 200 8/3/2026
0.1.1 133 7/21/2026
0.1.0 86 7/17/2026