OpenFlags

What is OpenFlags?

OpenFlags is an open source, self-hosted feature flag system designed to help teams ship changes with progressive delivery and safer rollouts. It provides a control plane and SDKs so application code can evaluate flags locally and enable feature behavior without redeploying for each change.

The core purpose of OpenFlags is to support release workflows—such as percentage rollouts, targeted activation, and controlled enablement—while keeping flag evaluation low-latency and runtime ownership inside the team’s infrastructure.

Key Features

• Self-hosted flag infrastructure: Keep flag storage, targeting logic, and runtime ownership inside your own infrastructure rather than relying on a hosted platform.
• Local evaluation via typed SDKs: Evaluate flags in the app using TypeScript packages, aiming for fast, predictable checks by running evaluation locally in your code.
• Progressive delivery controls: Roll out features to controlled slices (including percentage rollouts) rather than enabling changes for everyone at once.
• Granular targeting: Activate flags based on specific user targeting so different cohorts can receive different feature behavior.
• REST control plane with a focused surface area: Use a simple REST API for the flag control plane and management, designed as part of a monorepo with dedicated roles for server, dashboard, SDKs, and docs.
• Dashboard for toggling and rollout management: A React-based admin UI helps teams toggle releases and manage rollout configuration.

How to Use OpenFlags

1. Start with the documentation and quickstart: Use the provided docs to set up the server, dashboard, and SDKs for your environment.
2. Create an SDK client in your app: Initialize the client with your API URL, project identifier, and user identifier.
3. Evaluate flags locally in application code: Use the SDK to check whether a flag is enabled (for example, by calling flags.isEnabled("flag_name")) and conditionally render behavior.
4. Manage rollout configuration from the control plane: Use the dashboard and/or REST API to define rollout behavior such as percentage-based enabling or targeted activation.

Use Cases

• Progressively enable a new user experience: Gate a UI or workflow behind a feature flag and enable it for a controlled subset of users rather than all traffic at once.
• Run a beta test with targeted users: Activate a feature for specific cohorts by targeting user identifiers, allowing you to compare behavior across groups while keeping the rest unaffected.
• Reduce release blast radius with percentage rollouts: Roll out a change gradually (for example, to 35% of users) and adjust rollout behavior without needing to rebuild or redeploy the application.
• Keep flag checks fast in performance-sensitive apps: Use local evaluation in the app so feature checks stay low-latency and consistent during runtime.
• Maintain ownership inside your infrastructure: Use a self-hosted control plane to keep the operational and audit surface within your stack.

FAQ

• Is OpenFlags self-hosted or cloud-hosted? OpenFlags Cloud is described as coming soon, and the current offering is positioned as open source and self-hosted.

• How does feature evaluation work? OpenFlags supports local evaluation using its SDKs, so flag checks occur inside your app code rather than requiring a remote call for each evaluation.

• What rollout patterns are supported? The site mentions progressive delivery with percentage rollouts, granular targeting, and controlled enablement.

• What components does OpenFlags include? The monorepo includes a server (Bun-powered API for the control plane), a React-based dashboard, TypeScript SDK packages, and documentation.

• Which languages/frameworks are the SDKs designed for? The site highlights JavaScript-first SDK usage and mentions support for Bun, React, Next.js, Vite, and Node apps.

Alternatives

• Managed feature flag platforms (SaaS): These typically centralize flag management in a hosted service. Compared to OpenFlags’ self-hosted control plane, evaluation and operational ownership may be more dependent on the vendor’s platform.
• Infrastructure-as-code driven rollouts (without dedicated flag evaluation): Teams can approximate progressive delivery using deployments, routing, or configuration toggles. This differs from OpenFlags by not providing a purpose-built feature flag SDK workflow for local evaluation.
• Open-source feature flag services with different architectures: Alternative open source systems may offer similar concepts (flags, targeting, dashboards) but with different tradeoffs in SDK approach, control plane API design, or how local evaluation is handled.