---
title: "Feature Flags"
description: "Gate features in your backends and web frontends with flags, per-environment targeting, segments and percentage rollouts, evaluated through OpenFeature."
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.ezghcloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Feature Flags

EZGH Feature Flags turns features on and off in your backends and web pages without a deploy:
boolean and multivariate flags, targeting per environment (individual users, rules on context
attributes, reusable segments, percentage rollouts), and a version history of every change. Your
code evaluates flags through [OpenFeature](https://openfeature.dev), the CNCF's vendor-neutral
feature flag API, with EZGH's providers or any OpenFeature provider that speaks the OpenFeature
Remote Evaluation Protocol (OFREP).

- [Quickstart: Node, Bun and Deno](/flags/quickstart-node) — Create a flag and evaluate it in a backend.
- [Quickstart: browser and React](/flags/quickstart-browser-react) — Evaluate client-side flags in a web page.
- [Quickstart: Go](/flags/quickstart-go) — The server quickstart with the Go provider.
- [Quickstart: Python](/flags/quickstart-python) — The server quickstart with the Python provider.
- [Concepts](/flags/concepts) — Flags, variations, environments, configs and versions.
- [Targeting](/flags/targeting) — Individual targets, rules and their operators, and the default rule.
- [Percentage rollouts](/flags/rollouts) — Weights, bucketing, and rolling out by account.
- [Segments](/flags/segments) — Reusable audiences for rules.
- [Environments and SDK keys](/flags/environments-and-keys) — Server and client keys, and revoking them.
- [Any OpenFeature provider (OFREP)](/flags/ofrep) — Evaluate with OpenFeature's own OFREP providers, in any language.
- [IAM recipes](/flags/iam) — Staging-only editors, access by flag prefix, and denies.
- [Limits](/flags/limits) — Sizes, rate limits and quotas.

## Providers

EZGH's OpenFeature providers are open source (Apache-2.0) on GitHub. They aren't published to npm
or PyPI yet: install them from GitHub by tag. Server providers download the environment's flags
and evaluate them locally, with no network call per evaluation; the web provider evaluates on
EZGH's servers, so your rules never reach the browser.

| Language | Repository | Install |
| --- | --- | --- |
| TypeScript: Node, Bun, Deno, and the browser (React through OpenFeature's React SDK) | [ezgamehost/flags-provider-ts](https://github.com/ezgamehost/flags-provider-ts) | `npm install github:ezgamehost/flags-provider-ts#v0.1.0` |
| Go | [ezgamehost/flags-provider-go](https://github.com/ezgamehost/flags-provider-go) | `go get github.com/ezgamehost/flags-provider-go@v0.1.0` |
| Python | [ezgamehost/flags-provider-python](https://github.com/ezgamehost/flags-provider-python) | `pip install "git+https://github.com/ezgamehost/flags-provider-python@v0.1.0"` |

Other languages (mobile, Java, .NET) use OpenFeature's OFREP providers: see
[Any OpenFeature provider](/flags/ofrep).

## Hosts

| Host | What it serves |
| --- | --- |
| `https://flags.ezghcloud.com` | Evaluation: OFREP, and the snapshot and change streams providers use. Called with an [SDK key](/flags/environments-and-keys) |
| `https://flags-api.ezghcloud.com` | The [Feature Flags API](/flags-api): flags, targeting, history, environments, segments and SDK keys. Called with an API key or your console session |

The console's **Feature Flags** pages (in Application integration) and the `ezgh flags` commands use
the API.

## Permissions

| Action | Allows | Checked against |
| --- | --- | --- |
| `flags.flags.list` | List flags | Project |
| `flags.flags.get` | View a flag | Flag |
| `flags.flags.create` | Create flags | Project |
| `flags.flags.update` | Change a flag's name, description, tags, variations and client-side availability | Flag |
| `flags.flags.archive` | Archive and unarchive a flag | Flag |
| `flags.flags.delete` | Delete an archived flag | Flag |
| `flags.configs.get` | View a flag's targeting and history in an environment | Environment, with the flag's key as the path |
| `flags.configs.update` | Change or restore a flag's targeting in an environment | Environment, with the flag's key as the path |
| `flags.environments.list` | List environments | Project |
| `flags.environments.get` | View an environment | Environment |
| `flags.environments.create` | Create environments | Project |
| `flags.environments.update` | Change an environment | Environment |
| `flags.environments.delete` | Delete an environment, its targeting and its SDK keys | Environment |
| `flags.environments.export` | Export an environment's compiled flags | Environment |
| `flags.segments.list` | List segments | Project |
| `flags.segments.get` | View a segment | Segment |
| `flags.segments.create` | Create segments | Project |
| `flags.segments.update` | Change a segment | Segment |
| `flags.segments.delete` | Delete a segment no flag uses | Segment |
| `flags.sdkKeys.list` | List an environment's SDK keys (never the keys themselves) | Environment |
| `flags.sdkKeys.get` | View an SDK key's metadata | SDK key |
| `flags.sdkKeys.create` | Create SDK keys for an environment | Environment |
| `flags.sdkKeys.revoke` | Revoke an SDK key | SDK key |

| Managed policy | What it allows |
| --- | --- |
| `FlagsFullAccess` | Every `flags.*` action. |
| `FlagsReadOnlyAccess` | Every list and view action: flags, targeting and history, environments and their export, segments, and SDK key metadata (never a key). |

`ReadOnlyAccess` allows what `FlagsReadOnlyAccess` does. `AdministratorAccess` and the root user
can do all of these. Targeting is checked per environment and flag, so a policy can allow editing
in staging but not production: see [IAM recipes](/flags/iam).

## Resources

| Resource | Resource name |
| --- | --- |
| Flag | `ezgh:us-west-1:<org>:<project>:flg_<slug>` |
| Environment | `ezgh:us-west-1:<org>:<project>:fen_<slug>` |
| Segment | `ezgh:us-west-1:<org>:<project>:fsg_<slug>` |
| SDK key | `ezgh:us-west-1:<org>:<project>:fsk_<slug>` |

## Data

- **Evaluation contexts are never stored or logged.** They're evaluated and dropped, so Feature
  Flags keeps no list of your users beyond the targetingKeys you type into targets and segments.
- **SDK keys** are stored as a hash and their first 12 characters; a key is shown once, when it's
  created.

## Trails

Feature Flags' events have the event source `flags.ezghcloud.com`.

- **Recorded:** every API call, as the [rules for reads](/trails#what-trails-records) say. A
  targeting change records the flag's and environment's keys, the versions it went from and to,
  and its comment; never the targets or rule values. An SDK key's create records its ID and
  prefix, never the key.
- **Never recorded:** evaluations and streams on `flags.ezghcloud.com`.

Source: https://docs.ezghcloud.com/flags/index.mdx