Evaluations under 5ms, always
Now with Claude Desktop MCP →

Release with confidence.

Safer deploys. Controlled releases. Kill switches ready.

Free plan · No credit card · Deploy in 5 minutes

<5ms
Flag evaluation
99.9%
Uptime
4+
SDK languages
Open
Source SDKs

Everything you need.
Nothing you don't.

Connect in minutes. Release with precision. Control every rollout without touching your deployment pipeline.

Evaluations under 5ms

Flags are resolved from an in-process Redis cache. The database is never touched on the hot path. Your users won't notice a thing.

🔄

Real-time propagation

Change a flag in the dashboard and your SDK knows about it in under a second — no polling, no deploys, no restarts. Pure SSE.

🔑

OpenFeature compatible

Drop our provider into any OpenFeature-compliant SDK. Switch flag tools without touching application code.

🌿

Partial rollouts

Roll out to a specific list of user IDs before going to everyone. Simple, auditable, reversible in one click.

📋

Audit log built in

Every flag state change is recorded — who changed it, what it was before, what it became. No extra setup.

👥

Role-based access control

Admin, Editor, and Read Only roles out of the box. A 50-person team won't give every engineer write access to production flags.

🔐

Org API keys

Generate long-lived API keys for CI pipelines and scripts. Each key carries a role — read-only, editor, or admin.

🤖

AI-native via MCPNew

The only feature flag tool your AI assistant can control directly. Ask Claude Desktop to toggle a flag mid-incident — no dashboard required.

Learn more →
Industry first

Your AI assistant can
control your flags.

Flagr is the first feature flag tool with a native MCP server. Ask Claude Desktop to toggle, inspect, or roll back any flag — directly, mid-incident, in plain English.

Claude Desktop — flagr MCP
YouWe're seeing errors in prod — disable the payments-v2 flag immediately.
Claude

Calling get_flag_state for payments-v2 in production…

state: partially_enabled · 3,241 tenants

Calling set_flag_state → disabled…

✓ payments-v2 disabled in production.

Done. The flag is off for all users. Want me to check the audit log to confirm the change was recorded?

🚨

Kill switches in plain English

During an incident, the last thing you want is to hunt through a dashboard. Tell your AI assistant what to do — it calls the right API instantly.

🔍

Inspect any flag without leaving your editor

Ask which tenants are in a partial rollout, pull the full audit log, or check state across all environments — without switching context.

🤝

Works with Claude Desktop & Cursor

One binary. One config line. Compatible with any MCP-capable AI assistant — Claude Desktop, Cursor, and more.

Install in 30 seconds:

go install github.com/flagr-dev/flagr-mcp@latest
View on GitHub →

Works in your language.

OpenFeature-compatible SDKs for TypeScript, Python, and Go. Kotlin coming soon.

$npm install @flagr-dev/sdk
import { FlagrClient } from "@flagr-dev/sdk";

const client = new FlagrClient(process.env.FLAGR_ENV_KEY);
client.connect();

if (client.isEnabled("new-checkout", req.user.id /* optional: omit for simple on/off */)) {
  showNewCheckout();
}

// fires immediately + on every change; tenantId optional for partial rollouts
const sub = client.onChange("new-checkout", req.user.id /* optional */,
  (enabled) => enabled ? showNewCheckout() : hideNewCheckout()
);
sub.unsubscribe(); // call when done
Connected · 3msflags cached locally · updates via SSE

Simple pricing.

Start free. When your team is committed, we'll talk.

Dev

Freeforever

For individuals and small teams. Open-source SDKs, no lock-in, no credit card.

Get started free
  • 3 projects
  • 2 environments per project
  • 3 flags per project
  • 3 team members
  • Role-based access control
  • Partial rollouts
  • Audit log
  • OpenFeature SDKs (TS, Go, Python)
  • Community support

Enterprise

Let's talk

For teams that are committed and need SLAs, invoicing, and a real partner.

  • Everything in Dev — unlimited projects, environments, flags & members
  • 99.9% uptime SLA
  • Priority support
  • Dedicated Slack channel
  • Invoicing & procurement
  • Custom contract

No per-seat fees. No credit card to start. Switch to Enterprise when you're ready.

Common questions.

What happens to flag evaluation if your service goes down?
Nothing — evaluation never touches our servers at runtime. The SDK connects once at startup via SSE, seeds a local in-memory cache, and evaluates entirely from that cache. If we go down, your app keeps running from the last known state. There is no single point of failure in your critical path.
How do we run multiple environments (dev / staging / prod) without flags leaking across them?
Environments are first-class in Flagr. Each environment gets its own SDK key and maintains its own flag state — enabling a flag in dev has zero effect on staging or prod. Your CI pipeline can target each environment independently via the Management API using org API keys.
How do we integrate flag state into our CI/CD pipeline?
Use the Management API with an org-scoped API key. You can script flag creation, enable flags as part of a deployment step, and disable them automatically on rollback. Common pattern: create the flag disabled, deploy, run smoke tests, then enable via API — all in the same pipeline job.
We run multiple instances of our service behind a load balancer. Does each instance maintain its own cache?
Yes, and that's by design. Each instance opens one SSE connection and maintains its own in-memory cache. Flag changes are published via Redis pub/sub and fan out to every connected instance within milliseconds. No shared memory, no coordination between instances — it scales horizontally without any changes to your infrastructure.
How do we handle flag debt and prevent stale flags from piling up?
Every flag change is recorded in the audit log with the actor, timestamp, and previous state. Flags are scoped to projects with immutable keys, so you can track exactly where each flag is used. The recommended practice is to treat each flag as a short-lived branch: create it for the feature, clean it up once the rollout is complete and the old code path is deleted.
What's the recommended rollout strategy when adopting feature flags for the first time?
Start with one service and one flag for a low-risk feature — something you'd normally ship behind a config value. Wire up the SDK, get comfortable with partial rollouts (targeting a list of internal user IDs first), then expand to external users. Once the pattern is established in one service, other teams can adopt it with the same SDK without touching your infrastructure.

Ship your first flag
in the next 10 minutes.

Free plan. No credit card. Works with your stack in minutes.