Featurevisor

Documentation

Introduction

Define feature flags, experiments and remote configuration in YAML. Review changes in pull requests, test them in CI and build them into static JSON datafiles. Your applications evaluate those datafiles locally with an SDK.

Quick start How it works
npx @featurevisor/cli@latest init

From a file to your application

Every change follows the same four steps. Here is the whole loop for one feature, checkout, enabled for everyone in the Netherlands and a quarter of everyone else.

  1. Define
    features/checkout.yml
    description: Checkout redesign
    

    bucketBy: userId
    

    rules:
      - key: netherlands
        conditions: netherlands
        percentage: 100
    

      - key: everyone
        conditions: '*'
        percentage: 25

    A feature is a file in your repository. Its rules decide who gets it. Features

  2. Test
    tests/features/checkout.spec.yml
    feature: checkout
    

    assertions:
      - description: Dutch users are in
        at: 40
        context:
          country: nl
        expectedToBeEnabled: true
    

      - description: Everyone else waits
        at: 90
        context:
          country: de
        expectedToBeEnabled: false

    A spec pins a context and a bucket, then states the answer CI should get. Testing

  3. Build
    terminal
    npx featurevisor lint
    No lint errors found
    npx featurevisor test
    Assertion #1: Dutch users are in
    Assertion #2: Everyone else waits
    npx featurevisor build
    Datafiles built
    datafiles/
    └── featurevisor-all.json

    CI lints, tests and builds static JSON that you host on your own CDN. Building datafiles

  4. Evaluate
    your-app/checkout.js
    import {
      createFeaturevisor,
    } from '@featurevisor/sdk'
    

    const f = createFeaturevisor({
      datafile,
    })
    

    const context = {
      userId: 'user-4',
      country: 'nl',
    }
    

    f.isEnabled('checkout', context)
    // true

    The SDK answers from the datafile in memory, with no request per decision. SDKs

How Featurevisor works explains each step, including how rules, bucketing and requirements decide a result.

What teams use it for

Start from the outcome you want. Each guide walks through one workflow with a complete example, so engineers, product managers and marketers can plan the same release together.

Release apart from deploys

Ship code switched off, then turn it on when the business is ready.

Roll out gradually

Release to a small percentage, then widen it as confidence grows.

Launch on a date

Set the launch time in advance, with no deployment on the day.

Test in production

Give QA access to a feature before anyone else sees it.

Run an A/B test

Split users between variations and send exposures to your analytics.

Configure remotely

Change typed application settings without a new release.

Manage entitlements

Map each plan to what its users can access.

Roll back a change

Revert the definition in Git and publish the correction.

Switch it off fast

Plan which switch turns off what, and how fast it lands.

Run early access

Let customers opt in to new features before everyone else.

Keep experiments apart

Stop two tests from reaching the same user.

Name an owner

Require the owning team's approval on every change to its features.

The sidebar lists every use case, from trunk based development to microfrontends.

What your application reads

A datafile answers four kinds of question. Each evaluation takes a context, such as a user ID or a country, and the SDK decides the answer from the rules.

Flag

Turn a feature on or off.

f.isEnabled('checkout')
Variation

Give different users different versions.

f.getVariation('pricing')
Feature variable

Configuration that follows a feature’s rollout.

f.getVariable('buyButton', 'label')
Global variable

Configuration with a lifecycle of its own.

f.getVariable('supportEmail')

Find your way

New to Featurevisor

Learn the model, then create, test and evaluate your first feature.

Write definitions

Describe who gets what with attributes, segments, features and variables.

Test and ship

Catch mistakes in CI, then publish datafiles through your own pipeline.

Grow with your project

Organize larger projects and see what is defined where.

Work with AI agents

Let your coding agent create, test and explain definitions. Its changes still go through your review.

Product and marketing

See every feature, who it reaches and what changed, without reading YAML. Then plan launches and experiments with your engineers.

If you already run Featurevisor v3, the v4 migration guide moves your project and SDKs to the current version. The release announcement summarizes what changed.

Works in your stack

Choose the SDK for your language, a guide for your framework, or an OpenFeature provider if your application already uses that API. Every SDK evaluates the same datafiles.

SDKs

JavaScriptNode.jsGoPythonPHPRubyJavaKotlinSwiftRustElixirOpenFeature

Frameworks

ReactReact NativeNext.jsVue.jsNuxtAstroExpress.jsFastify

Good to know before you adopt

Featurevisor gives you the definitions, the tooling and the SDKs. These parts stay with your team.

  • You host the datafiles. Publish them to a CDN or storage you control. See Deployment.
  • Your application decides when to refresh. An SDK evaluates the datafile it was given. Fetching a newer one is up to your application.
  • Client datafiles are public. Anyone can read a datafile sent to a browser or a phone. Keep secrets and authorization on your server.
  • The CLI needs Node.js. Your applications do not. They only need the SDK for their language.

Open source

Featurevisor is MIT licensed and developed in the open on GitHub. There is no hosted service to sign up for, and nothing is priced per seat or per request. It runs on Git, your CI and storage you already have.

Next
How it works