Architects
One toggle service for every application.
Your applications depend on OpenFeature, the CNCF's vendor-neutral feature-flag API — not on FTF. FTF implements OpenFeature's Remote Evaluation Protocol (OFREP), so Java, .NET, Go, Python, Node and browser applications use OpenFeature's own SDKs, with no FTF library to adopt, version or patch.
- On the open standard — FTF implements OpenFeature's remote-evaluation protocol (OFREP), so Java, .NET, Go, Python, Node and browser applications use OpenFeature's own SDKs. No FTF library to adopt, and your code isn't tied to FTF or to a toggle vendor. Open standards
- The same answer on every platform — every way of evaluating a toggle, connected or offline, passes one shared set of test cases. Same answers everywhere
- Local development without a local server — a developer's toggles file serves the OpenFeature apps on their laptop, one way, visible to no one else. Integration patterns
- Your identity provider decides who can switch what, per environment — no users kept in FTF. Security & access
- Your choice of store — FTF, or the LaunchDarkly or ConfigCat account you already have. Where toggles live
- Promoted like code — test, then UAT, then production, with a preview of every change. Promotion
Connected, offline, or on a developer's laptop
| Situation | How the application evaluates | Where the toggles come from |
|---|---|---|
| Connected — test, UAT, production | OpenFeature's SDK with its OFREP provider, in any language. Or one plain HTTP call, or FTF's small JavaScript and Python clients. | FTF, per environment — the environment's client key selects it. |
| Browser applications | OpenFeature's web SDK: it fetches all of the application's toggles for the user once, then answers locally and refreshes when they change. | FTF, with a key restricted to that application — a key in a web page is public. |
| A developer's laptop, connected | The same OpenFeature setup as in production, pointed at FTF with the developer's own local key. | The toggles file in the developer's repo, uploaded to FTF one way as they edit it. No local server to run. |
| Offline — a laptop without network, CI, unit tests | An in-process evaluator reading the toggles file: JavaScript and Python today, Java as source code (a packaged library is coming). | The toggles file committed with the code. |
Local development without a local server
Developers keep toggles in a file in their repository and edit it with FTF's own screens. For OpenFeature applications on the laptop, each save uploads that file to FTF, one way, under a key only that developer holds. FTF then answers their applications from their file — and only from it. Nothing appears in any shared environment, and nothing flows back into the repository.
Unused uploads expire after 30 days; the next save recreates them.
The same code in every environment
What changes between a laptop, test and production is configuration the environment supplies — FTF's address and a key — never the code. A release moves through your environments without a code or configuration change.
An application declares its name on every call, and FTF answers only for that application's toggles and for releases, which span applications.
See it with your own stack
The trial gives you an environment and a key: point an OpenFeature SDK in the language you use at it and switch a toggle.