Unleash vs LaunchDarkly: What Self-Hosting Feature Flags Actually Costs

Unleash’s open-source core caps you at two environments and ships without single sign-on, role-based access control, SCIM provisioning or change requests; SSO, RBAC and additional environments sit behind the Pro and Enterprise plans, and SCIM and change requests are named in the Enterprise trial description, a boundary documented in the project’s own README. That single fact does more to settle the “self-host or pay for LaunchDarkly” question than any benchmark, because the real cost of self-hosting feature flags is not the container you run but the governance you give up and the operational toil you absorb. An Unleash maintainer’s post marking 11 years of open-source development drew attention on Hacker News this week [unverified], but the decision underneath the thread is older: build on the open-source core, pay Unleash or LaunchDarkly for the governance layer, and either way decide now whether OpenFeature sits between your code and the vendor.

The short version, with the reasoning to follow: choose the open-source core only if two environments are enough, your team can live without SSO and RBAC, and you can absorb the identity and availability work yourself. Independent evidence puts the identity gap alone at roughly 10 engineer-hours per week in one enterprise case, an estimated $35,000-plus per year at an illustrative $75/hour rate. If that trade looks bad, pay a vendor, and put OpenFeature in front so the eventual exit is a configuration change rather than a rewrite.

What the open-source core actually ships

The free tier is real software, not a demo. Local setup is git clone plus docker compose up -d, with the UI served on localhost:4242, per the Unleash README. The open-source feature list includes the capabilities most teams actually need day to day: kill switches, canary releases and gradual rollouts, A/B testing, and flag organization with tags. Evaluation happens inside your application via official backend SDKs for eight named languages: Go, Java, Node.js, PHP, Python, Ruby, Rust and .NET.

Two cautions on that SDK story. The same README states “15 official client and server SDKs and over 15 community SDKs” in its introduction and “12 official SDKs, and 10 community-contributed SDKs” in its feature list. Neither count is necessarily wrong (the introduction may include frontend SDKs the feature list excludes), but the discrepancy is a useful reminder that vendor documentation drifts.

The paywall is equally explicit. The README’s own words:

If you’re looking for one of the following features, please take a look at our Pro and Enterprise plans:

role-based access control (RBAC) single sign-on (SSO) more environments feature flags project support advanced segmentation additional strategy constraints tighter security more hosting options (we can even host it for you!)

And the Enterprise trial description in the same document names “role-based access control, change requests, single sign-on, and SCIM for automatic user provisioning.” Read those two lists together and the shape of the business model is clear: flag mechanics are free, identity and governance are the product.

One wrinkle worth flagging honestly. The README’s security section for the open product lists “Audit logs” alongside GDPR/Schrems II privacy-by-design and an HTTPS-only mode, which sits in tension with the common assumption that audit logging is enterprise-gated. The README and the marketing pages are vendor-controlled evidence; treat the audit-log boundary as unresolved before it influences a compliance decision. The documentation was split into its own repository in February 2026, which is where the current boundary lives.

The comparison vendors will not build for you

Unleash’s open-source page pitches the free edition as “fully featured” while the README gates identity, environments and segmentation behind paid plans. LaunchDarkly’s developer portal documents a broad commercial surface (targeting rules, users and contexts, segments, percentage rollouts, scheduled changes, and a supported languages/frameworks matrix split by server-side and client-side) but publishes no pricing. Neither vendor has an incentive to lay the boundary out side by side, so here is the map the evidence supports:

The empty cells are the point. “Not stated on the developer portal” does not mean LaunchDarkly lacks SSO or RBAC; it means the developer portal does not document them, and chasing those answers is part of the cost of doing this evaluation properly. What the table does establish: the open-source Unleash column is missing exactly the rows a security review will ask about first, and every performance number anyone will quote at you in this decision is vendor-published.

Self-hosting moves the identity problem onto your team

The rows the open core lacks are not nice-to-haves. A 2025 paper on arXiv, The Auth Shim, studied what happens when a standalone open-source tool meets enterprise identity requirements, and frames the result as a three-way dilemma: “purchase expensive enterprise licenses solely for SSO, accept the security risks of manual account management, or abandon the tool altogether.” In the study-reported Adobe case, engineers bridged the gap with a shim layer and eliminated manual provisioning toil estimated at 10 hours of engineering work per week, “an estimated annual saving of over $35,000 in operational costs for a single application integration” at an illustrative $75/hour fully loaded rate.

Two limits on that number before you reuse it. It comes from one enterprise, one application, and a different OSS tool than Unleash, and the $75/hour rate is the paper’s illustrative assumption, not a market survey. But the mechanism transfers directly: if you self-host Unleash’s open core for a team of any size, someone on your team becomes the provisioning system. Every hire, departure and role change is a manual account operation in a tool that controls which code paths your production services execute. That is both a toil line item and a security exposure, and it recurs for as long as you run the tool.

High availability is the second transferred burden, and here the evidence in hand is thinner. The README’s feature list describes Unleash Edge scaling client and frontend evaluation independently of the central server so read traffic does not overload the core instance, which reduces but does not eliminate the availability requirement on the central node. The README does not name the backing database, so storage-layer failover specifics stay on the verification list at the end of this article. What can be said without new facts: when the flag server degrades, every service that consults it degrades in the same incident, and the on-call rotation for that server is yours.

OpenFeature is an exit ramp for code, not for governance

The strongest argument for self-hosting is reversibility, and OpenFeature is how you buy it cheaply. OpenFeature is described as a graduated CNCF open standard, and per CloudBees’ explainer (written by a feature-management vendor, so read it as an interested but well-informed party), calling the OpenFeature API instead of a vendor SDK means “Swapping providers becomes a configuration change rather than a codebase-wide migration.” If you adopt Unleash’s open core today and the governance gap eventually forces you onto a paid plan or a competitor, an OpenFeature integration confines that migration to provider configuration instead of a sweep through every service that evaluates flags.

The same source is equally clear about the limit: “OpenFeature has no concept of audit trails, approval workflows, role-based access controls, or flag lifecycle management.” OpenFeature standardizes the call site, the line of code that asks “Is this flag on for this user?” It does not migrate your flag definitions, targeting rules, segments, permissions or approval history between vendors, and it supplies none of the governance capabilities whose absence might be the reason you are switching. Treat it as cheap insurance on the SDK layer, priced at a modest abstraction cost up front, not as a portability guarantee for your flag configuration.

A break-even you can compute, with inputs exposed

Neither vendor publishes plan pricing on the pages cited here, so any precise dollar break-even would be invented. What can be built honestly is the equation, with each input exposed so you can substitute current quotes:

• Identity toil. Hours per week spent on manual provisioning and deprovisioning, times loaded hourly rate, times 52. The study-reported reference point is 10 hours/week, over $35,000/year, from a single case at an illustrative rate. A team of ten with modest churn might spend a fraction of that; a regulated organization with strict joiner-mover-leaver requirements might exceed it. Measure your own number.
• Availability toil. Setup and ongoing operation of a highly available flag server and its database, plus on-call. No public measurement exists in this evidence set; estimate it from your team’s experience running comparable stateful services, and count the first incident review, not just the uptime.
• Environment count. If your pipeline needs dev, staging and production, the open core’s two-environment cap ends the evaluation on its own, per the README feature list. This is a binary gate, not a cost curve.
• Vendor price. Pull current quotes from both vendors at decision time; neither page cited here publishes one.

The structure of the answer is robust even without the prices: the open core wins when the environment cap fits and identity toil is small (a platform team of five, one staging environment, existing internal SSO you can front with a proxy); the paid tiers win as soon as a security review, an audit requirement, or a third environment enters the picture. I would treat the two-environment limit as the first filter, because it costs nothing to check and disqualifies the free tier for most multi-team rollouts before any toil math matters.

How to read 7.5 trillion evaluations a day

Unleash’s homepage reports, as vendor-published figures, 7.5T+ flag evaluations daily and Enterprise Edge latency under 50ms across 35+ regions, alongside SOC2, ISO27001, FedRAMP-ready and GDPR posture. A customer testimonial on the same page, attributed to a Wayfair SRE, reports “more than 20,000 RPS on a typical business day” served by a single Unleash server fronted by Edge instances acting as a distributed read-only proxy, with the useful detail that “Edge limits query load on the central server, keeps latency low, and keeps features running even if the server has hiccups.”

These numbers are not evidence that your deployment will be fast, and they are not suspect either; they are marketing claims and one named customer’s self-report. None of the sources cited here is an independent benchmark of Unleash versus LaunchDarkly evaluation performance. If performance is load-bearing for your decision, the honest path is a small benchmark you run yourself. A recent pilot benchmark of self-hosted HTTP services on a Raspberry Pi 5 models the disclosure standard: named hardware and firmware, N=50 randomized runs per configuration, bootstrap confidence intervals, and memory measured alongside throughput. A flag-evaluation test at that level of rigor, on your own services and network, will tell you more than any vendor’s trillion-evaluations headline. Unleash’s homepage adds one relevant fact for the self-hosting case: “Flag evaluation happens locally inside your apps.” An evaluation path that runs inside your own process is the one your own benchmark measures; a vendor’s aggregate headline is not.

Flagsmith and the rest of the spectrum

Unleash and LaunchDarkly are not the whole field. Flagsmith is an open-source feature flag and remote config platform under the BSD-3-Clause license, offering a hosted API, private cloud or on-premise deployment, with its GitHub organization showing 90 repositories updated through early November 2026. It spans the same deployment spectrum as Unleash, which means the same evaluation framework applies: find the license boundary, find where identity and audit live, price the toil. Repository activity says the project is maintained; it says nothing about whether its feature boundary or SDK coverage fits your stack, so apply the same verification steps rather than treating it as a drop-in answer.

The verdict, and what to re-verify

The decision resolves into three questions. Can you live within two environments and without SSO, RBAC, SCIM and change requests, all documented as paid features in Unleash’s README? Can you absorb the identity and availability toil, with the study-reported identity gap alone running about 10 engineer-hours weekly in one enterprise case? And have you put OpenFeature in front so that a future switch is a configuration change, with the understood limit that governance and flag data do not travel with it? If yes to all three, the open-source core is a defensible foundation. If any answer is no, pay Unleash or LaunchDarkly for the governance layer, because that is what you are actually buying; the flag mechanics were free all along.

Before signing or committing, re-verify six things against current documentation, because every one of them rests on vendor-controlled or time-sensitive evidence: the Pro/Enterprise feature boundary (especially the ambiguous audit-logs row); the self-hosting storage and high-availability requirements, since the README never names the backing database; both vendors’ current pricing; the official SDK counts for your languages; the repository’s license, which no page cited here states; and any scale claim you intend to rely on, all of which are vendor-reported rather than independently measured. Flag systems outgrow the team that installed them; the flags you create this quarter will still be in the codebase, accruing the lifecycle debt no vendor’s SDK can clean up, long after this quarter’s pricing sheet is obsolete.

Frequently Asked Questions

What features are missing from Unleash’s open-source core?

Unleash’s open-source core caps you at two environments and ships without single sign-on, role-based access control, SCIM provisioning or change requests; SSO, RBAC and additional environments sit behind the Pro and Enterprise plans, and SCIM and change requests are named in the Enterprise trial description, a boundary documented in the project’s own README.

How much does manual identity provisioning cost in an enterprise setting?

Independent evidence puts the identity gap alone at roughly 10 engineer-hours per week in one enterprise case, an estimated $35,000-plus per year at an illustrative $75/hour rate.

Does OpenFeature allow migrating flag configurations between vendors?

The same source is equally clear about the limit: “OpenFeature has no concept of audit trails, approval workflows, role-based access controls, or flag lifecycle management.” OpenFeature standardizes the call site, the line of code that asks “Is this flag on for this user?” It does not migrate your flag definitions, targeting rules, segments, permissions or approval history between vendors, and it supplies none of the governance capabilities whose absence might be the reason you are switching.