Introducing Flaggr

We're excited to announce Flaggr, an open-source feature flag management platform built for modern engineering teams.

Why We Built Flaggr

Every engineering team eventually reaches the same inflection point: the feature they shipped last Tuesday broke production for 10% of users, and rolling back means reverting three other unrelated changes that went out in the same deploy. Feature flags solve this, and the concept is well understood. So why build a new platform?

We built Flaggr because the existing options fell into two unsatisfying camps. On one side, proprietary SaaS platforms like LaunchDarkly and Split deliver polished experiences, but at $10+/seat/month with vendor lock-in baked into every SDK call. On the other side, open-source alternatives like Unleash require managing PostgreSQL infrastructure and don't support modern evaluation protocols beyond basic REST polling.

We wanted something different: a feature flag platform that is open source, serverless-native, OpenFeature-compatible from the ground up, and supports the protocols that modern distributed systems actually use -- gRPC-Web, Connect-RPC, OFREP, and real-time SSE streaming. We wanted a platform that treats infrastructure-as-code, observability, and AI-native workflows as first-class concerns rather than afterthoughts.

The frustrations that drove us were specific and recurring:

• Vendor lock-in was the default. Switching flag providers meant rewriting every evaluation call across every service. OpenFeature existed as a standard, but most platforms treated it as a compatibility shim rather than a core architectural principle.
• Protocol support was stuck in 2015. REST with polling was the universal answer, even for applications that needed sub-second flag propagation or high-throughput binary RPC.
• Self-hosting meant operational tax. Running PostgreSQL, managing connection pools, handling schema migrations -- all for a system that should be simpler than your application database.
• Pricing punished growth. Per-seat models meant that adding an intern or a product manager to the flag dashboard had a direct cost impact. Features like audit logging and SSO were gated behind enterprise tiers.
• AI tooling was nonexistent. As engineering workflows increasingly involved AI assistants, there was no way for an LLM to create, modify, or query feature flags through a structured protocol.

Flaggr addresses all of these. It is free, self-hostable, and built on a serverless-first architecture that eliminates database management. It speaks five protocols natively, implements OpenFeature at the core (not as a wrapper), and ships with an MCP server so AI coding assistants can manage flags alongside your code.

Why Another Feature Flag Platform?

Feature flags have become essential for modern software delivery. They enable trunk-based development, progressive rollouts, A/B testing, and instant kill switches. But existing solutions often come with trade-offs: vendor lock-in, high costs, complex setups, or limited protocol support.

Flaggr was built to be different:

• OpenFeature-compatible from day one — no vendor lock-in, standard SDK interfaces
• Multi-protocol support — REST, gRPC-Web, Connect-RPC, OFREP, and SSE streaming
• Built-in observability — OpenTelemetry-native metrics, traces, and audit logging
• Type-safe SDKs — full TypeScript support with compile-time safety
• Real-time updates — flag changes propagate in milliseconds via SSE streaming

Architecture Overview

Flaggr is organized around a three-level data model: Projects contain Services, and Services contain Flags. Projects provide tenant isolation -- they represent an organization or a product. Services map to your actual applications or microservices. Flags live within a service and carry their own targeting rules, variants, and per-environment configuration.

Project ("Acme Corp")
├── Service ("Web Frontend")
│   ├── Flag: release-dark-mode (boolean)
│   ├── Flag: experiment-pricing-page (string, variants: A/B/C)
│   └── Flag: ops-maintenance-mode (boolean)
└── Service ("API Gateway")
    ├── Flag: ops-rate-limit (number)
    └── Flag: release-v2-endpoints (boolean)

This hierarchy maps cleanly to how teams actually organize software. A platform team manages infrastructure flags in one service while a product team manages experiment flags in another, all under the same project with shared RBAC and audit logging.

Beneath the data model, Flaggr follows a four-layer architecture:

1. Storage — Dual backend with file-based storage for development and Firestore for production. File-based storage means you can run Flaggr locally with zero external dependencies -- no database to install, no Docker Compose file to maintain. In production, Firestore provides a fully managed document store that scales automatically and requires no schema migrations.
2. Authorization — NextAuth + RBAC with four roles (Owner, Admin, Member, Viewer). Authentication supports multiple providers including Google OAuth, GitHub, and email/password. Every API call is authorized against the user's role within the project context.
3. Evaluation — Targeting rules, variants, percentage rollouts with consistent hashing (MurmurHash3). The evaluator supports operators including equals, not_equals, in, not_in, contains, starts_with, ends_with, greater_than, less_than, regex, before, after, and cohort-based targeting. Percentage rollouts use consistent hashing so users always get the same variant for a given flag, and increasing the rollout percentage only adds new users without changing existing assignments.
4. Providers — OpenFeature server and web providers for any runtime. The server provider supports Node.js with SSE streaming for real-time updates. The web provider is optimized for browsers with cached evaluation and event-driven re-rendering.

Multi-Protocol Support

One of Flaggr's defining characteristics is protocol diversity. Instead of offering only a REST API and expecting every client to adapt, Flaggr supports five evaluation protocols natively:

This matters because different parts of a system have different needs. A Go microservice can use Connect-RPC for type-safe, high-performance evaluation. A React frontend can use SSE streaming so flag changes appear instantly without polling. A CI/CD pipeline can use the REST API for simplicity. And any OFREP-compatible client from any vendor can evaluate flags without any Flaggr-specific SDK at all.

AI-Native: The MCP Server

Flaggr ships with an MCP (Model Context Protocol) server at packages/mcp-server/. This is a standalone npm package (@flaggr/mcp-server) that exposes 19 tools, 3 resources, and 3 prompts for AI coding assistants like Claude, Cursor, and similar tools that support the MCP protocol.

With the MCP server, an AI assistant can:

• Create, list, update, and delete flags, projects, and services
• Modify targeting rules and percentage rollouts
• Set up A/B test experiments
• Query flag health scores and impact analysis
• Apply user overrides for debugging

This means feature flag management can happen directly in your development workflow. Ask your AI assistant to "create a boolean flag called release-dark-mode in the web-frontend service and roll it out to 5% of users" and it will make the appropriate API calls through the MCP protocol. No dashboard switching, no context loss.

What Makes Flaggr Different

Beyond the technical architecture, several design decisions set Flaggr apart from existing platforms:

OpenFeature is the core, not a wrapper. Many platforms added OpenFeature support after the fact -- a compatibility layer on top of their proprietary SDK model. Flaggr's evaluation engine, providers, and context model were designed around OpenFeature semantics from the start. This means standard OpenFeature SDKs work natively, OFREP compliance is built in, and you can switch providers by changing a single line of configuration.

Server-side evaluation by default. Flaggr evaluates flags on the server and sends only the result to clients. This means targeting rules, segment definitions, and rollout percentages never leave your infrastructure. Compare this to platforms that ship the full flag configuration to client SDKs, making rules visible in browser DevTools.

Observability is included, not upsold. OpenTelemetry-native metrics, evaluation tracing (think "EXPLAIN ANALYZE" for flag evaluation), flag health scoring across four dimensions (error rate, latency, volume, staleness), and per-flag impact analysis are all included. There is no enterprise tier that unlocks monitoring.

Infrastructure as code from day one. The Terraform provider covers projects, services, flags, alert channels, alert rules, and metric sources. Every flag change can go through a pull request with terraform plan showing exactly what will change. For teams that want to learn more about this approach, see our guide on managing feature flags with Terraform.

Evaluation debugging. The /api/flags/evaluate-debug endpoint returns a full evaluation trace showing every rule that was checked, every condition that was evaluated, and exactly why the flag resolved to its final value. This is invaluable when debugging complex targeting rules with multiple conditions and percentage rollouts.

Getting Started

Getting started with Flaggr takes minutes:

npm install @flaggr/sdk

import { useBooleanFlag } from '@flaggr/react';
 
function MyComponent() {
  const darkMode = useBooleanFlag('dark-mode', false);
 
  if (darkMode.value) {
    return <DarkTheme />;
  }
  return <LightTheme />;
}

What's Next

We're actively working on:

• Progressive rollouts with automated safety checks -- read more about this in our progressive rollouts guide
• Experimentation framework for A/B testing with statistical analysis
• Cohort management for reusable audience segments
• Terraform and Pulumi providers for flag-config-as-code
• Relay proxy for edge evaluation with zero-latency flag reads
• Additional SDK languages expanding beyond TypeScript, Go, Java, and Python
• Enhanced MCP server capabilities for deeper AI-assisted flag workflows

The Road Ahead

Flaggr is built in the open, and the roadmap is driven by real engineering needs rather than enterprise sales targets. Here is what we are focused on in the near term:

Community-driven development. Feature requests, bug reports, and contributions are welcome. The codebase is MIT-licensed with no CLA required. We believe that a feature flag platform should be community infrastructure -- like observability and CI/CD tools -- not a proprietary SaaS product.

Deeper OpenFeature ecosystem integration. As the OpenFeature specification evolves (it is a CNCF incubating project alongside Kubernetes and OpenTelemetry), Flaggr will track the specification closely. We are actively contributing to the OpenFeature community and ensuring that new specification features are supported in Flaggr's providers as they are ratified.

Edge evaluation. We are working on a relay proxy that runs on Cloudflare Workers, Vercel Edge Functions, and Deno Deploy. This will enable zero-latency flag evaluation at the edge while maintaining server-side evaluation semantics -- targeting rules stay private, and evaluation results are cached at the edge for sub-millisecond reads.

Expanded observability. The flag health scoring system currently tracks four dimensions (error rate, latency, volume, staleness). We plan to add anomaly detection that automatically identifies flags with unusual evaluation patterns, as well as deeper integration with Grafana dashboards for teams that use the Grafana stack for observability.

Follow our documentation for guides and SDK references, or jump straight into the dashboard to create your first flag. If you are evaluating Flaggr against other platforms, see our comparisons with LaunchDarkly and Unleash for detailed, honest assessments of where each platform excels.

We are building Flaggr for teams that ship. Join us.