featuresd

featuresd is a tiny dæmon that helps you decouple your code releases from your feature releases.

Developers define features and segments, then your app uses the featuresd API at runtime to find out which features are available in any context.

Works alongside any language or framework
Simple to deploy as a single static binary
Fast and low memory footprint

Quickstart

You can run featuresd locally in about 30 seconds.

# Download and run featuresd (no sudo required!)
curl https://featuresd.io/get.sh | bash
./featuresd -p 15555 --insecure &

# Create a feature
curl -XPOST localhost:15555/api/features \
  -d id=new_interface_alpha

# Create a "context" and enable the feature we just created
curl -XPOST localhost:15555/api/contexts \
  -d id=user1 \
  -d features[new_interface_alpha]=true

# Check which contexts match the feature
curl localhost:15555/api/contexts/?matches=new_interface_alpha

# That's all, folks
kill featuresd

Read the docs to get the full story

featuresd is a focused project which may not suit everyone. To stay sustainable we have to say “no” to some features.

Included

HTTP and interprocess APIs
Web-based management UI
Audit log of changes to features and contexts
Use Lisp to define feature matching instead of a custom boolean language or GUI builder
Metrics export to statsd

Not included

Enterprise user and ACL management
Scheduled and automatic feature rollouts
Integrations & SDKs
Managed hosting
User behaviour analytics

Simple capabilities can have broad reach, allowing you to manage your apps the way you want.

Context prototypes

featuresd doesn't prescribe a structure for your data. A context can have one or more prototypes which it inherits features from.

# User inherits features from their team, and
# from a beta-testing segment they have opted in to
curl -XPOST localhost:15555/api/contexts \
  -d id=user1 \
  -d prototype[]=team1 \
  -d prototype[]=beta_testers

# Enable a beta feature for all beta testers
curl -XPOST localhost:15555/api/contexts \
  -d id=beta_testers \
  -d features[new_interface_beta]=true

Powerful matching rules

Instead of inventing our own boolean language for feature matching, featuresd uses Lisp.

# Define a feature enabled for a complex set of users
curl -XPOST localhost:15555/api/features \
  -d id=tricky_situation \
  -d match='(or \
    (= "US" (ctx "country")) \
    (> 10 (ctx "team-size")))'

Flags-as-code

Instead of managing your features and segments through the web UI, you can deploy code from a repository. This is great for keeping feature definitions in sync between dev, pre-release, and production environments.

# Sync feature definitions from a manifest
curl -XPOST localhost:15555/api \
  -d manifest=@/path/to/manifest.toml

Why use a feature flag manager?

For more information about progressive delivery and feature flagging, check out the original post by Flickr, or this detailed guide from LaunchDarkly.

Ship new features behind a flag, then roll them out gradually
Enable change management for large/slow customers
Centralise, formalise and audit moderation
Don't build it yourself if you don't want to

Who is featuresd for?

Right now, featuresd is handling production workloads at Pylon.

Small companies and startups
Hackers and developers
Self-hosting and open-source enthusiasts

What else is out there?

See the docs for more comparisons between featuresd and alternatives.

Unleash (open-source, managed, JS)
Flagsmith (OS, managed, Python)
LaunchDarkly (managed)
Statsig (managed)