Skip to content
FortressFlag Docs

Keys

FortressFlag has two kinds of keys, and they’re opposites on purpose. Knowing which is which — and treating each accordingly — is most of what there is to know.

Client keys: ffc_ — public by design

Section titled “Client keys: ffc_ — public by design”

A client key authenticates the client plane: your iOS, Android, and web apps. It ships inside every copy of your app, and anyone with your binary or your page source can read it out. The design assumes that. A client key:

  • is read-only, scoped to one project and one environment
  • can only fetch a single device’s evaluated values — never your rules, never another device’s data, never anything from the management API
  • is rate-limited per key and per device

So put it in your app config with a clear conscience. What someone learns by holding your client key is your flag keys for one environment — which they could already read out of the binary the key came in. The ffc_ prefix exists so secret scanners can recognize it as a client key and not wake anyone up.

Server keys: ffs_ — a genuine secret

Section titled “Server keys: ffs_ — a genuine secret”

A server key authenticates the server plane: your own backend downloading the full ruleset — targeting rules included — for local evaluation. Treat it exactly like a database password:

  • store it in a secret manager or an environment variable
  • never in client-side code, never in a repository, never in a log
  • the ffs_ prefix is there so a leak scanner classifies it as a real secret that should page somebody — the exact opposite of ffc_, which is why the two share no prefix

A server key is also scoped to one project and one environment, is read-only, and can’t reach the management API. But its blast radius on a leak is your targeting rules, not just your flag keys — hence the different handling.

Minting, revealing once, revoking

Section titled “Minting, revealing once, revoking”

Keys are managed from each project’s SDK keys screen (Admins and Owners mint and revoke; Developers can view the list):

  • Minting creates a key bound to one project + environment. The full key is revealed exactly once, at mint time — copy it then, because afterwards the list shows only enough to identify it. There’s no “show key again”: a key that can be re-displayed is a key stored in a form that can be stolen.
  • Revoking takes effect on the key’s next use — no app release, no deploy. And it’s safe to do under pressure: SDKs holding a revoked key fall back to their cache rather than break.

Rotation

Section titled “Rotation”

Several live keys per environment are legal, and that’s the rotation recipe: mint the new key, roll it out to your apps or servers, then revoke the old one. No downtime, no flag-serving gap, and the window where both keys work is yours to control.

Where to next

Section titled “Where to next”