A feature flag is a switch that turns part of your product on or off for the people you choose, without shipping new code.
Kilden evaluates flags in a service built for that one job, and targets them with the same events, people and cohorts your analytics runs on.
Shipping code and turning it on are two decisions. Tie them together and every release is a bet, settled in front of everyone at once.
The code goes to production behind a flag that is off — deployed, reachable by nobody — until launching is a switch, not a Friday deploy.
Turning the flag off takes a click. Reverting, rebuilding and redeploying takes as long as your pipeline takes — while customers sit in the broken version.
Your own team, then a slice of traffic, then everyone. If the error rate moves, it moved for a fraction of the people.
None of this needs a long-lived branch, a release train, or a second copy of your infrastructure.
Created in the panel, evaluated in production, read from your code in a line.
On for the people who match your targeting, off for everyone else. The most common flag is also the most boring one.
Give a flag a list of variants instead of on and off, and your code reads back the variant name. One button spreads the weights evenly.
A rollout is a cut in a hash, not a queue. Raise it and the flag only ever adds people; nobody loses the feature because you moved the number.
One toggle turns a flag off for everybody, whatever the targeting says, and reaches the evaluation service within seconds. No deploy, no cache to bust.
A flag belongs to a project, and the project is the boundary: staging has its own flags and its own keys.
The first time a session reads a flag, an event records the value it got — so you can chart a rollout instead of trusting it.
A standalone flag tool knows an id and whatever properties you remembered to send, so the audience ends up as a pasted list somebody keeps true by hand.
Kilden is a customer data platform first, and the flag service reads the same people, events and cohorts as your funnels and campaigns. So an audience is a sentence about behaviour.
You build the audience once as a cohort, and the flag that gates the feature, the campaign that follows up and the funnel that measures it read the same definition.
Membership is recomputed from the events, so someone who came back yesterday drops out of “never came back” on its own.
Cohort membership is recomputed on a schedule, so it can be minutes behind. Right for targeting, wrong for anything that has to be true this second — for those, properties you pass in the request apply immediately.
One flag, twenty people, and the arithmetic that decides where each of them falls. Drag the rollout: the same person always lands on the same side.
The flag is on. People inside the rollout get this variant; everyone else gets the checkout you already ship.
Dot colour is the variant that person would get — an independent hash, so it does not track the rollout.
Every chip is one distinct id. Raise the rollout and chips only light up; lower it and the last in are the first out. These twenty sit evenly across the range, so the count follows the slider; a real twenty would wobble either side.
Shuffling changes the order they are drawn in and nothing else: each person keeps their side.
Illustrative: it reproduces the property the page claims — position depends only on the flag key and the id — not the hash the service computes.
Flag evaluation is its own service, and the only part of Kilden that a page load waits on. Here is everything it does.
At start-up the SDK sends your public key and the current distinct id, and gets every flag back in one response — inactive ones as false, so “off” is not “never heard of it”.
Whether someone falls inside a rollout is a hash of the flag key and their distinct id, mapped onto the line the percentage cuts. Same inputs, same answer.
No assignment table, no write on the read path. Raising a rollout extends the cut, which is why it only adds people. Variants come from a second hash.
After that first response, every flag read is a lookup in memory. The first read of each flag records the exposure.
The bucket depends on the distinct id, so when someone signs in and their anonymous id is replaced, a person right at the boundary can change sides. That is the price of evaluating with no stored state. The SDK reloads flags the moment identity changes.
Once a flag hands out named variants, the only thing missing is the arithmetic. An experiment is a lens over a flag you already have: choose the flag, choose the metric, read the result.
Conversion is counted only after the person was exposed, so a purchase from before they saw the change cannot be credited to it.
A split that does not match your weights, exposure too thin to conclude anything, anonymous traffic mixing with identified — the report names the problem and holds the verdict.
Add the SDK, initialise it with your public key, read the flag by its key. Flags load in the background, so gate the render on the callback.
Server-side SDKs evaluate the same flags with your secret key, and the endpoint is documented if you want to call it yourself. The secret key is rejected from a browser.
Read the flags guide →A flag request is one response that carries flags — not one per flag your code reads. The SDK asks once on load and answers every read from memory, so a page with fifty flags spends one request.
That is cheaper per flag than metering every read, which punishes any app with a lot of flags on one screen.
There is no meter counting flag requests and no line for them on an invoice. An allowance you cannot exceed is decoration, not a limit, so this page prints none. The day they are metered, the plan pages get the number first.
See what is billed →A switch in your code that turns something on or off for the people you choose, without shipping a new version. Both paths are deployed; the flag decides which one runs.
A flag decides who gets something. An A/B test measures what that did to a number you care about. In Kilden the test is a lens over a flag with variants: same assignment, same audience.
Reading one does not: the SDK loads every flag once, in the background, and each read after that is a lookup in memory. The service itself answers in single-digit milliseconds.
Create the flag, leave the targeting empty, set the rollout to ten percent. Everyone whose hashed distinct id falls under the cut gets it, and raising the number later only adds people.
Yes, and it is the reason to run flags on a customer data platform. A cohort such as “checked out twice and never came back” is defined once from your events and targeted directly.
Your app keeps running. A flag that never loaded reads as unknown, which the SDK reports as off, so your code takes the path it took before the feature existed.
Create a project, drop in the SDK, and ship the thing you were nervous about — to your own team first, then to whoever earns it. Flags are in the free plan.