Unleash is an open-source feature management platform. Engineers wrap new behaviour in a feature flag, deploy the code switched off, and then enable it from an admin interface for chosen users, a percentage of traffic or particular environments, without redeploying. It addresses the risk of releasing everything at once: a flag can roll out gradually, target a pilot group, run an experiment, or act as a kill switch if the change misbehaves. Unleash began at the Norwegian marketplace FINN.no and is now developed by the company Unleash (formerly Bricks Software), which also sells a commercial edition. NON CNCF: Unleash is not a CNCF project. It is listed in the CNCF Landscape under Feature Flagging alongside OpenFeature, and this brief covers it as a Landscape item.
CNCF daily · Sprint 2, day 8 · Feature Flagging · NON CNCF
At a glance
| Category | Observability and Analysis › Feature Flagging |
| CNCF status | NON CNCF, listed in the CNCF Landscape |
| Written in | TypeScript on Node.js for the server; the admin UI is React |
| License | Open-source core under Apache 2.0, with a separate commercial Enterprise edition. Confirm the licence of the edition you deploy |
| Storage | PostgreSQL |
| Core concepts | Projects, environments, feature flags, activation strategies, segments, variants and API tokens |
| SDKs | Server-side SDKs for Node.js, Java, Go, Python, .NET, Ruby, PHP, Rust and others, plus client-side SDKs through the frontend API |
| OpenFeature | An Unleash provider is available, so applications can use the vendor-neutral OpenFeature API |
Architecture
flowchart TB
ADMIN[Admin UI and API<br/>flags strategies segments] ==> SRV[Unleash server]
SRV ==> DB[PostgreSQL<br/>flag configuration]
SRV ==>|flag configuration| SDK[Server-side SDKs<br/>cache and evaluate locally]
SRV ==>|flag configuration| EDGE[Unleash Edge<br/>cache for client apps]
EDGE ==>|evaluated flags| WEB[Browser and mobile apps]
SDK ==> APP[Backend services]
SDK -.->|usage metrics| SRV
OF[OpenFeature API<br/>Unleash provider] -.->|optional wrapper| SDK
classDef actor fill:#eceff1,stroke:#455a64,stroke-width:1.5px,color:#1d1c1a
classDef core fill:#0f766e,stroke:#064e4a,stroke-width:2px,color:#ffffff
classDef data fill:#e3f2fd,stroke:#1565c0,stroke-width:1.5px,color:#1d1c1a
classDef ctrl fill:#ede7f6,stroke:#5e35b1,stroke-width:1.5px,color:#1d1c1a
class ADMIN actor
class SRV,SDK,EDGE core
class DB,APP,WEB data
class OF ctrl
Key: teal blocks are Unleash components, blue are storage and applications, purple is the OpenFeature layer, grey is the management interface. Thick arrows show flag distribution, dashed arrows metrics and the optional wrapper.
| Component | Responsibility |
|---|---|
| Unleash server | Stores flags and strategies, serves the admin UI and API, and distributes configuration to SDKs. |
| Server-side SDKs | Fetch the full flag configuration, cache it, and evaluate flags locally, so a request never waits on a network call to Unleash. |
| Unleash Edge | A lightweight proxy that serves evaluated flags to browser and mobile apps without exposing the main server or its configuration. |
| Activation strategies | Rules that decide who gets a flag: gradual rollout by percentage, specific user IDs, and constraints on context such as region or plan. |
| Segments and variants | Reusable audience definitions, and weighted values for A/B tests and multivariate flags. |
Design principle. Evaluate flags where the application runs. Server-side SDKs hold the configuration in memory and compute the result locally, so flag checks are fast, keep working if the Unleash server is briefly unavailable, and never send user data to the server.
Production reference design
A typical deployment runs the server and PostgreSQL on Kubernetes (EKS, GKE, AKS or on-premises) and connects services through SDKs.
- Run the database. Use a managed PostgreSQL service or a replicated cluster, with backups, since it holds all flag definitions.
- Install Unleash. Use the project Helm chart, supplying the database connection through a secret:
helm repo add unleash https://docs.getunleash.io/helm-charts helm install unleash unleash/unleash --namespace unleash --create-namespace - Structure the setup. Create projects per team and environments such as development and production, and issue separate API tokens per application and environment.
- Use a flag in code. A Node.js service checking a flag:
import { initialize } from 'unleash-client'; const unleash = initialize({ url: 'https://unleash.example.com/api/', appName: 'checkout', customHeaders: { Authorization: process.env.UNLEASH_API_TOKEN }, }); if (unleash.isEnabled('new-checkout-flow', { userId })) { // new behaviour } - Roll out gradually. Enable the flag for internal users, then a growing percentage, watching error rates and latency, and keep it as a kill switch until the code path is retired.
Typical uses include progressive delivery, trunk-based development, targeted beta programmes, experiments, and operational kill switches. Wrapping the SDK with the OpenFeature API through the Unleash provider keeps application code independent of the flag vendor.
Operational considerations
- Availability. SDKs keep serving cached values if the server is unavailable, but new SDK instances need an initial fetch or a bootstrap. Run several server replicas behind a load balancer.
- Client-side exposure. Never ship server API tokens to browsers. Use Unleash Edge or the frontend API with a client token that exposes only evaluated flags.
- Flag hygiene. Flags accumulate as technical debt. Set owners and expiry, use flag types, and remove release flags once rollout is complete.
- Security and audit. Restrict who can change production flags, use change requests where the edition supports them, and review the event log.
- Edition differences. Some governance and scale features belong to paid editions. Check the feature matrix against your requirements before standardising.
Adoption
- FINN.no, a Norwegian online marketplace, created Unleash for its own releases before it was open sourced.
- The Unleash company publishes customer stories and case studies on its website; consult those for current, first-party examples rather than relying on third-party lists.
- No public ADOPTERS list can substitute for your own evaluation, so run a pilot on one service first.
Alternatives
| Solution | Model | Best suited to |
|---|---|---|
| OpenFeature with flagd (CNCF Incubating) | Vendor-neutral API with a lightweight backend | Teams that want a standard API and a simple, file or Kubernetes-based backend; see the OpenFeature brief |
| Flagsmith | Open-source and hosted feature flags | Similar scope with remote configuration |
| GO Feature Flag | Open-source, file-based flags | Small, simple setups, also an OpenFeature provider |
| LaunchDarkly | Commercial SaaS | Large organisations that want a managed service and enterprise features |
| Config-file flags | Application configuration | Very small projects with few flags |
Strengths and limitations
| Strengths | Limitations |
|---|---|
| Mature, widely used open-source feature management | Not a CNCF project; backed by one company |
| Flexible strategies, segments and variants | Some governance features are commercial only |
| Local evaluation keeps flag checks fast and private | Requires operating a server and PostgreSQL |
| Edge proxy for safe client-side use | Flag sprawl needs active lifecycle management |
| OpenFeature provider avoids code lock-in | Node.js server stack may not match every platform team’s preferences |
Recommendation
Adopt for teams that want self-hosted feature management with progressive delivery. Start with one project and two environments, use the OpenFeature provider so application code stays portable, and agree flag ownership and removal rules from the beginning. Teams that only need simple flags may begin with OpenFeature and flagd, and move to Unleash when targeting, audit and a management interface are needed.
References: Unleash website · Unleash documentation · Unleash repository · CNCF Landscape