Self-hosted feature flags
Feature flags you run yourself
Ship code dark, turn it on for one customer, then roll it out by percentage. FlagPilot runs on your own infrastructure, and the Node SDK evaluates flags in memory: no network call per check.
const ctx = { key: 'user-42', plan: 'pro' };
client.variationDetail('new-checkout', ctx, false);- value
- true
- reason
- RULE_MATCH
- ruleIndex
- 0
- network calls
- 0
What you get
- 01
Organizations, projects, environments
Every project starts with development, staging and production. A flag is on in one environment and independently off in another.
- 02
Targeting that explains itself
Overrides, ordered rules, segments and weighted rollouts. Every evaluation returns a reason, so you can see why a user got a value.
- 03
Local evaluation
The SDK holds a validated snapshot in memory and keeps serving the last good one if delivery goes away.
Every feature
- 01
Organizations, projects and environments
Tenants, the products inside them, and the stages each product ships through, each configured on its own.
- 02
Flag types and variations
Boolean, string, number and JSON flags, each with a list of variations to serve.
- 03
Targeting rules
Ordered rules on context attributes. The first enabled rule that matches decides the value.
- 04
Individual overrides
Pin a specific user or a whole organization to a variation, ahead of every targeting rule.
- 05
Reusable segments
Define a group of users once, then target it from any flag in the project with in_segment.
- 06
Percentage rollouts
Weighted, deterministic rollouts in basis points. Raising a percentage only adds users.
- 07
Immutable snapshots
Every published change becomes a new, versioned snapshot of the environment that SDKs fetch whole.
- 08
Audit log and restore
Every change is recorded. Restoring an old configuration creates a new version and keeps history.
- 09
Node SDK with local evaluation
One client per process holds the snapshot in memory and evaluates flags with no network call per check.
- 10
REST management API
Everything the dashboard does, over HTTP, described by a committed OpenAPI document.
From flag to rollout
- Step 1
Create a flag
Pick a key and a type (boolean, string, number or JSON) and define its variations. The flag exists in every environment of the project, configured separately in each.
- Step 2
Target it
Add overrides for specific users or organizations, ordered rules on context attributes, segment membership and weighted percentage rollouts.
- Step 3
Publish
Saving the configuration publishes a new immutable snapshot of that environment. Production asks you to confirm before it changes.
- Step 4
SDKs pick it up
Each SDK polls delivery with the snapshot version it holds. A changed environment returns the new snapshot; an unchanged one returns 304.
Run it next to your app
Sign in to the dashboard, or clone the repository and start the whole stack locally with Docker and pnpm.