Unleash has deprecated its open-source editions (Unleash OSS and Unleash Edge OSS) in favor of Unleash Enterprise. Those editions moved to long term support on December 10, 2025, and reach end of life on December 31, 2026. Nothing switches off on that date, and the code stays open. What ends is vendor maintenance and security patching for those editions, so plan a path now.
What the deprecation actually says
Unleash's availability page lists the support status of each edition. It says the open source editions are deprecated in favor of Enterprise, and gives them two dates: LTS (long term support) from December 10, 2025, and end of life on December 31, 2026. Read it at docs.getunleash.io/support/availability: a primary source beats any summary.
LTS means the software still exists and still gets limited, critical support: maintenance, not development. EOL means the vendor stops. After December 31, 2026, expect no further releases, bug fixes, or security patches from Unleash for those two editions. That is a runway of roughly 18 months, and the failure mode is forgetting about it until Q4 2026.
What it does not mean
- Your flags do not turn off. There is no remote kill date. An Unleash OSS instance running on January 1, 2027 serves flags exactly as it did the day before.
- The repository is not being deleted. The code is open source and stays available.
- Your SDKs keep working. The client API is documented, and your apps keep talking to your server the same way.
- This is not a rug-pull. What is withdrawn is vendor support and maintenance, not your right to run the code you already have.
What it does mean if you self-host
A flag service is not a dashboard you visit on Thursdays. It sits on the request path: every page load, every API call, every job that checks a flag depends on it, directly or through cached SDK state. Adopt flags seriously and it becomes tier-0 infrastructure. After EOL, that service is unmaintained:
- No security patches. A CVE in the server, in Edge, or in a transitive dependency becomes yours to triage, backport, and ship. This is a service holding an admin API, API tokens, and user targeting attributes.
- No compatibility fixes. Postgres majors move. Runtimes move. Base images get rebuilt. Nobody upstream is checking that the old release still builds against them, and the longer you sit on a frozen version, the more every skipped migration costs when you finally jump.
- Security review will ask. "Is any production dependency past end of life" is standard in SOC 2 and vendor questionnaires, and "yes, the one on the request path" is an awkward answer.
That is the ordinary risk of running unmaintained software in a critical position: not a crisis, but a debt with a start date. Self-hosting already meant owning the upgrades, the patches, and the server provisioning and zero downtime deploys that keep it reachable. The deprecation does not add that burden; it removes the upstream help that made it manageable, a trade we covered in open source feature flags vs managed platforms.
If you are on GitLab, read this
GitLab feature flags are not affected in the same way, and plenty of teams who reached Unleash through GitLab are about to worry for no reason. GitLab's built-in flags are Unleash compatible, not Unleash powered. GitLab runs its own backend that speaks the Unleash client API, which is why you point Unleash SDKs at it. It does not run the Unleash server. GitLab's flags are not deprecated and still ship on Free, Premium, and Ultimate as of GitLab 19.x. If your flags live in GitLab, this notice does not apply and nothing needs migrating. Our guide to GitLab feature flags covers what that setup can and cannot do.
Your options
If you self-host, you have four honest paths: pay Unleash, move to another self-hostable open source project, move to a managed platform, or stay put with your eyes open. Pricing verified July 14, 2026.
| Option | Pricing model | Self-host? | Migration effort | Best for |
|---|---|---|---|---|
| Unleash Enterprise | $75 per seat/mo (PAYG), 5-seat minimum self-hosted, about $375/mo at the floor. Includes 53M API requests/mo, then $5 per million. Enterprise is sales-led. | Yes | Lowest: same SDKs and data model | Teams who like Unleash and want zero migration work. Cost grows per seat. |
| Flagsmith | Free $0 (50K API requests/mo, 1 seat). Start-Up $40/mo billed yearly. Scale-Up $250/mo yearly. Overages from $50 per million requests. | Yes | Medium | Closest like-for-like open source self-host swap. |
| ConfigCat | Flat monthly, unlimited seats and unlimited MAU. Free $0 (10 flags, 2 envs). Pro $110/mo. Smart $325/mo. | No | Medium | Flat billing, no servers to run. |
| PostHog | Free to 1M requests/mo, then usage-priced per request. No per-seat charge. | Yes | Medium | Already on PostHog for analytics. |
| LaunchDarkly | Developer $0 (unlimited seats and flags, 1 project, 3 envs). Foundation usage-priced: $10 per service connection/mo plus $8.33 per 1,000 client-side MAU/mo, yearly. No longer per-seat. | No | Medium to high | Large orgs needing deep governance and experimentation. |
| Toggled | Planned flat per-team pricing, unlimited seats and flags: Launch $49/mo, Team $149/mo, Scale $499/mo. Early access, not launched. | No (planned for Enterprise) | Medium | Small teams wanting flat pricing and A/B testing. New and unproven. |
Unleash Enterprise is a completely reasonable answer: if you like the product, migration cost is near zero. The catch is the shape of the bill. Per seat, with a floor, means cost tracks headcount rather than usage, so price the team you expect in two years.
Flagsmith is the obvious like-for-like if what you valued was open source and self-hosting. If you ran Unleash OSS for data residency or air-gapping, that reason has not changed, and a managed vendor (including us) is not your answer. Our comparison of feature flag tools covers the wider field, and LaunchDarkly's pricing gets its own breakdown.
How to migrate without flipping cohorts under live users
Teams estimate a flag migration as "swap the SDK, point at the new host, done." The SDK swap is the easy part. The real work is re-creating flag definitions, targeting strategies, environments and rollout state, then verifying the new system buckets users the way the old one did.
That last point bites. Percentage rollouts hash a stable identifier (user ID, session ID, some attribute) and compare it to a threshold. Every provider does this, but not all use the same hash function, seed, salt, or inputs. If your new provider hashes users differently, a user who was inside your 10% cohort can land outside it after the migration. Someone using a feature at 10:00 loses it at 10:01, mid-session, with no deploy and no obvious cause. If the flag gates an experiment, you have also contaminated the results.
The fix is procedural. Sequence the migration so no flag is mid-rollout while it changes hands.
- Inventory by state, not by name. Split every flag into three buckets: at 0%, at 100%, and partially rolled out (including targeting rules matching a subset). The first two are safe to move. The third is not.
- Migrate the 0% and 100% flags first. A flag serving everyone or no one has no cohort to preserve, so bucketing differences cannot change the answer. That is most of your estate, migrated with zero user-visible risk.
- Never migrate a flag mid-rollout. For anything at 25% or 40%, either finish the rollout to 100% or roll it back to 0% and restart it on the new provider. Deciding that on your schedule is cheap. Discovering it during cutover is not.
- Verify cohort stability on a canary flag. Create a throwaway flag at 50% in both systems with the same identifier and rule, evaluate a few thousand real user IDs against both, and compare the sets. Near-total overlap means the bucketing is compatible. If they look like independent coin flips, you found the problem cheaply, on a flag nobody uses.
- Pin the identifier explicitly. Pass the same stable key on both sides. Falling back to a session ID or a random anonymous ID re-shuffles users on every visit: the same symptom for a different reason, and harder to spot.
- Run both in parallel briefly. Keep the old server up and read from the new one behind a thin wrapper in your code, so rollback is a config change, not a redeploy. Decommission after a clean week.
Done this way, migrating a few dozen flags is a quiet week. Done on a Friday by repointing the SDK, it is a queue of "the feature disappeared" tickets nobody can reproduce. Our gradual rollout guide covers restarting one safely.
Is Unleash open source being discontinued?
The Unleash OSS and Unleash Edge OSS editions are deprecated in favor of Unleash Enterprise, but the code remains open source and available. What is discontinued is vendor support: they entered long term support on December 10, 2025 and reach end of life on December 31, 2026.
When does Unleash OSS reach end of life?
December 31, 2026, per Unleash's availability documentation. Since December 10, 2025 the open source editions have been in LTS, meaning limited critical support only. After the EOL date, expect no further releases, bug fixes, or security patches from Unleash for those editions.
Do I have to pay for Unleash now?
Not immediately, and not at all if you migrate elsewhere or accept the risk. To keep vendor support, the paid path is Enterprise: Pay-As-You-Go is $75 per seat per month with a 5-seat minimum self-hosted, roughly $375/mo at the floor, scaling with headcount.
Are GitLab feature flags affected by the Unleash deprecation?
No. GitLab's feature flags are Unleash-compatible: GitLab runs its own backend that speaks the Unleash client API, and does not run the Unleash server. GitLab feature flags are not deprecated and still ship on Free, Premium, and Ultimate as of GitLab 19.x. No migration is required.
What is the best alternative to Unleash open source?
It depends on why you self-hosted. If you needed data residency or control, Flagsmith is the closest open source, self-hostable replacement. If you liked Unleash itself, Enterprise is the lowest-effort path. If you self-hosted to avoid a bill, a flat-priced managed platform often costs less than the engineer hours.
Where we fit
Toggled is a managed feature flags platform with A/B testing built in, priced flat per team with unlimited seats and flags: Launch $49/mo, Team $149/mo, Scale $499/mo. No per-seat math, so the whole team can reach the kill switch without counting licenses.
The caveat matters more than usual here: we are in early access and unproven, with no track record to check. If you face a hard migration deadline for infrastructure on your request path, an established vendor is the rational choice, and Unleash Enterprise or Flagsmith may be the better answer. If flat pricing and built-in experimentation are what you want, how it works explains the rest.