LaunchDarkly doesn’t offer self-hosting. Here’s what to use instead

Your security team flags it during procurement: with a cloud-only platform like LaunchDarkly, all user evaluation context (attributes, identifiers, segment data) routes through a third-party cloud you don’t control. For a fintech, a healthcare provider, or a government contractor with data residency requirements, that’s a procurement blocker, not a risk to be managed.

LaunchDarkly and several other feature management platforms operate cloud-only by design — there is no self-hosted path, no private-cloud add-on, and no relay that changes where the control plane lives. So the question shifts from “can we self-host LaunchDarkly?” to “what must a self-hosted replacement do before we commit to one?”

TL;DR

• Cloud-only platforms block procurement for fintech, healthcare, and government teams.
• Self-hosting provides data residency and local evaluation to keep PII within your infrastructure.
• Self-hosting requires internal governance controls: RBAC, change approvals, and audit logs.
• Migration success depends on SDK coverage and targeting rule parity.
• Open-source architecture prevents vendor lock-in and preserves long-term portability.

Why LaunchDarkly stays cloud-only, and who that rules out

Cloud-only platforms design their architecture to deliver real-time flag changes without redeployment or restart. LaunchDarkly’s own documentation states the central requirement: flags must be able to change at any time and take effect immediately. That delivery model depends on persistent infrastructure the vendor controls, not a server an organization spins up internally.

The infrastructure requirements drive this decision rather than licensing models. The platform requires multiple interdependent services, managed databases, and high-availability APIs. Replicating that architecture internally at comparable reliability would effectively mean building a feature management platform from scratch.

Three buyer profiles often find cloud-only models incompatible with their requirements. Regulated industries (financial services, healthcare, government) often face data residency mandates that prohibit sending evaluation context, including user attributes, to third-party infrastructure. Teams operating in air-gapped or sovereign cloud environments have no network path to an external SaaS at all. And organizations with security policies that prohibit any user data leaving internal systems hit the same outcome: cloud-only architecture is incompatible before the feature conversation starts.

What self-hosting buys you: data residency and local evaluation

Self-hosting covers two capabilities that serve different security requirements. Buyers who conflate them often pick an architecture that doesn’t fully meet their needs.

Data residency

Data residency means the control plane (flag definitions, targeting rules, change history) lives on infrastructure teams own: their database, their cloud account, their data center. No flag configuration or audit record routes through a third-party system. For organizations under GDPR, HIPAA, or similar frameworks, residency often determines whether the tool is permissible at all.

Local evaluation

Local evaluation goes further. The SDK evaluates flag rules against a locally cached copy of the ruleset, so no evaluation request ever leaves your environment. For GDPR compliance, that gap matters: flag evaluation often requires user attributes like cohort membership or geography, and with local evaluation those attributes never travel to an external system.

Unleash Enterprise Edge handles both layers. It sits between your SDKs and the Unleash server to evaluate flags locally, so PII stays inside your infrastructure on every call. For air-gapped environments, Edge supports an offline mode that serves flag decisions from a local bootstrap file, with no network call required.

Self-hosting isn’t the right trade-off for every team. Under roughly 50 engineers without active compliance mandates, the operational overhead adds up: a PostgreSQL instance to manage, schema migrations on upgrades, and high availability to maintain. Those are real platform engineering hours. For teams where data sovereignty is a genuine requirement, self-hosting provides the lowest total cost of ownership, but that calculus shifts when a small team is carrying the operational overhead without a mandate that requires it.

Governance and compliance when flags run inside your environment

A self-hosted control plane doesn’t automatically satisfy a compliance audit. A regulated organization needs more than data residency. It needs documented evidence: who can change a flag, whether changes require approval first, and a timestamped log of every modification. When the control plane is self-hosted, those controls must run inside your environment too. A self-hosted deployment without them leaves a gap that a SOC 2 auditor or GDPR data protection officer will find quickly.

RBAC and change requests

Unleash Enterprise includes role-based access control with custom root roles. Organizations define who can create, modify, and archive flags across environments. Change request workflows require explicit approval before a flag goes live. The approval-gate model that cloud-only platforms run on their own infrastructure runs inside yours instead.

Audit logs

Every flag change, approval, and role assignment is recorded in an immutable audit log. For GDPR reviews and SOC 2 assessments, this log provides the documentation trail compliance teams require without relying on a vendor’s infrastructure to produce it.

Compliance integration at scale

Prudential uses Unleash Enterprise to handle feature flags across an environment that spans COBOL mainframes to AI microservices. Their compliance requirement extended beyond data residency to include removing the manual overhead of ticketing every flag change through ServiceNow. The integration coordinates flag changes and approvals automatically in the background. According to the Prudential case study, “developers never have to see ServiceNow. They simply interact with Unleash, and all changes and approvals are automatically synced in the background.” The compliance record exists; the developer friction doesn’t.

Prudential achieves this because the governance controls run inside their environment, not on a vendor’s servers. A cloud-only platform with equivalent governance features would still route approval data and audit records through external infrastructure, failing the same data residency requirement the organization is trying to satisfy.

Migration checklist: SDK coverage, targeting rules, and flag types

Standing up a self-hosted server takes an afternoon. The migration risk sits in the targeting rule layer, not the infrastructure layer. A flag with three nested conditions, a custom attribute, and a percentage rollout does not automatically map to the same flag in another platform. Before starting any migration, work through these four areas:

• List every language and framework the applications use. Verify each has a maintained SDK with a recent release. Missing SDK support means one team can’t migrate until a new SDK ships, and that gap tends to surface after the migration is already underway.
• Export and document every complex targeting rule before you touch the new platform. Segment definitions, custom attribute operators, and multi-condition rules rarely map 1:1 between platforms. Treat each complex rule as a manual translation, not an automated import.
• Boolean flags migrate without issues. Multivariate flags and JSON flags require careful re-mapping. Confirm the replacement supports every flag type the applications use, including any that power emergency shut-off toggles, load shedding controls, or entitlement logic.
• If you’re running more than a handful of environments, verify the replacement handles environment-based customizations and least-privilege permissions. Tink (a Visa solution) runs flags across 25+ services and 20 environments with Unleash, with releases decoupled from deployments and instant rollbacks available. Environment complexity often causes migration plans to break down without upfront documentation.

At production scale, the platform must process the traffic load those flags serve. For example, Wayfair’s Unleash deployment works for thousands of engineers and processes peak traffic of over 20,000 requests per second. Mark Quigley, Wayfair’s Head of Internal Developer Platforms, confirmed publicly that Unleash significantly reduced operational costs compared to their previous homegrown system, while improving reliability and scalability.

Open source foundation, no vendor lock-in

For enterprise buyers, open source serves as an architectural risk hedge, not a pricing argument alone.

If a commercial vendor changes pricing, is acquired, or discontinues a feature, teams on a closed platform have no exit path beyond rebuilding or accepting the change. An open source platform means the organization retains full access to the source code regardless of what happens to the vendor. You can fork, self-manage, and continue operating independently. Code portability matters to procurement and legal teams evaluating long-term platform commitments.

Open source also means the codebase is auditable. Security teams can inspect how flag evaluation works, how SDKs handle PII, and what the server does with targeting context. For organizations that require code review as part of security assessments, a closed-source platform cannot satisfy that requirement. For teams able to self-host, the total cost is primarily infrastructure-based: a single Docker container that doesn’t scale with user traffic or seat counts the way cloud-only pricing does.

Evaluating Unleash Enterprise for self-hosted environments

Unleash Enterprise runs on your infrastructure: your own cloud account, a private data center, or a managed private cloud environment. The managed option provides the control of self-hosting without running your own database.

Deploy with a Docker image to get running quickly, or use a Helm chart on Kubernetes if you already run container orchestration. Add Unleash Edge in front of the server for local flag evaluation and PII boundary enforcement. The same RBAC, change request workflows, and audit logs that satisfy compliance requirements in the Prudential deployment run inside your environment, not on Unleash’s servers.

If data residency or air-gapped operation is a hard compliance requirement, self-hosting is the path, and the four criteria this article covers give you a framework to evaluate any platform against it. If self-hosting is a preference rather than a mandate, weigh the migration checklist against what you gain. The operational overhead is real, and it’s worth carrying when the requirement is genuine.

If you began by looking for a self-hosted version of LaunchDarkly, you now have a sharper set of criteria: does the replacement satisfy data residency architecture, local evaluation, governance controls, and migration fidelity? A platform that answers yes to all four is a viable replacement. One that answers only the deployment question leaves the compliance problem open.

FAQs about LaunchDarkly self-hosting alternatives

How does the cost of self-hosting Unleash compare to LaunchDarkly?

The pricing models differ in kind. LaunchDarkly scales with monthly active users (MAUs) and service connections, so cost climbs with traffic and architecture. A self-hosted Unleash deployment is primarily infrastructure-based, often running as a single Docker container. So cost tracks your infrastructure and required seats, rather than user volume. Model both against your own traffic and seat projections to compare like for like.

How long does a migration from LaunchDarkly to a self-hosted platform take?

Most teams complete the core infrastructure setup in an afternoon, but a full migration typically runs a few weeks. The timeline depends on auditing existing SDKs and manually re-mapping complex targeting rules, since segment definitions and custom attribute operators rarely map 1:1 between platforms.

What happens to flag evaluation if the self-hosted server goes down?

If the central server becomes unavailable, SDKs fall back to the last known good configuration cached locally, or to a set of hard-coded default values. That keeps flag evaluation serving and prevents the flag service from becoming a single point of failure in the request path until the connection is restored.

Can I run feature flags in air-gapped or offline environments?

Yes. Self-hosted Unleash supports air-gapped operation using a local bootstrap file. In this mode, the application serves flag decisions from a local configuration without making any network calls to an external control plane, a requirement for many government and high-security financial environments.

Is a relay proxy the same as full self-hosting?

No. A relay proxy only moves evaluation closer to your infrastructure while the control plane stays on the vendor’s cloud. Full self-hosting keeps both the control plane and the data on your own servers, which is what satisfies strict data residency and PII protection mandates.