Featurevisor is an open source feature-management system where flags, experiments, and remote configuration live as YAML files in a Git repository instead of a vendor dashboard. Developers declare attributes, segments, flags, variations, and typed variables in files, review changes as pull requests, and use a command-line tool to lint, test, and build static JSON datafiles. Lightweight SDKs for JavaScript, browsers, servers, and mobile then evaluate those rules locally in memory, fetching the datafiles from the team's own CDN. It is MIT-licensed and aimed at developers comfortable with a Git workflow.[1][2]
Quick verdict
Featurevisor is the right flag system for developers who want Git-reviewed flag changes, local in-memory evaluation, and zero vendor lock-in. Its YAML-plus-CLI workflow makes rollouts and experiments auditable as pull requests, with typed variables and sticky experiment bucketing built in. The tradeoff is operational: there is no management UI, and the team owns hosting, caching, and experiment analysis. Git-native teams running their own CDN should adopt it; dashboard-dependent or analytics-managed teams should choose Flagsmith or Featbit instead.[1][2]
Capabilities
Git-reviewed flag definitions Flags, segments, variations, and variables are declared as YAML in Git, so every rollout change gets pull-request review, diff history, and rollback through the team's normal workflow.[1]
CLI build pipeline The command-line tool lints definitions, runs scheduled assertions, and builds versioned static JSON datafiles, catching schema and consistency errors in CI before anything ships.[1]
Percentage rollouts Flags support percentage-based rollout rules, so a feature can ramp from 1 percent to full traffic with sticky bucketing that keeps each subject in the same variation.[1]
Sticky A/B experiments Variations carry weights and MurmurHash-based sticky bucketing, letting teams run controlled experiments whose subjects stay assigned across sessions.[1]
Typed remote configuration Variables carry JSON Schema types with validation at build time, so remote configuration arrives typed and malformed values fail the build rather than the app.[1]
Nested targeting segments Segments combine attribute conditions with AND/OR nesting, so targeting rules can express country, plan, device, or custom attributes without custom code.[1]
Local in-memory evaluation SDKs for JavaScript, Node.js, browsers, React, Go, Python, Ruby, Java, Kotlin, Swift, PHP, Rust, and Elixir evaluate flags locally in memory, with OpenFeature providers available for a vendor-neutral API.[1][2]
Self-hosted datafiles Built datafiles deploy to the team's own CDN or static host with ETag polling, so evaluation never depends on a vendor service being reachable.[1][2]
Who will love it
Git-native delivery teams Teams that already ship through pull requests and CI will love that flag changes get the same review, audit trail, and rollback as application code.[1]
Cost-sensitive growing teams Teams avoiding per-seat vendor pricing will love the MIT licence with no seat fees: flag usage can scale across developers and services without a growing bill.[1]
Polyglot products Products spanning web, server, and mobile will love evaluating one shared Git-defined rule set consistently across thirteen SDKs and OpenFeature providers.[1][2]
Who should avoid it
Dashboard-dependent teams Teams that need a point-and-click management UI should avoid it: there is no console, and every change means editing YAML and running the CLI.[1]
Teams wanting managed analytics Teams expecting built-in experiment analysis should avoid it: the SDKs emit exposure events, but the team must wire its own analytics pipeline to interpret them.[1]
Teams avoiding operational load Teams that do not want to own hosting, caching, CI checks, and datafile delivery should avoid it: vendor independence means the operational burden sits entirely with the team.[1][2]
Compatibility and operations
Own CDN and CI required Adoption requires a Git repository, a CI step running the Featurevisor CLI, and a static host or CDN serving the built datafiles to the SDKs.[1]
Broad SDK coverage Client and server SDKs cover JavaScript, TypeScript, React, browsers, Node.js, Go, Python, Ruby, Java, Kotlin, Swift, PHP, Rust, and Elixir, with OpenFeature providers for standardised access.[1][2]
Vendor-neutral exit Because all definitions stay in the team's repository and SDKs evaluate locally, leaving for another tool never strands flag state with a vendor.[1]
Questions worth asking
What are good non-technical alternatives to Featurevisor?
Teams that need a point-and-click dashboard should consider Flagsmith or Featbit, which pair hosted interfaces with flag management. They suit non-developers and mixed teams, while Featurevisor suits developers who prefer Git. The tradeoff is operational control against convenience: a dashboard product manages hosting and UI for you, while Featurevisor leaves both in your hands.[1]
Can non-developers manage flags in Featurevisor without code?
No. Flags, segments, and variables are authored as YAML files in Git and built with a command-line tool, and changes ship through pull requests and CI. A non-developer cannot safely manage flags without a developer operating that workflow. Teams needing no-code flag control should choose a dashboard-based product instead.[1][2]
How much does Featurevisor cost per month?
The software licence costs nothing: Featurevisor is MIT-licensed with no per-seat pricing, so there is no monthly vendor bill at any team size. Your only spending is your own infrastructure, meaning static hosting or CDN delivery for the datafiles plus the CI minutes that build them. Most teams will find this near zero next to their existing hosting.[1]
Can I self-host Featurevisor?
Yes. There is no vendor-hosted service in the loop: you build static JSON datafiles from your Git repository and serve them from your own CDN or static host, and the SDKs fetch and evaluate them there. You keep every flag definition in your own repository, so you can move or leave at any time. The cost of that freedom is that you own uptime, caching, and key rotation.[1][2]
Sources and editorial review
Source research. Reviewed on October 9, 2026. Written by Sanjib Sah. AI assisted; reviewed by a human editor.
We have not run or tested this product.
- Featurevisor - Open-source feature management
official · Observed October 9, 2026
Product homepage inspected for definition, workflow, SDK list, licensing, pricing, FAQ, and alternatives positioning.
- featurevisor/featurevisor README
official · Observed October 9, 2026
Repository README inspected for YAML authoring model, variation and segment semantics, variable schemas, SDK list, and licence.
Compared with these products
No explicit proprietary baseline is recorded.