Skip to main content
OmniFlags organises resources in three levels: projects group related flags, environments let you configure each flag independently per deployment stage, and applications hold the SDK keys that connect your code to a specific environment.

​
Projects

A project is a namespace for a set of related flags — typically a service, product area, or team. Every project has a key (e.g. checkout, product-listing). The key is set at creation and cannot be changed. It is the first segment of every flag reference in code: 
checkout.charge-delivery-fee
product-listing.show-promo-products
agent-app.enable-bulk-actions
mos.new-order-flow
Flags, environments, segments, and change history are all scoped per project. Members can be granted access at the project level independently of other projects.

​
Environments

Environments represent your deployment stages — development, staging, production, or whatever stages your workflow uses. Each flag is configured independently per environment. The same flag key can have completely different rollout percentages, targeting rules, and default values in each environment: 
checkout.charge-delivery-fee
├── development  disabled
├── staging      enabled, targeting: country = "Nigeria", rollout 10%
└── production   enabled, targeting: country = "Nigeria", rollout 100%

agent-app.enable-bulk-actions
├── development  enabled, rollout 100%
└── production   enabled, rollout 5%
The SDK key you use when initialising the provider determines which environment’s configuration is fetched. All flag evaluation for that SDK instance reflects that environment’s settings only.

​
Approvals

Environments can require approvals before flag changes take effect. When enabled, a submitted change enters a pending state and must be approved by a configured number of reviewers before it is published. This is typically enabled on production environments. Approval settings are configured per environment under Settings → Environments within a project.

​
Applications and SDK keys

An application represents a consumer of the flag distribution API — a web app, mobile app, backend service, or any other process that evaluates flags. Applications are managed at the organisation level under Applications in the dashboard. Each application is granted access to one or more project environments. Each grant produces an SDK key — a credential scoped to that application and environment pairing: 
Application: "ROS PWA"
├── checkout  /  production  →  pk_live_abc...
└── checkout  /  staging     →  pk_live_def...

Application: "ROS Native"
└── product-listing  /  production  →  pk_live_ghi...

Application: "Order Service"
└── checkout  /  production  →  pk_live_jkl...
Pass the SDK key to the provider when initialising the SDK: 
<OmniFlagsProvider sdkKey="pk_live_...">
  <App />
</OmniFlagsProvider>

​
Key management

SDK keys are shown once in the dashboard when created. Store them in environment variables and treat them as secrets. They grant read-only access to the flag snapshot — they cannot create, modify, or delete any resources. To rotate a key: revoke it and generate a new one. Instances holding the revoked key continue serving from their cached snapshot until their next refresh attempt, at which point the request will fail and the SDK will surface the error via its status hooks.