LaunchDarkly vs Unleash: which fits your release flags?
Choose hosted LaunchDarkly if you want the vendor to run the flag service, its uptime and its upgrades, and you need its full governance and integration list. Choose self-hosted Unleash if you want the flag server, the flag data and the operating effort inside your own infrastructure, and your team can either work within Unleash Open Source limits or pay for Unleash Enterprise. The decision usually turns on a few concrete facts rather than on feature checklists alone. Count the projects and environments you need today and in the next year, because Unleash Open Source is limited to 1 project and 2 environments. Then list every SDK language your services use and confirm each has a supported Unleash SDK, since client and server coverage differs by language.
Plan the delivery path for flag evaluation early. LaunchDarkly uses the Relay Proxy inside your network, and the Unleash equivalent is Unleash Edge. The open-source version of Edge reaches end of life on December 31, 2026, so any design that depends on Edge for scale needs an Enterprise plan or another caching approach before go-live. Next, settle the licensing position with legal. Unleash moved its server source code to AGPLv3 starting with v8.0.0, while the official open-source Docker images remain under Apache 2.0. Unleash states that running those images unmodified is not affected, but any modified server offered as a public or commercial service must publish its source or buy a commercial license. Confirm that your internal use and any patches fit that position.
Finally, name who operates the stack. Unleash runs against PostgreSQL 15 or later, with the server and admin UI on port 4242, so your platform or database team must own backups, patching, high availability and access to the database. Ask whether the people who will run this work have time for it, and whether SSO, SCIM, custom roles and change requests are required, since those sit in the Enterprise tier. Where those controls are essential, price Enterprise against the operating effort of running the stack yourself. Ask Unleash for a current quote for your exact deployment shape, and confirm feature availability in the Unleash OSS vs Enterprise comparison before you commit.
Which scenarios favor each option
This table matches common buyer situations for LaunchDarkly and self-hosted Unleash to the option that fits best. Read each row for the deciding fact, then check whether the operating work described is work your team can staff.
| Scenario | Better fit | Reason |
|---|---|---|
| Single product team with one application and two environments | Unleash Open Source | The free self-hosted edition allows 1 project and 2 environments, which matches this shape, but you run the server and PostgreSQL 15 or later yourself. |
| Multi-team organization needing SSO, SCIM and custom roles | LaunchDarkly or Unleash Enterprise | Unleash Open Source has basic roles only. SSO, SCIM, project and custom roles, and user groups sit in Unleash Enterprise, which is a paid plan. |
| Data residency or air-gapped requirement | Unleash (self-hosted) | LaunchDarkly manages flags in its hosted service. Self-hosted Unleash can run the dashboard, API and SDK endpoints inside your own network, though you must confirm the exact deployment with your team. |
| Flags only, with no experimentation suite | Unleash | Unleash is built around release flags, gradual rollouts and activation strategies. Confirm the experimentation features you need before you commit, since they are not its focus. |
| Team with no internal platform staff | LaunchDarkly | LaunchDarkly hosts the service, upgrades and availability. Unleash requires you or a partner to run the server, database, backups and upgrades, and Edge if you use it. |
| Large fleet of SDK clients needing a local relay | Evaluate carefully | LaunchDarkly offers the Relay Proxy. Unleash Edge open-source reaches end of life on December 31, 2026, so plan for Enterprise or another caching design. |
| Organization that must keep AGPLv3 modifications private as a service | LaunchDarkly or a commercial Unleash license | Under AGPLv3 (from v8.0.0), publishing source or buying a commercial license is required if you modify Unleash and offer it as a public or commercial service. Confirm with counsel. |
How Unleash Edge replaces the Relay Proxy and why the OSS end-of-life date matters
The Unleash Edge decision is the one most likely to change your architecture, and the open-source version has a hard stop: it entered long-term support on December 12, 2025 and reaches end of life on December 31, 2026. If your LaunchDarkly estate uses the Relay Proxy to serve flags inside a data center, a VPC or a set of Kubernetes clusters, you need a replacement design before that date, not after it. Unleash recommends that OSS Edge users move to an Enterprise plan, so that recommendation should be part of the cost comparison from the start.
The LaunchDarkly Relay Proxy sits inside your network, holds a connection to the SaaS flag service and serves evaluations to local SDKs, which keeps application traffic off the public internet and reduces repeated calls to the vendor. Unleash Edge plays a similar role in the Unleash model: it is a caching layer between SDKs and the Unleash API, so SDKs talk to Edge and Edge talks to your self-hosted Unleash server. Confirm with Unleash how many Edge instances, which regions and which SDK types your design needs, and whether a single-instance Edge is enough for your traffic. Do not commit to a scale pattern based on the diagram alone.
Plan the SDK change as its own work item. Each application that points at a Relay Proxy URL will need its endpoint and client key or token updated, and the team should test latency from each application network to Edge, not only from the Unleash server. Run load tests that mirror your peak flag evaluation rate, and measure what happens when Edge restarts or loses its upstream connection, because the cached state determines what users see during that window. Record the results so the Edge version and its support status are visible to the teams that own those services.
Capabilities side by side: targeting, SDKs, governance and hosting
This table compares how LaunchDarkly and self-hosted Unleash handle targeting, SDKs, governance and hosting for release flags. Read the Unleash column with its free edition limits in mind, because roles, SSO, SCIM and change requests sit in the Enterprise tier. Where the supplied material does not settle a capability, confirm it with the vendor before you commit.
| Capability | LaunchDarkly (hosted) | Self-hosted Unleash |
|---|---|---|
| Targeting and gradual rollouts | Targeting rules and percentage rollouts managed in the hosted dashboard | LaunchDarkly targeting rules map to Unleash activation strategies, including gradual rollouts (confirm strategy parameters in your version) |
| Multivariate flags | Multivariate flags with variations per flag | Mapped to strategy variants; review how each variant is weighted before cutover |
| Segments and prerequisites | Segments and prerequisite flags | Segments map to Unleash segments and prerequisites map to flag dependencies; segments must exist before import |
| SDK coverage | Broad server and client SDK set maintained by LaunchDarkly; confirm your exact languages on its SDK list | Unleash SDKs for common server and client languages; OpenFeature providers reduce coupling, but confirm a provider exists for each of your languages |
| Relay Proxy versus edge caching | Relay Proxy keeps flag evaluation inside your network | Unleash Edge serves as the caching layer; the open-source Edge version reaches end of life on December 31, 2026 |
| Environments and projects | Unlimited projects and environments on paid plans | Open Source allows 1 project and 2 environments; unlimited projects and environments require Enterprise |
| Roles, SSO and SCIM | Role-based access and SSO on paid plans; confirm plan tiers | Basic roles on Open Source; SSO, SCIM, project and custom roles and user groups are Enterprise features |
| Change requests and audit | Approval workflows and audit history; confirm which tier includes them | Change requests are an Enterprise feature; confirm the audit log detail your assessor expects |
| Experimentation | Experimentation is a separate LaunchDarkly product; confirm its scope for your team | Not a focus of Unleash; for experiments, see GrowthBook as a complement |
| Hosting model | SaaS, with an EU instance and a FedRAMP instance; flag management stays in the vendor's service | Self-hosted on your infrastructure with PostgreSQL 15 or later, server and admin UI on port 4242 |
What the AGPLv3 change means for internal use
Starting with Unleash v8.0.0, the server source in the main GitHub repository and the unleash-server npm package moved from Apache 2.0 to AGPLv3. The official open-source Docker images remain under Apache 2.0. Unleash's blog post of June 2, 2026 states that teams running those unmodified images are not affected by the change, which covers the common internal deployment of the unleashorg/unleash-server image against PostgreSQL.
- Image license: The official open-source images stay under Apache 2.0, according to the Unleash blog.
- Internal use: Running the unmodified image for your own employees is the scenario Unleash describes as unaffected.
- Configuration is not modification: Environment variables, feature flags and admin users are set through the product and do not count as changing the source code.
- Deployment target: The same statement applies whether the image runs on your own servers or in your own cloud account.
- Pinned versions: Note which tag you deploy, since the license position is tied to the release line you run.
Confirm with the Unleash blog and your counsel that the image you pull matches this position before you standardize on it.
AGPLv3 is a copyleft license, so the obligations attach to changes made to the server source. Unleash's blog states that anyone who modifies Unleash to offer it as a public or commercial service must publish the source or buy a commercial license. Internal patches are a separate question from patches you run for customers, and your counsel should decide how your patch set is classified.
- Source changes: Forks, custom plugins built into the server and patched builds fall under the copyleft analysis, not the image analysis.
- Internal patches: Changes used only inside your organization are not the public service scenario Unleash describes, but confirm how your counsel reads them.
- Patch tracking: Keep a record of every modification, its version base and where it runs.
- Upgrade cost: Patched servers must be rebased onto each new release, which is recurring engineering effort.
- Alternative: Where a need can be met with configuration, an activation strategy or an SDK-side change, avoid touching the server.
If your team expects to patch the server, have counsel review the plan before the first change is deployed.
The scenario with the clearest stated consequence is offering Unleash to others as a public or commercial service. Unleash's position is that a modified server offered this way must have its source published or be covered by a commercial license from Unleash. This matters for SaaS providers, managed service firms and any business that hosts feature flags for clients, including implementation partners who run Unleash for a client that does not own the instance.
- Hosting for clients: Running a modified server to serve other companies is the case Unleash names directly.
- Commercial license: Unleash offers a commercial route, whose terms you must obtain from Unleash.
- Source publication: Publishing modified source is the other route the blog describes.
- Client-owned instances: Clarify in writing who operates the instance and who holds the license obligations.
- Contract terms: Ensure client agreements reflect the license position, including any source-offer obligations.
Before promising a client a managed Unleash service, obtain written confirmation of the license route from Unleash and your counsel.
The AGPLv3 change applies to the server. Unleash's blog states that the SDKs keep their permissive licenses. Application code that calls an Unleash SDK is therefore governed by the SDK's own license, not by the server's copyleft terms. This separation is what lets product teams embed flag evaluation in their applications without treating their application code as part of the server.
- Server versus SDK: The copyleft change covers the server source, while SDK licenses are stated separately.
- Application code: Your products that call an SDK are not covered by the server license on that basis alone.
- Edge and proxies: Check the license of any caching or proxy component you add between the SDK and the server, since it is a separate piece of software.
- Version pinning: Record SDK versions alongside server versions in your software bill of materials.
- Dependency review: Include the SDK license in your open-source inventory and approval process.
Confirm each SDK license in its own repository, and ask counsel to review any component you build that sits between the SDK and the server.
The licensing picture is tied to specific releases, so the position should be checked against the release you intend to run. The Unleash blog post of June 2, 2026 is the primary statement of the change, and the Unleash release notes and GitHub releases page record what each version contains. The current release line to check against is v8.2.0, released on September 8, 2026, but a later release may exist by the time you read this.
- Primary statement: Read the June 2, 2026 Unleash blog post before relying on any summary, including this one.
- Release line: Confirm the version you deploy is v8.0.0 or later if you rely on the AGPLv3 terms, and check v8.2.0 or newer.
- Release notes: Review the notes for each upgrade, since licensing and edition limits can change between versions.
- Edition boundary: Confirm whether a feature you need belongs to the open-source or Enterprise edition, which is a separate question from license type.
- Written record: Save the license statement and version in your compliance evidence.
Have your counsel confirm the position for your own use before you deploy, and repeat the check at each major upgrade.
Where flag data lives and who runs the control plane
Every flag change passes through a control plane, and who operates it decides where your flag definitions sit, who can read them and what evidence you must produce. This section compares the hosted LaunchDarkly model with a self-hosted Unleash deployment on the points that matter for a renewal or a compliance review.
Where flag definitions are stored
LaunchDarkly keeps flag definitions, targeting rules and environment settings in its hosted service, and your applications pull or stream them through SDKs and the Relay Proxy. With self-hosted Unleash, the server and admin UI run from the unleashorg/unleash-server image against your own PostgreSQL, so flag records live in a database you administer. Check which evaluation data, such as context attributes, leaves your network, because that data is separate from the flag definitions themselves.
Database and network placement
The Unleash getting started guide lists PostgreSQL 15 or later and exposes the server and admin UI on port 4242. Decide whether that port sits behind your reverse proxy, which internal networks can reach the admin UI, and where the database replicas live. Your team owns patching PostgreSQL, sizing it and restricting access, tasks that a SaaS vendor handles for LaunchDarkly.
Identity and SSO by edition
Unleash Open Source provides basic roles only, while Unleash Enterprise adds single sign-on, SCIM provisioning, project and custom roles, user groups and change requests. Confirm in writing which identity capabilities each edition includes before you assume your existing identity provider can govern flag access. Map every admin account to a named owner, and document how leavers lose access to the admin UI and API tokens.
Audit trail and change control
Ask LaunchDarkly what audit log retention and export options your plan includes, and compare that with what your own PostgreSQL and log pipeline will retain for Unleash. Change requests, which give a reviewer step before a flag goes live, are an Enterprise feature in Unleash, so an Open Source deployment needs a documented manual approval process. Record who changed a targeting rule, when and why, and where that record is stored.
Backup and recovery ownership
With LaunchDarkly, the vendor operates the hosted service, but you still hold exported flag definitions for continuity. With Unleash, your team owns database backups, restore tests and the recovery time you commit to internally. Environment import and export moves flag configurations as JSON, but segments and custom strategies must exist in the target before import, so a restore plan must recreate them first.
Mapping each model to compliance evidence
Both models produce different evidence. LaunchDarkly evidence comes largely from vendor reports and contract terms you request, while Unleash evidence comes from your own access reviews, database configuration, backup logs and change records. DeployOpen can prepare systems, controls and evidence for an assessment, but it does not issue audit reports, attestations or certifications, which independent auditors and certification bodies provide.
What LaunchDarkly and self-hosted Unleash cost to own
LaunchDarkly's invoice is driven by usage units: service connections and client-side monthly active users, and some governance features sit in its higher tiers. Before comparing totals, pull your current contract and confirm which units you are billed on, how many service connections your SDKs and Relay Proxy instances open, and which governance controls (approvals, SSO, custom roles, audit retention) your current plan includes. The self-hosted side has no per-unit license fee for the Open Source edition, which is free with 1 project and 2 environments per the Unleash pricing page. If your release process needs more projects, more environments, SSO, SCIM or change requests, those are Enterprise features and you should price them as a subscription. Unleash lists Pay-As-You-Go self-hosted at $75 per seat per month with a 5-seat minimum, and Custom Enterprise on annual contracts for self-hosted or hybrid hosting.
Your one-time work is usually the largest first-year cost: designing the project and environment layout, recreating segments and context fields, mapping targeting rules to activation strategies, wrapping SDK calls if you adopt OpenFeature, running both systems in parallel, and training the teams that create flags. Recurring work is the part people underestimate. It covers PostgreSQL operations (backups, restore tests, major upgrades), hosting for the server and any Edge instances, patching and upgrades of Unleash itself, and on-call coverage for flag evaluation outages, since a flag server sits on the critical path. The Open Source Edge version reaches end of life on December 31, 2026, so if your design depends on Edge, budget either an Enterprise plan or a replacement caching layer.
Costs go up with the number of environments and projects you need, the number of seats that need SSO or approvals, the scale of evaluation traffic on Edge or Relay-style proxies, and how many teams need on-call coverage. They go down when flag ownership is clear and stale flags are cleaned up. In a written quote, ask the vendor or implementer for: the Unleash tier and seat count, the hosting model, which features are included versus add-ons, support hours, and the upgrade policy. Ask DeployOpen for a fixed-scope proposal covering setup, migration, SDK changes, hardening, backup, documentation and an optional support retainer. DeployOpen does not publish prices, and a quote follows from the written scope agreed before work starts.
How a move from LaunchDarkly to Unleash runs in practice
The sequence turns LaunchDarkly flag definitions into Unleash configuration, keeps both systems in agreement during a parallel run, and cuts traffic over in controlled waves so users keep the same flag outcomes. The Unleash migration guide of August 20, 2026 is the reference for the mapping and ordering.
Inventory flags, segments, environments and SDK usage
Your engineering lead and the platform team list every LaunchDarkly project, environment, flag, segment and prerequisite, and record which applications call the LaunchDarkly SDK and the Relay Proxy. Flag each flag as release, experiment or operational, because release flags map most directly to Unleash. The inventory is done when every flag has an owner, a status and a list of consuming services, and the team has confirmed which flags are stale and can be retired before the move.
Export flag and segment definitions as JSON
An engineer exports flag and segment definitions through the LaunchDarkly REST API using a scoped access token, storing each environment as a separate JSON file under version control. Confirm the export covers targeting rules, variations, prerequisites and segment membership rules, and keep a dated copy as the rollback reference. The step is complete when a second engineer can reproduce the file count and flag keys from the API and the team has signed off the source snapshot.
Recreate context fields and segments first
Before any flag is imported, the platform team recreates the context fields and segments in the target Unleash instance. This order matters because Unleash's environment import and export references segments and custom strategies as names only, so a flag that depends on a missing segment will fail or evaluate incorrectly. The step is done when every segment referenced in the exported JSON exists in the target and a test import into a non-production environment completes without missing references.
Map targeting rules to activation strategies
Architects translate each LaunchDarkly targeting rule into an Unleash activation strategy, map multivariate flags to strategy variants, and convert prerequisites into flag dependencies, following the mapping in the Unleash guide. Where a LaunchDarkly rule has no direct equivalent, record the gap and decide whether to move the logic into application code or a custom strategy. The step closes with a mapping document that lists each source rule, its target strategy and any open differences, reviewed by the owning product teams.
Import flags and verify them in staging
Engineers apply the mapped definitions to a staging Unleash environment, using the Admin API or the import feature, and then run evaluation tests for representative users in each context. Compare results against LaunchDarkly for the same contexts, including edge cases such as missing attributes and default variations. The step is done when the staging comparison shows matching outcomes for every flag in the test set and each difference has a documented decision.
Replace SDK calls, ideally behind OpenFeature
Application teams replace direct LaunchDarkly SDK calls with an abstraction layer, preferably the CNCF OpenFeature API with the LaunchDarkly provider first, then switch the provider to Unleash. This lets services move one at a time and keeps evaluation code stable during the change. Confirm the SDK languages in use are covered by an OpenFeature provider, and track which services have changed. The step is complete when every consuming service evaluates flags through the abstraction and no direct LaunchDarkly calls remain in the code base.
Run both systems in parallel
Operate LaunchDarkly and Unleash side by side, with the abstraction layer able to read from either, and compare evaluation results and metrics for live traffic. Pay particular attention to partial rollouts, where a change in bucketing key, hashing or context attributes can move users to a different variation and cause re-bucketing. The step closes when the team has observed agreement across the agreed period and has confirmed that partial rollouts keep the same user assignments in both systems.
Cut over in controlled waves
Move traffic to Unleash in waves, starting with low-risk services and internal users, then widening to customer-facing applications, with a tested rollback path back to LaunchDarkly at each wave. Keep the Unleash Edge design decision in view, since the open-source version of Edge reaches end of life on December 31, 2026, so confirm the caching and delivery architecture before production scale. Retire LaunchDarkly only after each wave has been stable and the team has documented the final state and owners.
Questions buyers ask before a LaunchDarkly to Unleash move
What does a move from LaunchDarkly to Unleash cost, and what drives it?
The cost has three parts: the Unleash software, the infrastructure that runs it, and the people who migrate and operate it. Unleash Open Source is free to self-host, but it is capped at 1 project and 2 environments with basic roles. Unleash's pricing page lists Pay-As-You-Go at $75 per seat per month with a 5-seat minimum for self-hosted deployments, and Custom Enterprise on annual contracts, so the licensing line depends on which tier you need. Drivers include the number of projects and environments, whether you need SSO or SCIM, the size of your flag estimate, and how many LaunchDarkly definitions must be recreated by hand. Ask for a written quote that separates one-time migration work from recurring licensing, hosting and support.
How long does a LaunchDarkly to Unleash migration take?
No fixed duration is set by the supplied sources, so treat any timeline as something to confirm in a written scope. The main drivers are the number of flags and segments, how many targeting rules use attributes that must be recreated as context fields, whether you have multivariate flags or prerequisites that map to flag dependencies, and how long you run both systems in parallel behind an abstraction layer. Partial rollouts also need care so that users are not re-bucketed during cutover. Ask the vendor or implementation partner to list each phase, its deliverables and the acceptance criteria for cutover.
What does the migration need from our engineering team?
Expect work from platform engineers, application owners and whoever administers LaunchDarkly today. Platform engineers deploy Unleash on PostgreSQL 15 or later and expose the server and admin UI on port 4242. Application owners replace LaunchDarkly SDK calls, or wrap them first, and test each flag's behavior. Someone must export LaunchDarkly flag and segment definitions as JSON through the REST API, then recreate them through the Admin API or the import feature. Segments and custom strategies must exist in the target before import. Ask for named roles, expected hours per role and a sign-off process for each environment.
Can our team migrate to Unleash by following the Unleash documentation alone?
A capable team can migrate on its own if it has time, a small flag inventory and engineers comfortable with APIs and deployment. The Unleash getting started guide and the migration guide from its blog cover deployment, the LaunchDarkly export and the mapping of targeting rules to activation strategies. The gaps are usually in volume and risk: parallel running, rollout continuity, SDK replacement across many services and sign-off in regulated change processes. If those are hard to staff, a fixed-scope engagement with a written deliverable list can cover the same steps. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms in your own infrastructure.
Are the Unleash Open Source limits enough for our flags?
Open Source fits a single project with up to two environments, such as one application running in development and production. It also carries a limit of 5,000 feature flags per instance, according to the Unleash pricing page. Teams with several products, separate staging and production tiers, or a need for SSO, SCIM, project roles, user groups or change requests usually need Unleash Enterprise, which adds unlimited projects and environments. Count your projects, environments and the approval controls your change process requires, then confirm the current limits with Unleash before you commit.
What happens to Unleash Edge after December 31, 2026?
The open-source version of Unleash Edge, the caching layer between SDKs and the Unleash API, enters long-term support on December 12, 2025 and reaches end of life on December 31, 2026. Unleash recommends that OSS Edge users move to an Enterprise plan. If your design relies on Edge to serve many SDK clients, plan a replacement or an upgrade before that date. Ask for the Edge architecture in your written scope, including how SDKs connect, how many instances you expect and the upgrade path you will follow.
How does the AGPLv3 license change affect internal use of Unleash?
Starting with v8.0.0, the server source code moved from Apache 2.0 to AGPLv3, but the official open-source Docker images remain under Apache 2.0. Unleash states that running the official images without modifying the source does not trigger the change. Modifying Unleash and offering it as a public or commercial service requires publishing that source or buying a commercial license. Ask your legal team to confirm whether any internal patches, custom strategies or wrapper services fall into that category before deployment.
How DeployOpen works on this
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a LaunchDarkly to Unleash move, we start with a written scope that fixes what is covered before any work begins.
How we scope
- We inventory LaunchDarkly projects, environments, flags, segments and Relay Proxy deployments in use
- We confirm which Unleash edition fits, including the 1 project and 2 environment limit of Open Source
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
How we build
- We deploy Unleash on PostgreSQL in your cloud account, data center or isolated network
- We map targeting rules to activation strategies and test each mapped flag against expected results
- We plan the Unleash Edge design, accounting for the open-source Edge end of life on December 31, 2026
How we hand over
- We deliver configuration, runbooks, backup and upgrade procedures, and a record of mapped flags
- We document the AGPLv3 position for your internal use and any modifications, for your legal review
- We run parallel evaluation with you before cutover and walk your team through the handover
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- We can keep the Unleash deployment hardened and patched as new releases ship
- Compliance evidence for your own assessments is prepared with you, while auditors issue any reports
