OpenFeature-compatible

Feature flags that know when to roll back.

Flaggr ties every browser event to the flags that were on, measures each flag's real-user impact against control, and uses those signals to advance, pause or roll back staged rollouts — automatically.

Start free Read the docs

npm install @flaggr/sdk

MIT-licensed SDKs & CLI
Self-hosting on request
OFREP-compliant

checkout-v2 · serving

25% of AU → new

LCP · INP · CLS

treatment vs control

Stage 3 of 5 · 25%

guardrails healthy

How it fits

Three layers. One path to production.

The mark is the architecture: a control plane where changes are made and approved, services that own their flags, and a Go data plane that answers every evaluation.

Control plane
Console & API
Define flags, targeting, environments and rollout plans. Every change is validated, versioned, audited and — in protected environments — held for approval.
- Console
- REST API
- Versioning
- Audit log
Services
Where flags live
Each project has services — web-frontend, api-server — with their own flags, scoped tokens and per-environment config, promoted from development to production.
- Environments
- Scoped tokens
- Import / export
Data plane
Evaluation, in Go
flaggr-api evaluates from an in-memory snapshot kept fresh by Postgres notifications — sub-millisecond per evaluation — and streams changes to SDKs.
- REST
- OFREP
- Connect-RPC
- gRPC-Web
- SSE

Latency by evaluation mode is published in the performance guide.

The platform

Flags, real-user signal and rollouts — stacked, not stitched.

Most teams glue a flag service, an analytics tool and a deploy pipeline together by hand. In Flaggr they are layers of one system, joined by the flag key.

Feature flags

Target precisely. Change it live.

Rules, variants and percentage splits per environment, evaluated the same way over every protocol and pushed to connected SDKs the moment you save.

16 targeting operators, reusable cohorts and percentage rollouts
Boolean, string, number and object flags with typed SDK accessors
Separate config per environment, promoted development → production
Changes stream to SDKs over SSE — no redeploys, no polling lag

Targeting rules

web-frontend/Flags/checkout-v2

production

checkout-v2

string · variants classic, new

Serving

developmentstagingproduction

1
IF plan in proenterprise
serve new
2
IF country equals AU
25% new75% classic
·
DEFAULT serve classic

Changes stream to connected SDKs over SSE

Browser analytics

See what each flag does to real users.

A lightweight script records Web Vitals, errors and interactions — and every event carries the flag set that was active in that browser. Impact is split by variant automatically.

Under 5 KB gzipped, no cookies, no PII, respects Do Not Track
LCP, INP, CLS, TTFB and FCP with element attribution
Per-flag p75 vitals, errors and frustration signals — treatment vs control
The same signals feed rollout guardrails and the MCP server

Browser analytics

web-frontend/checkout-v2/Impact

Example data

Real-user impact

new vs classic

Metric	Control	Treatment	Δ
LCP p75	2.41 s	2.18 s	−9.5%
INP p75	184 ms	176 ms	−4.3%
CLS p75	0.06	0.11	+0.05
JS errors per 1k sessions	3.2	3.3	+0.1

{ type: "webvital", data: { metric: "LCP" }, flags: { "checkout-v2": "new" } }

Automated rollouts

Rollouts that drive themselves — and stop themselves.

Pick a plan, set soak times and guardrails, and let the engine advance stage by stage. If error rate or latency breaches a threshold, it pauses or rolls back without waiting for a human.

Canary, staged, linear and ring strategies
Soak time per stage and manual approval gates
Guardrails on error rate and latency: pause or roll back
Every engine decision recorded in the audit log

Progressive rollouts

Releases/checkout-v2

Active

Automated rollout · staged · production

Stage 3 of 5 · soaking

Canary · 1%
soaked 30m
Early · 5%
soaked 1h
Quarter · 25%
soaking · 2h
Half · 50%
approval
Full · 100%
final

Error rate · roll back if > 2.0%

0.4%

p99 latency · pause if > 100 ms

84 ms

Advances automatically when the soak completes and guardrails stay healthy

Release pipeline

Every stage earns the next one. Or it rolls back.

A plan is a path of stages. The engine ticks through it: a stage only advances once its soak time has elapsed, its guardrails are healthy and — where you asked for one — an approver has signed off.

1%
Canary
soak 30m
5%
Early
soak 1h
25%
Quarter
soak 2h
50%
Half
approval
100%
Full
final

Staged walks through fixed percentages. Each stage has its own soak time; gated stages wait for an approver.

Error rate · Quarter · 25%

rolled back

threshold 2.0%

stage startedbreach → rollback

Decision log

Every engine decision and human approval, in the audit log

Rollout rolled back
guardrail action: rollback
rollout.rolled_back · system:rollout-engine
Guardrail breached
error_rate 3.1% exceeds 2.0%
rollout.guardrail_breached · system:rollout-engine
Stage advanced · Quarter 25%
soak complete, guardrails healthy
rollout.stage_advanced · system:rollout-engine
Stage approved · Early 5%
manual approval gate
rollout.stage_approved · alice@example.com

Soak times
Each stage holds for its soak window before the engine considers moving on.
Approval gates
Mark any stage as approval-gated; risky production starts can require an independent approver.
Guardrails
Thresholds on error rate and p99 latency, each with its own action: pause or roll back.
Decision log
Advances, breaches, pauses and approvals are written to the audit log with the actor.

For developers

Wire it in with the SDK you already use.

Type-safe SDKs for TypeScript and React, Go and Python — and any OpenFeature SDK through OFREP. The same flag answers over REST, Connect-RPC, gRPC-Web and SSE.

Streaming updates
SSE push keeps SDK caches current; sync reads resolve locally from the streamed config.
OpenTelemetry built in
An OTel plugin for the TypeScript SDK and tracing across control and data plane.
Open-source SDKs and CLI
MIT-licensed at github.com/flaggr-dev, with the Terraform provider. Use the hosted tier; self-hosting is available on request.

Quick start

npm install @flaggr/sdk

checkout.ts

import { createFlaggr } from '@flaggr/sdk'const client = createFlaggr({  serviceId: 'web-app',  apiKey: 'fgr_your_token',  updateMode: 'stream', // SSE push, no polling})const isEnabled = await client.getBooleanValue('checkout-v2', false)

npm install @flaggr/sdk

Checkout.tsx

import { FlaggrProvider, useBooleanFlag } from '@flaggr/sdk/react'function App() {  return (    <FlaggrProvider config={{ serviceId: 'web-app', apiKey: 'fgr_xxx' }}>      <Checkout />    </FlaggrProvider>  )}function Checkout() {  const useNewFlow = useBooleanFlag('checkout-v2', false)  return useNewFlow ? <CheckoutV2 /> : <CheckoutClassic />}

go get github.com/flaggr-dev/flaggr-go@latest

main.go · flaggr-go

import (	"context"	"log"	"os"	flaggr "github.com/flaggr-dev/flaggr-go")client, err := flaggr.NewClient(	flaggr.WithAPIKey(os.Getenv("FLAGGR_TOKEN")),	flaggr.WithServiceID("web-app"),)if err != nil {	log.Fatal(err)}defer client.Close()enabled, _ := client.Boolean(context.Background(), "checkout-v2", false,	flaggr.EvalContext{TargetingKey: "user-123"})

Or through OpenFeature, with its OFREP provider:

go get github.com/open-feature/go-sdk github.com/open-feature/go-sdk-contrib/providers/ofrep

main.go · OpenFeature + OFREP

import (	"context"	"log"	"os"	"github.com/open-feature/go-sdk-contrib/providers/ofrep"	"github.com/open-feature/go-sdk/openfeature")provider := ofrep.NewProvider("https://api.flaggr.dev/api",	ofrep.WithBearerToken(os.Getenv("FLAGGR_TOKEN")),	ofrep.WithHeader("X-Service-Id", "web-app"),	ofrep.WithHeader("X-Environment", "production"), // OFREP's default is development)if err := openfeature.SetProviderAndWait(provider); err != nil {	log.Fatal(err)}client := openfeature.NewClient("web-app")enabled, _ := client.BooleanValue(context.Background(), "checkout-v2", false,	openfeature.NewEvaluationContext("user-123", nil))

pip install "flaggr @ git+https://github.com/flaggr-dev/flaggr-python@v0.1.1"

app.py · flaggr

import osfrom flaggr import FlaggrClientclient = FlaggrClient(    api_key=os.environ["FLAGGR_TOKEN"],    service_id="web-app",)enabled = client.get_boolean("checkout-v2", default=False, context={"targeting_key": "user-123"})

Or through OpenFeature, with its OFREP provider:

pip install openfeature-sdk openfeature-provider-ofrep

app.py · OpenFeature + OFREP

import osfrom openfeature import apifrom openfeature.contrib.provider.ofrep import OFREPProviderfrom openfeature.evaluation_context import EvaluationContextapi.set_provider(OFREPProvider(    "https://api.flaggr.dev/api",    headers_factory=lambda: {        "Authorization": f"Bearer {os.environ['FLAGGR_TOKEN']}",        "X-Service-Id": "web-app",        "X-Environment": "production",  # OFREP's default is development    },))client = api.get_client()enabled = client.get_boolean_value("checkout-v2", False, EvaluationContext("user-123"))

terminal

curl -s https://api.flaggr.dev/api/flags/evaluate \  -H "Authorization: Bearer fgr_your_token" \  -H "Content-Type: application/json" \  -d '{"flagKey":"checkout-v2","serviceId":"web-app"}'# { "flagKey": "checkout-v2", "value": true,#   "reason": "TARGETING_MATCH", "variant": "enabled" }

go install github.com/flaggr-dev/flaggr-cli/cmd/flaggr@latest

Prebuilt binaries for macOS, Linux and Windows come with releases from v0.5.0 on: see the CLI docs.

terminal

flaggr login              # opens the browser to sign inflaggr flags list --project <project-id>flaggr eval bool --key checkout-v2 --service web-app

Try it

Flip a demo flag.

This playground evaluates its demo flags live with Flaggr's evaluation engine. Toggle a flag and watch the preview and the SDK call update.

Governance & agents

Governed for people. Operable by agents.

Roles, change requests and a full audit trail keep production changes deliberate — and the same guard rails apply when an AI agent is the one making the change.

Governance

Project roles, protected environments that turn edits into change requests, and an audit log of who changed what.

Change request

Awaiting approval

Toggle checkout-v2 on in production

Protected environment · needs an admin to approve

Owner
full control, transfer & delete
Admin
members, tokens, settings
Member
create, update & toggle flags
Viewer
read-only, incl. audit logs

Audit log

flag.togglealice@example.comcheckout-v2 → on
rollout.approval_appliedsam@example.comHalf · 50%
member.role_changesam@example.comjo: member → admin
token.rotateci-botread token · web-frontend

Roles & permissions

MCP server & agent skills

@flaggr/mcp-server gives Claude, Cursor and other MCP clients 60+ token-scoped tools — evaluate, toggle, run canaries, read impact and audit.

claude_desktop_config.json

{  "mcpServers": {    "flaggr": {      "command": "npx",      "args": ["-y", "@flaggr/mcp-server@latest"],      "env": { "FLAGGR_API_TOKEN": "fgr_your_token_here" }    }  }}

Needs @flaggr/mcp-server 0.3.0 or later: earlier versions can run shell commands taken from a crafted login URL. Until npm view @flaggr/mcp-server version prints 0.3.0 or later, connect to the hosted server at https://flaggr.dev/mcp instead.

evaluate_flag
toggle_flag
start_canary_rollout
advance_canary_stage
check_and_rollback_flag
get_flag_rum_impact
get_audit_log

agent skills

npx @flaggr/skills   # skills: .agents · .claude · .devinnpx @flaggr/plugin   # plugin for Claude Code & Codex: skills + MCP

MCP server guide

Questions

Frequently asked

Is Flaggr open source?

Partly. The TypeScript, Go and Python SDKs, the CLI and the Terraform provider are MIT-licensed and public at github.com/flaggr-dev. The source code of the platform itself (the Next.js control plane, the Go data plane and the Helm chart) isn't public: self-hosting is available on request, or use the hosted tier.

Does Flaggr work with OpenFeature SDKs?

Yes. Flaggr is OFREP-compliant — any OpenFeature SDK with OpenFeature's OFREP provider (TypeScript, Go, Python, Java and more) evaluates Flaggr flags at /api/ofrep/v1. Flaggr's own TypeScript, Go and Python SDKs don't need OpenFeature.

Can I self-host Flaggr?

On request. The platform's source isn't public, and there's no public container image or Helm chart: email hello@flaggr.dev to arrange self-hosting, or use the hosted tier.

What protocols does Flaggr support?

REST, Connect-RPC, gRPC-Web, OFREP, and SSE for real-time push. The same flags are addressable over every protocol — pick per-client.

How does Flaggr compare to LaunchDarkly or Flagsmith?

Honest comparisons live at /compare — Flaggr leads on protocol breadth; LaunchDarkly leads on enterprise workflow features, and Flagsmith on remote config for non-engineers.

Can AI agents manage flags?

Yes — the @flaggr/mcp-server package exposes flag list/toggle/evaluate/health as MCP tools, so agents like Claude or Cursor can operate flags with scoped tokens.

Ship the change. Keep the evidence.

Start on the free tier, or ask us about self-hosting. OpenFeature-compatible from day one — no lock-in.

Start free SDKs on GitHub

Feature flags that know when to roll back.

Three layers. One path to production.

Control plane

Services

Data plane

Flags, real-user signal and rollouts — stacked, not stitched.

Target precisely. Change it live.

See what each flag does to real users.

Rollouts that drive themselves — and stop themselves.

Every stage earns the next one. Or it rolls back.

Soak times

Approval gates

Guardrails

Decision log

Wire it in with the SDK you already use.

Streaming updates

OpenTelemetry built in

Open-source SDKs and CLI

Flip a demo flag.

Governed for people. Operable by agents.

Governance

MCP server & agent skills

Frequently asked

Is Flaggr open source?

Does Flaggr work with OpenFeature SDKs?

Can I self-host Flaggr?

What protocols does Flaggr support?

How does Flaggr compare to LaunchDarkly or Flagsmith?

Can AI agents manage flags?

Ship the change. Keep the evidence.