Open source · 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
Self-host with Helm
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, self-hostable
Docker, Cloud Run or the Helm chart for Kubernetes — or use the hosted tier.

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/flaggr-go

main.go

client, err := flaggr.NewClient(    flaggr.WithAPIURL("https://flaggr.dev"),    flaggr.WithServiceID("web-app"),    flaggr.WithAPIKey("fgr_your_token"),)if err != nil {    log.Fatal(err)}defer client.Close()enabled, err := client.Boolean(ctx, "checkout-v2", false, flaggr.EvalContext{    TargetingKey: "user-123",})

pip install openfeature-sdk openfeature-provider-ofrep

app.py · OpenFeature + OFREP

from openfeature import apifrom openfeature.contrib.provider.ofrep import OFREPProviderapi.set_provider(OFREPProvider(    base_url="https://api.flaggr.dev/api/ofrep",    headers={        "Authorization": "Bearer fgr_your_token",        "X-Service-Id": "web-app",    },))client = api.get_client()enabled = client.get_boolean_value("checkout-v2", False)

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" }

curl -fsSL https://raw.githubusercontent.com/skunkworq/flaggr/main/scripts/install.sh | sh

terminal

flaggr login              # opens the browser to sign inflaggr flags list --service web-appflaggr eval checkout-v2 --bool

Try it

Flip a real flag.

This playground evaluates against Flaggr's live evaluation API. 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"],      "env": { "FLAGGR_API_TOKEN": "fgr_your_token_here" }    }  }}

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          # .agents · .claude · .devin/plugin marketplace add flaggr/flaggr/plugin install flaggr      # Claude Code: skills + MCP

MCP server guide

Questions

Frequently asked

Is Flaggr open source?

Yes — MIT licensed. The full stack (Next.js control plane, Go data plane, SDKs, CLI, Helm chart) is on GitHub. You can self-host everything or use the hosted tier.

Does Flaggr work with OpenFeature SDKs?

Yes. Flaggr is OFREP-compliant — any OpenFeature SDK pointed at /api/ofrep/v1 works, and first-party providers exist for TypeScript, Go, Python, and Java.

Can I self-host Flaggr?

Yes — the Helm chart deploys the whole stack to Kubernetes. You need Postgres and Redis; the control plane runs anywhere Next.js does.

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, built-in observability (OTel + Grafana), and self-hosting; the incumbents lead on enterprise workflow features.

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 self-host the whole stack. OpenFeature-compatible from day one — no lock-in.

Start free Star 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, self-hostable

Flip a real 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.