# Creating Flags

Create and publish a release toggle, a multi-variant flag or a remote config in the dashboard, and issue server API keys

Open a project and choose Feature Flags in the sidebar
(`/{org}/{project}/feature-flags`). The page has two tabs: Flags and
Server API keys. Anyone who can edit the project can change flags; no new
roles are involved.

## Step by step

Name and key

Press New feature flag. Enter a Name and a Key. The key is what
your code asks for: lowercase letters, digits, `_` and `-`, starting with a
letter, 1 to 128 characters, unique in the project. It cannot be changed
after creation.





Keep it active

Leave Flag is active on. Turning it off later makes the flag answer
`false` everywhere on the next request, without deleting it. That is the
kill switch.





Choose the kind

Release toggle, Multiple variants or Remote config. See
[the three kinds](../docs/feature-flags-overview.html#three-kinds-of-flag) if you are unsure.





Variants (multiple variants only)

Keep or rename `control` and `test`, add more if you need them, and set the
split. It must add up to exactly 100 %, with up to two decimals. Each
variant can carry its own JSON payload. Variant keys lock once saved.





Payload

Optional for a toggle (returned only when the flag answers `true`),
required for remote config, not allowed at the top level of a variant flag.
The editor checks the JSON as you type and shows the size against the 32 KB
limit.





Activation conditions (toggles and variants)

Add a condition set, pick properties (country, device, language, platform,
visit type, current URL, query string or a user property) and set
Roll out to a percentage. For variant flags, a set can instead
Serve a specific variant to everyone it matches, for example mobile
visitors always get `compact`.





Delivery

Choose Public (readable from the browser) or Private (servers with
a key only), and add selector groups if you want to load several flags by
group name.





Create and publish

The flag appears in the list with Published once it is at the Edge, or
Publish failed with the error and a Retry button. The dialog also
shows a ready-to-copy SDK snippet for the flag.








Public means readable by anyone

A public flag’s key and payload arrive in the visitor’s browser and are visible
in DevTools. Put secrets in neither kind of flag: private flags are not a
secrets manager either.

## Examples by kind

Release toggle



Goal | 
Condition set | 





Ship a feature gradually | 
No properties, Roll out to 5 %, then 25 %, 50 %, 100 % | 



Launch in one market first | 
Country equals US, roll out to 10 % of US visitors | 



Let your own team try it first | 
User property `plan` or `email` (sent in `userContext`), roll out 100 % | 



Kill switch | 
Turn Flag is active off | 








Multiple variants



Goal | 
Setup | 





Try two or more layouts | 
Variants `control` 50 % and `compact` 50 %, each with its layout settings as payload | 



Test copy or prices | 
One variant per headline or price; each payload holds the text or number | 



Give one segment a fixed version | 
A condition set such as Device is mobile with Serve a specific variant | 








A condition set decides who is in the test and how many of them (its
rollout). The split decides which variant each of them sees.


Remote config
Remote config has no conditions and no rollout, so it needs no user token.
Change the JSON, press save, and the next request gets it.





Goal | 
Example payload | 





Change a banner without a deploy | 
`{ "banner": { "text": "Free shipping over $75" } }` | 



Tune a threshold | 
`{ "free_shipping_threshold": 75 }` | 



Switch navigation or theme | 
`{ "navigation": "compact", "theme": "ocean" }` | 








Toggle with a payload, or remote config?

Use a toggle when only some users should get the settings, or when you need a
kill switch. Use remote config when everyone gets the same settings.

## What one save does

There is no separate publish step. Create, update and delete each run the same
sequence inside a per-project lock: validate, save the flag with its version
raised by one, rebuild the whole project snapshot, write it to the Edge,
and record the publish status. If the Edge write fails, the flag shows
Publish failed, its previously published version stays live, and nothing is
half-written. Deleting a flag is permanent: Coframe republishes without it,
then removes it, and the key can be reused.

## Server API keys

Server keys let your backend read private flags. On the
Server API keys tab press New Server API key, give it a name, and copy
the token. It is shown in full exactly once and looks like
`cffs_v1_<keyId>_<secret>`. Coframe stores only a SHA-256 hash of it.



- A key belongs to one project and can only evaluate flags. It cannot call the
management API or change anything.


- A project can have several keys. Create one per service or environment so
each can be revoked alone.


- Revoke switches the key off at the Edge first, so a revoked key stops
working on the next request.


- Keep keys server-side: never in a browser bundle, logs, source control, or a
`NEXT_PUBLIC_*` / `VITE_*` variable. A key pasted into a chat or a ticket
should be rotated.