Turn on by rules, turn off in one action.
A feature flag serves a value to your server code: open a feature to a share of visitors, reserve it for certain customers, set a threshold, load a configuration. It can follow a running test, and can be turned off everywhere at the first problem.
- Boolean, text, number, or JSON
- No rules in your pages: read with a secret key
- Pay in 3 installments
paiement-3-foisBooleanOn1 rule, then based on the A/B test “Pay-in-3 option highlighted” (A (original): Off; B: On) - Photos in reviews
avis-photosBooleanOn2 rules, then 25% On; everyone else: Off - Instant search
recherche-instantaneeBooleanOffOff: serves Off everywhere - Free-shipping threshold
seuil-livraison-offerteNumberOnNew threshold (60) - Black Friday banner
bandeau-black-fridayJSONDraftServed to no one until it’s turned on. - Recommendations on the product page
recommandations-ficheBooleanOnBased on the A/B test ““You may also like” recommendations” (A (original): Off; B: On) - Old search engine
ancien-moteur-rechercheBooleanOffOff: serves Off everywhere
Read the transcript
Release a feature to a few customers, and turn it off if it breaks? A feature flag serves a value to your server code, without redeploying.
Rules are read in order. For “Instant search”, each visitor goes down the stack: flag off, specific IDs, attributes, default rule. The first one that applies decides.
The share only goes up. “Photos in reviews” went from 10% to 25% of visitors. Bucketing uses the visitor ID, so an exposed visitor stays exposed.
Your servers read the value locally. The server client reloads the configuration every 60 seconds. If Probant doesn’t respond, your code gets the default value it passed.
Off everywhere within a minute. Nov 9, 06:42 PM: JavaScript errors up on Safari. The “off” value goes out immediately through the API, and reaches your servers within 60 seconds.
These feature flags and their rules are in the demo, no sign-up needed.
Serve the right value, without redeploying.
The visuals come from the demo store’s feature flags, worded as in the app.
Rules read in a known order.
A flag that is off serves its “off” value. Otherwise, individual IDs come first, then attribute rules, in order: the first one that applies decides. The default rule serves everyone else.
Attributes come from your server: plan, country, app version, number of orders. Nothing is inferred from the browser, and a missing attribute meets no condition.
- Each rule serves a fixed value, a percentage, or a test’s variant
- All conditions in a rule must be met
- If the flag is offOff
- ID is one of equipe-maison-luneOn
- If app-version version ≥ 4.2.0 and country is in the list FR, BE25% On; everyone else: Off
- If orders number ≥ 3On
- Otherwise (default rule)Off
app-versioncountryordersA percentage that only goes up.
The draw uses the identifier, with the same hashing as test assignment: a visitor gets the same value on all your servers. For “Photos in reviews”, the share went from 10% to 25%; at each increase, visitors already exposed kept it.
- A lower share is rejected on save, because exposed visitors would switch values
- To go back, turn the flag off or serve a fixed value
A flag can follow a running test.
The “Pay in 3 installments” flag returns the value tied to the visitor’s variant in the “Pay-in-3 option highlighted” test. The variant comes from the same assignment as the script: holdout, slices, weights, and consent included. With the probant_id cookie, your server gets the same variant as the page.
Outside the test, the original’s value is served and nothing is counted. Exposures sent by your server are checked, with the variant recomputed, and a visitor also seen by the script counts only once. The results stay those of the test.
- A test with an audience or a trigger is decided in the browser, so a flag can’t follow it
equipe-maison-luneOnindividual ID, before the testThe kill switch needs no approval.
“Turn off everywhere” serves the “off” value without asking an editor or owner for approval: it is a safety action. Served right away by the evaluation API, and by server SDKs at their next refresh: 60 seconds at most with the default setting.
The “Instant search” flag was turned off on Nov 9, 06:42 PM by Inès Martin: JavaScript errors up on Safari.
- Turning a flag back on follows the same rule as a launch
- Every kill is recorded in the audit log: who, when, why, value served
On Slack or by webhook if the workspace has chosen it; the kill is recorded in the audit log.
With the server client, your site doesn’t wait for Probant.
The server client reloads the configuration every 60 seconds by default and evaluates each flag locally, with no call per request. If Probant doesn’t respond, the last configuration is used; without one, your code gets the default value it passed. No method throws an error.
This client is part of the server helper, the @probant/edge package. For PHP, Python, Ruby, or Go, the evaluation API answers each call and serves a kill immediately.
- Secret key only: the configuration your pages read contains no flags, rules, or values
- Attributes passed for evaluation are neither stored nor logged
- A request coming from a web page is rejected
const flags = createFlagClient({ key: process.env.PROBANT_SECRET_KEY, // management key, read role endpoint: "https://getprobant.com", }); const actif = await flags.boolean("paiement-3-fois", false, { id: visiteur, // probant_id cookie or account ID attributes: { plan: "pro" }, }); // if Probant doesn’t answer: false, the default passed in
In detail.
- Types
- Boolean, text, number, and JSON; 2 to 10 values per flag, up to 8 KB for a JSON value.
- States
- Draft, on, off, and archived. A new flag starts in draft and is served to no one; once archived, it keeps its history.
- Rules
- Up to 50 rules of up to 10 conditions each, all required; up to 1,000 individual IDs.
- Operators
- “equals”, “is in the list”, “contains”, “starts with”, “number ≥”, “number ≤”, “version ≥”, and “version ≤”.
- Context
- An identifier of up to 128 characters and 50 attributes: text of up to 256 characters, number, or boolean. Neither stored nor logged.
- Refresh
- The server client reloads the configuration every 60 seconds by default and evaluates locally; the evaluation API serves each change immediately.
- Rate limit
- 6,000 requests per minute per key for configuration, evaluation, and exposures.
- Who can do what
- Prepare feature flags: owner, editor, and contributor; a contributor’s live change becomes a request. Turn feature flags on and off: owner and editor. If the workspace requires launch approval, every live change waits for another member, except a kill.
- Management
- From the app, the management API, or the MCP server: create, edit, turn on, turn off, archive. Turning on or off through MCP requires explicit confirmation. Every change is recorded in the audit log.
Frequently asked questions.
How is this different from a rollout?
A rollout scales up a test’s winning variant in steps, with guardrails and automatic rollback. A feature flag serves a value to your code (a feature, a threshold, a configuration), and you are the one who turns it off. A flag that follows a test also follows its rollout.
Can flags be read in the browser?
No: your pages’ script reads no flags, and the public configuration contains none. Flags are read on your server, through the server client or the evaluation API.
What does my code get if Probant doesn’t respond?
The last configuration read, kept in memory. At startup, without a configuration, the default value your code passes on each read. Evaluation doesn’t throw an error.
Do I need one flag per environment?
A flag applies to the whole workspace. To separate staging from production, use one workspace per environment.
Next: Learnings library
See this feature in the demo, on the screen this page describes, or move on to the next one.
- Open demo, no sign-up
- Free to start, no overage charges
- Database and compute in Amsterdam, with Scaleway