How it works
How it works
A flag change becomes a new immutable snapshot of the environment. SDKs pick it up on their next poll and evaluate it in memory.
- 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.
- Step 5
Evaluate locally
The SDK evaluates the flag for each context in memory and returns the value with a reason: override, rule match, fallthrough, off or error.
- Step 6
Restore if needed
Every change is in the audit log and the version history. Restoring an earlier version creates a new version, so history is never rewritten.
Why snapshots
Immutable
Each published snapshot has a version number and never changes. A historical snapshot can be fetched by version, and the SDK never moves to a lower version than the one it holds.
Validated before use
The SDK parses and validates a snapshot before it replaces the current one. A bad snapshot is rejected and the previous one keeps serving.
Last known good
An initialized client keeps evaluating from memory during a delivery outage. With a cache file it also survives a restart while delivery is unreachable.
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.