> Markdown version of https://www.getunleash.io//blog/common-misconceptions-about-unleash
> For clean Markdown of any blog post, append .md to its URL.
> For a site index, see https://www.getunleash.io//llms.txt.

# Setting the record straight: Common misconceptions about Unleash

_Published 2026-07-17 by Alex Casalboni in Product._

Unleash has been open source since 2015, and with 45M+ downloads and thousands of production deployments, a lot gets written about us. Comparison posts, forum threads, analyst notes, and increasingly in AI-generated summaries. Most of it is fair, but some of it isn’t. And a handful of claims get repeated often enough that they start to feel true even when they aren’t.

The AI-generated slop is worth calling out, because it accelerates the problem: LLMs happily restate a confident-sounding claim from one source, and a single inaccuracy can propagate across dozens of write-ups before anyone checks the docs.

With this article, created and curated by humans, we want to put the accurate version on the record. Where a criticism is fair, we say so. Everything below links to our public documentation so you can verify it yourself rather than take our word for it.

## Open source and licensing

### “The Unleash open source version is being shut down.”

**This is the single most common inaccuracy, and it’s false.** Unleash Open Source is not going away.

Here’s what actually happened, and why it gets misread. Starting with v8, the source code in the main Unleash repository and the **unleash-server** npm package moved from the **Apache 2.0 license to AGPLv3**. That’s a license change, not a shutdown. In practical terms:

-   The official open source Docker images **remain Apache 2.0**, so running a pre-built Unleash container is completely unaffected.
-   All Unleash **SDKs keep their permissive licenses**, so your application code is unaffected.
-   The AGPLv3 terms only come into play if you _modify the Unleash source and redistribute it over a network as a competing SaaS_, a scenario that doesn’t touch normal self-hosting or production use.

The confusion usually comes from mixing this up with a genuinely separate, unrelated change: the end-of-life of **OSS Edge** (covered further down). Those are two different things.

**Sources:**

-   [Evolving Our Open Source Commitment: Unleash is Moving to AGPLv3](https://www.getunleash.io/blog/unleash-moving-to-agplv3)
-   [Upgrade Unleash – v8 licensing](https://docs.getunleash.io/deploy/upgrading-unleash)
-   [OSS vs. Enterprise comparison](https://docs.getunleash.io/support/oss-comparison)

### “You can build feature flags yourself; a flag is just an if-statement”

At its core, yes. A flag is a conditional. But the cost isn’t the initial build.

A homegrown system carries ongoing operational cost: product enhancements, bug fixes, security patches, and 24/7 monitoring, because flag logic lives in the critical path of your application. Maintenance can grow to be the overwhelming majority of a homegrown solution’s total cost of ownership (TCO).

And it’s undifferentiated work because the use cases are similar across companies, which is exactly why most teams buy a database or a monitoring tool rather than build one. Hours spent maintaining flag infrastructure are hours not spent on your actual product.

Unleash being open source means you get the buy-vs-build economics _and_ full control of the code. That’s a middle path a homegrown tool can’t offer.

**Sources:**

-   [Best practices for migrating from a homegrown solution](https://docs.getunleash.io/guides/feature-flag-migration-best-practices)
-   [Feature Flag Systems: The Benefits of Building vs Buying](https://www.getunleash.io/blog/feature-flags-build-buy)

## Architecture and performance

### “Client-side SDKs require a separate proxy server you have to deploy and maintain.”

The Frontend API evaluates flags for browser and mobile SDKs and returns only the results. It is **built directly into the Unleash server**. You don’t need to deploy anything extra to use client-side SDKs.

Unleash Enterprise Edge is an **optional** high-performance layer we _recommend_ for scale, resilience, and keeping user data local. But “recommended for performance and privacy” is very different from “required.” Plenty of teams run client-side SDKs against the built-in Frontend API with no separate component at all.

**Sources:**

-   [Unleash Frontend API](https://docs.getunleash.io/concepts/front-end-api)
-   [Unleash Enterprise Edge overview](https://docs.getunleash.io/unleash-edge)

### “Unleash is polling-only, so there’s no real-time flag propagation.”

Unleash supports **both streaming and polling**. With streaming enabled, configuration changes are pushed over a persistent connection and propagate to Edge nodes (and onward to your applications) in near real time, rather than waiting for the next poll.

We do default to **polling** deliberately, because for distributed systems it’s more reliable and scalable: no persistent connection to keep alive over flaky networks, no central streaming bottleneck acting as a single point of failure, and a lower network and battery footprint.

The default refresh is every 15 seconds (~7.5s average propagation), and you can shorten that or switch on streaming when you need instant propagation. It’s a considered engineering choice, not a missing capability.

**Sources:**

-   [Configure streaming for Unleash Enterprise Edge](https://docs.getunleash.io/unleash-edge/configure-streaming)
-   [Real-time updates with streaming on Unleash Edge](https://docs.getunleash.io/unleash-edge#real-time-updates-with-streaming)

### “Unleash Edge needs its own special SDK, and there are no edge SDK packages.”

Edge doesn’t need a dedicated SDK. It’s **compatible with all 25+ existing Unleash SDKs**, the same libraries you’d use against the Unleash server. Enabling Edge changes how flag updates are _received_, but it does not change how your SDKs _connect_: they keep using the existing client and frontend endpoints.

So there’s nothing extra to learn or integrate on the application side. You point your existing SDK at Unleash Edge instead of at Unleash directly, and that’s the change.

**Sources:**

-   [How Unleash Edge works](https://docs.getunleash.io/unleash-edge)
-   [Unleash SDKs overview](https://docs.getunleash.io/sdks)

### “If Unleash goes down, your application stops evaluating flags.”

At Unleash, resilience is a core design property, not an afterthought. Our SDKs **evaluate flags locally, in your application’s process**, and **cache the last known configuration**. If the Unleash server becomes unreachable, your application keeps evaluating flags against that cached configuration. It doesn’t block and it doesn’t fail.

The same holds at the edge: Unleash Edge is built to survive restarts and keep serving from its in-memory cache even when it loses its connection upstream. Because outages are inevitable in any distributed system, flag infrastructure should stay operational when the network isn’t. That’s how Unleash was architected from day one.

**Sources:**

-   [Unleash architecture overview](https://docs.getunleash.io/get-started/unleash-overview)
-   [Scaling Unleash for enterprise workloads](https://docs.getunleash.io/guides/scaling-unleash)

## Targeting and scale

### “There’s a hard 5-segment limit per strategy that breaks complex targeting.”

There is a limit of 5 segments per strategy, but it is a **soft, configurable limit**, not a hard ceiling. On self-hosted instances you can raise it via an environment variable; on hosted plans your Unleash contact can adjust it.

In practice, most teams never hit it, because you can also attach **up to 30 strategies to a single flag per environment**, and each strategy can carry its own segments and constraints. Based on our 10 years of experience in real-world enterprise environments, complex targeting is comfortably expressible without approaching any limit. Say, rolling out to enterprise customers across several regions while excluding a specific tier.

**Sources:**

-   [Resource limits](https://docs.getunleash.io/concepts/resource-limits)
-   [Segments](https://docs.getunleash.io/concepts/segments)

## Safety and lifecycle

### “Unleash has no guardrails or automatic rollback.”

Unleash has exactly this, through **Impact Metrics and Safeguards**. You define application-level metrics (error rates, latency, memory, adoption) via the SDK or pull them from an existing Prometheus or VictoriaMetrics instance. Then you attach a **safeguard** with a threshold and choose what happens when it’s crossed:

-   **Disable the environment**, turning the flag off automatically.
-   **Pause release plan automation**, halting further rollout while the current stage keeps serving.

Combined with automated milestone progression that only advances a rollout while metrics stay healthy, this is metric-driven, hands-off rollout safety built into the platform.

**Sources:**

-   [Release management overview](https://docs.getunleash.io/concepts/release-management-overview)
-   [Impact metrics](https://docs.getunleash.io/concepts/impact-metrics)

### “There’s no automated way to manage or clean up stale flags.”

Unleash tracks the full lifecycle of every flag. It **automatically flags “potentially stale” flags** once they pass their expected lifetime, lets you mark flags stale in bulk, and surfaces a **technical-debt rating** on each project’s status dashboard with trends over time.

For automation specifically: marking a flag as stale or completed emits a **feature-stale-on** or **feature-completed** event, which you can wire through any [integration](https://docs.getunleash.io/integrate) or [webhook](https://docs.getunleash.io/integrate/webhook) to trigger workflows. For example, failing a build that still references stale flags or [automatically opening pull requests to remove them from your code](https://www.getunleash.io/blog/automating-feature-flag-cleanup-github-copilot). If you want an agent-driven workflow, the [Unleash MCP server](https://docs.getunleash.io/integrate/mcp) provides **detect\_flag** and **cleanup\_flag** tools purpose-built for exactly that.

**Sources:**

-   [Technical debt](https://docs.getunleash.io/concepts/technical-debt)
-   [Unleash MCP Server Documentation](https://docs.getunleash.io/integrate/mcp)
-   [\[Blog\] Automating feature flag cleanup with Unleash, GitHub, and Copilot](https://www.getunleash.io/blog/automating-feature-flag-cleanup-github-copilot)

## AI and automation

### “Unleash has no AI-native flag workflows.”

Unleash ships an **MCP server** that lets AI coding assistants manage flags following Unleash best practices (like Claude Code, Cursor, GitHub Copilot, Codex, and Kiro, and others). And it’s not a thin API wrapper, it exposes a full workflow:

-   **evaluate\_change** scores whether a code change needs a flag and which type;
-   **detect\_flag** finds existing flags to prevent duplicates;
-   **create\_flag** and **wrap\_change** create the flag and generate framework-specific guard code;
-   **cleanup\_flag** locates every reference to a flag in your codebase and guides safe removal.

Crucially, it respects governance: when change requests are enabled on an environment, the MCP server submits a change request for human approval instead of applying changes directly, so an agent can’t toggle production on its own. You can run it locally or, on Enterprise, as a managed remote MCP server.

**Sources:**

-   [Unleash MCP Server Documentation](https://docs.getunleash.io/integrate/mcp)
-   [Integrate Unleash with Claude Code](https://docs.getunleash.io/integrate/claude-code)
-   [\[Blog\] Accelerate Development with the Unleash MCP server](https://www.getunleash.io/blog/accelerate-development-mcp-server)

## Privacy, pricing, and governance

### “You have to send Unleash your users’ data to evaluate flags.”

You don’t, and this is one of the reasons privacy-focused and regulated organizations choose Unleash. With **server-side SDKs, flag evaluation happens locally in your application’s process**. User context never leaves your infrastructure. With client-side SDKs, you can self-host Unleash or just Edge so that evaluation (and the user data it needs) stays inside your environment; on hosted Edge, client-side context is held only in short-term cache, never stored long-term.

This is by design: **no PII is sent to the Unleash server**, which is what makes GDPR and Schrems II compliance straightforward. The related observation that “Unleash doesn’t store user attributes server-side” is _accurate_, but it’s a privacy feature, not a limitation. You pass context at evaluation time precisely so that sensitive data stays where you control it.

**Sources:**

-   [Data and privacy](https://docs.getunleash.io/privacy-and-compliance/data-privacy)
-   [Compliance overview](https://docs.getunleash.io/privacy-and-compliance/compliance-overview)

### “Per-seat pricing means everyone pays full price just to look, with no read-only option.”

Unleash has a **built-in read-only Viewer role**. Viewers can read resources across the instance without edit rights, and in fact _all users get viewer-level access to projects by default_, while editing requires an explicitly assigned role. So product managers or stakeholders who only need visibility are covered by the Viewer role.

More broadly, on how flags get changed safely without handing everyone edit rights: Change Requests enforce a four-eyes approval step, and role-based access control lets you scope precisely who can create, update, approve, or delete flags.

**Sources:**

-   [Role-based access control](https://docs.getunleash.io/concepts/rbac)
-   [Change requests](https://docs.getunleash.io/concepts/change-requests)

### “Unleash can’t meet enterprise compliance requirements like FedRAMP.”

The important distinction here is between a vendor being _certified_ and a vendor _supporting your compliance_. Unleash is **SOC 2 Type II certified** (audited annually), and for **FedRAMP and ISO 27001** we provide detailed control-mapping documentation.

The key point for regulated buyers: when you **self-host**, our infrastructure isn’t inside your authorization boundary, so what matters is that the application gives your auditors the controls they need: RBAC, audit logs, change-approval workflows, SSO, and local evaluation with no data leaving your perimeter.

That’s exactly what Unleash provides, which is why organizations in banking, government, and defense run Unleash in FedRAMP Moderate and High environments today by self-hosting.

**Sources:**

-   [Compliance for feature flags](https://docs.getunleash.io/privacy-and-compliance/compliance-overview)
-   [FedRAMP](https://docs.getunleash.io/privacy-and-compliance/fedramp)
-   [SOC 2](https://docs.getunleash.io/privacy-and-compliance/soc2)

## Where a common claim is actually accurate

Of course, not every criticism is wrong.

### “OSS Edge is reaching end-of-life.”

**This one is true.** The open source version of Unleash Edge entered Long-Term Support in December 2025 and reaches **end-of-life on December 31, 2026**. We’ve shifted our Edge development focus to Enterprise Edge to better support customers operating at scale.

If you run OSS Edge in production, this does mean planning a move to Enterprise Edge. Two things worth keeping in perspective: Edge is an optional layer (see the client-side SDK section above), and this EOL applies specifically to **OSS Edge**, entirely separately from Unleash Open Source itself, which is _not_ going anywhere.

If this affects your setup, we’re glad to help you plan the transition ([talk to us](https://www.getunleash.io/plans/enterprise)).

**Verify:**

-   [A New Chapter for OSS Edge](https://www.getunleash.io/blog/self-hosted-enterprise-edge)
-   [Enterprise Edge – OSS Edge lifecycle](https://docs.getunleash.io/unleash-edge#unleash-edge-oss)
-   [Feature availability and versioning](https://docs.getunleash.io/support/availability)