Targeting

By default, an environment serves every device the flag’s default. Targeting is how you serve something else to some devices: beta testers, a specific app version, 10% of everyone. This page explains the machine; the rollout guide walks you through using it.

Tags: what rules see

Rules test tags — small key/value facts about the device asking. The SDKs send a few built-in tags automatically (appVersion, appBuild, osVersion, platform, sdkVersion), and your app can add its own, like cohort: "beta".

Two things about tags are worth knowing early:

• Tags are evaluated and forgotten. FortressFlag uses them to answer the one request they arrived on, then discards them — they’re never stored and never logged. There is no tag history anywhere, by design.
• Tags are your app’s claims. A tag can carry anything your code puts in it — so don’t put secrets or your users’ personal data in tag values. Keep them to cohorts, versions, and configuration.

Rules: an ordered list, first match wins

Each flag + environment has an ordered list of rules. A rule is a group of conditions ANDed together — cohort is beta AND appVersion ≥ 2.0 — plus the value it serves on a match.

Evaluation is simple and worth internalizing:

1. Rules are checked top to bottom.
2. The first rule whose conditions all hold decides the value. Nothing below it is consulted — order is meaning, and you can reorder rules in the dashboard.
3. A condition on a tag the device didn’t send doesn’t hold. No tag, no match — the rule is skipped, never an error.
4. If no rule matches, the flag’s default serves.

A rule with no conditions always matches — that’s the “everyone else” shape you put at the bottom of a list.

Version comparisons

Conditions can compare versions: appVersion ≥ 2.0. Versions split on dots and compare numerically, left to right, and missing components read as zero — so 2.0 equals 2.0.0, and 2.10 is newer than 2.9. A device version that doesn’t parse as dotted numbers (say, 2.0-beta) simply makes the condition not hold. Pre-release suffixes aren’t supported — compare plain dotted versions.

Segments: a rule-piece you name and reuse

A segment is a named AND-list of conditions — beta-testers, internal-devices — that you define once for your whole organization and reference from rules across flags and environments. Edit the segment, and every rule using it follows.

That reach is exactly why editing a segment requires production-level permission: a segment referenced by a production rule changes production when it changes, whoever saves it.

Percentage rollouts

Any rule can carry a rollout percentage: instead of matching every device that passes its conditions, it matches only the first N% of them. That’s how “10% of beta testers” works — conditions first, percentage gate second.

Three properties make rollouts safe to rely on:

• Sticky. Whether a device is inside the percentage is computed from the device’s identity and the flag’s key — the same device gets the same answer on every request. Nobody flickers in and out of a rollout, and raising 10% to 20% keeps the original 10% in.
• Per-flag. The computation mixes in the flag key, so a 10% rollout on one flag and a 10% rollout on another catch different tenths of your fleet. There’s no permanently unlucky 10% of devices that gets every experiment at once.
• Nothing is stored. Cohort membership is pure arithmetic, recomputed per request — FortressFlag keeps no record of which devices are in which rollout. There’s nothing to leak and nothing to clean up.

Limits

Generous enough that you won’t usually meet them, fixed so payloads stay bounded: up to 20 rules per flag per environment, 5 conditions per rule (a segment reference counts as one and can hold up to 10 of its own), tag keys up to 64 characters, condition values up to 256.

Where to next

• Set up a percentage rollout — the task, step by step
• Environments and projects — targeting is per environment
• How flags reach your app — why devices never see your rules