Self-hosted LaunchDarkly alternative for air-gapped networks

Why a self-hosted LaunchDarkly alternative fits air-gapped networks

LaunchDarkly's flag management stays in its SaaS even with the Relay Proxy, so a self-hosted flag server such as Unleash or Flagsmith is the usual replacement for a network that cannot reach LaunchDarkly's hosted service. Consider a platform team whose application servers sit in an enclave with no outbound internet route (an illustrative case). Their SDKs can only call hosts inside that enclave, so every flag evaluation and every flag change has to be served from infrastructure the team operates. The Relay Proxy keeps evaluations local, but the source of truth for flags still lives in LaunchDarkly's cloud, which is why it does not remove the dependency.

LaunchDarkly's Enterprise-only offline mode lets SDKs evaluate flags from a *file archive* instead of a live connection. That archive is a snapshot, so someone must generate it, carry it across the boundary and refresh it on a schedule, and the team must confirm that a stale file cannot silently change application behavior. Ask LaunchDarkly to confirm how the archive is produced, how often it must be refreshed in your environment and what happens to flags changed after the last snapshot. If you operate under NERC CIP-013-2, the file crossing your boundary also falls under its supply chain expectations for verifying software integrity. A self-hosted server removes the refresh cycle because the flag server runs inside the network, but you then own its patching and backups.

The right choice depends on two things: the license tier you need and who will run the service. Unleash Open Source is free to self-host but limited to 1 project and 2 environments, so a multi-team estate will likely need an Enterprise plan that adds single sign-on and custom roles. Flagsmith's open-source version has no API request limits, but SAML single sign-on and role-based access control are Enterprise features. Confirm the license for each feature you need before design, and decide whether your own staff or a partner will handle upgrades, backups and the database. The Unleash self-hosting getting started guide is a practical starting point for checking the deployment requirements.

What an air-gapped flag server must do

An isolated network changes what a flag server has to do on its own, from serving evaluations to receiving software. The cards below cover the requirements that follow from that constraint, and each one is a decision your team should make before a pilot starts.

Serve flags and SDK traffic inside the boundary

Flag evaluation and SDK synchronization must reach a server that sits in your network, so applications never call out to a vendor endpoint. Unleash listens on port 4242 for both the server and admin UI, which makes that port the first firewall rule to define. Confirm which SDK client types need the API, and whether any Edge or caching layer also runs inside the boundary.

No outbound calls during evaluation

Evaluation must work when the flag server is unreachable from the internet and from any vendor service. Check every SDK, telemetry setting and admin plugin for background calls, because a single default endpoint can break the isolation claim. Test the application with outbound routes blocked and record what happens when the flag server restarts.

Controlled import of software and updates

Container images, Helm charts, database packages and updated SDKs all cross the boundary as files you have checked. Plan a repeatable intake step that records the artifact, its checksum and its source before it enters the network. This is the practical control behind verifying vendor software integrity under NERC CIP-013-2 for the utilities that fall under it.

A PostgreSQL database your team operates

Unleash runs against PostgreSQL 15 or later, so the database version becomes a supported-version decision you own. Decide whether the database is managed inside the boundary or built by your platform team, and who applies patches and restores backups. Ask who holds the database credentials and how they are rotated.

Offline behavior of the caching layer

If you plan to scale SDK delivery with Unleash Edge, confirm that the offline setup you choose is supported for your edition. The open-source Edge version reaches end of life on December 31, 2026, so any design that depends on it needs a dated replacement plan. Record which component serves flags during an outage of the main server.

Licensing that fits internal use

Before you deploy, confirm which license applies to the exact image and version you pull into the network. Unleash moved its server source to AGPLv3 starting with v8.0.0, while the official open-source Docker images remain under Apache 2.0. Have legal review how that applies if your team modifies the server or exposes it to outside users.

Where LaunchDarkly's offline mode and Relay Proxy stop short

The first limit is that flag management stays in LaunchDarkly's hosted service. Flag definitions, targeting rules, approvals and change history live there, so a network with no route to the SaaS can evaluate flags it already holds but cannot create, edit or audit them in LaunchDarkly. The Relay Proxy is often mistaken for a fix. It runs inside your network and serves flag data to SDKs with lower latency, but it still takes its configuration from LaunchDarkly. In an isolated network, it is a local delivery layer for a configuration that originates outside the boundary.

Offline mode is the other option, and it is an Enterprise feature. It serves flags from a file archive instead of a live connection, so the network runs on whatever the archive contained when it was produced. Every change made upstream reaches the isolated network only after a new archive is generated, carried across the boundary and loaded. A stale archive means a kill switch or rollout change can lag behind what the business has already decided. Each transfer also needs an approved process with integrity checks on the file. If your environment falls under NERC CIP-013-2, that supply chain control applies to what you carry across the boundary.

Before relying on either model, confirm the current behavior in writing with LaunchDarkly. Ask whether offline mode is included in your contract and which plan carries it, how the archive is generated and what it contains (including segments, prerequisites and environments), how often LaunchDarkly expects it to be refreshed, what happens when an archive expires, which SDK versions support it, and whether the Relay Proxy can run without any outbound connection. Check current plan terms on the LaunchDarkly pricing page and document the answers, because they determine whether this design meets your change-control requirements.

Which open-source options meet the constraint

This table compares self-hosted Unleash and Flagsmith on how their dashboard, API and SDK endpoints run inside an isolated network, with GrowthBook noted for experimentation only. Read each row as a condition to confirm in your own environment before you choose. The main takeaway is that both can run inside the boundary, but the edition, licence and caching choices decide what you actually get.

Requirement	Self-hosted Unleash	Self-hosted Flagsmith
Runs dashboard, API and SDK endpoints in isolation	Server and admin UI listen on port 4242 against PostgreSQL 15 or later, so the whole stack can sit on internal hosts	Runs from Docker, Docker Compose or the official Helm chart, with an external database recommended for production
Project and environment limits on free edition	Open Source allows 1 project, 2 environments and 5,000 feature flags per instance; Enterprise removes project and environment caps	Free self-hosted version has no API request limits; RBAC and SAML are Enterprise features
Role and identity controls	Basic roles in Open Source; SSO, SCIM, custom roles and change requests require Enterprise	Role-based access control, SAML and Okta integrations are Enterprise features and require a license
Edge or proxy for scale inside the network	Open-source Edge reaches end of life on December 31, 2026; plan an Enterprise path or another caching design	Optional Edge Proxies for lower latency are listed in its self-hosting documentation; confirm fit for your topology
License change to check before upgrading	From v8.0.0 the server source moved to AGPLv3; official Docker images stay Apache 2.0 unless you modify the source	Majority of code is BSD 3-Clause; Enterprise Edition features are closed source
Migration from LaunchDarkly inside the network	Export flags and segments as JSON through the LaunchDarkly REST API, then recreate them in Unleash before running both in parallel	Built-in importer reads projects and environments through the LaunchDarkly REST API, so the source must be reachable from the import host
Experimentation (note only)	Not a focus of the Unleash server; pair with a separate experimentation tool if needed	Not a focus of the Flagsmith server; confirm experiment features against your requirements

How to deploy Unleash or Flagsmith inside an air-gapped network

This sequence takes a flag server from an internet-connected staging build to a running, verified instance inside an isolated network, with every container image, chart and package checked before it crosses the boundary.

Choose the platform and size the scope
The platform team, with security and the application owners, decides between Unleash and Flagsmith based on licensing, the features needed (SSO, RBAC, change requests) and whether the Enterprise tier is required. Unleash Open Source allows 1 project and 2 environments, while Flagsmith's open-source version has no API request limits but keeps RBAC and SAML in its Enterprise edition. The step closes with a written list of images, charts and licenses to mirror, which the reviewers sign off.
Mirror images and charts through a controlled transfer
An operator in the connected staging zone pulls the unleashorg/unleash-server image (or unleashorg/unleash-enterprise), the Flagsmith container images and the flagsmith/flagsmith Helm chart, plus the PostgreSQL image if it will run in the cluster. Each artifact is pushed to the internal registry and listed in a manifest with its version and digest. The step is complete when the internal registry lists every artifact in the manifest and the transfer media is logged under the change ticket.
Verify package integrity before import
Before the transfer media crosses the boundary, the security team checks each artifact against the published checksums or signatures, and rescans the images with the scanner that the organization already runs. This control supports the software integrity expectations in NERC CIP-013-2 where that standard applies. The step closes when every artifact has a recorded verification result and any failure has been rejected and re-sourced.
Stand up PostgreSQL 15 or later
The database team provisions a PostgreSQL instance on version 15 or later inside the enclave, with its own backup schedule, encryption at rest and access limited to the flag server's service account. Flagsmith's Helm chart creates a database in the cluster by default, but its documentation recommends an externally managed database in production, so the team points the chart at this instance. The step closes when a test connection from the application network succeeds and the backup job has completed one restore test.
Deploy the flag server from internal sources
The platform team runs the unleashorg/unleash-server image on the internal registry, or deploys Flagsmith with Docker Compose or the Helm chart pointed at the internal registry, using the external database. Both servers listen on port 4242 for Unleash or the Flagsmith ports in its documentation, and the team sets the admin credentials through its secrets store rather than in the chart values. The step closes when the admin UI loads inside the network and the health endpoint reports the database as connected.
Configure SDK endpoints and network paths
The platform team exposes the flag API only to application subnets, restricts the admin UI to the management network, and assigns each SDK a server-side token scoped to its environment. Services that need caching at scale can use Unleash Edge or Flagsmith's Edge Proxy, but the open-source Unleash Edge reaches end of life on December 31, 2026, so teams confirm the supported path before design. The step closes when a test service in the application subnet receives flag evaluations and a host outside it cannot reach the API.
Load flag configuration and plan updates
Flag definitions are imported from a reviewed JSON export, with segments and custom strategies created in the target first because Unleash exports them as references. Flagsmith's LaunchDarkly importer, if used, overwrites data in the target project, so teams import into a fresh project and check flags by hand. Each future update follows the same path: a new transfer of artifacts with a fresh manifest, verification, staging and a rollback copy of the database. The step closes when a dated runbook records this cycle and the first update has been rehearsed.

Kubernetes, Docker Compose or OpenShift for isolated clusters

Docker Compose suits a small, isolated host that runs one flag server for a limited set of applications. Both Unleash and Flagsmith document Docker-based quick starts, so the runtime footprint is a single host, a database and the application containers. Unleash's getting started guide runs the unleashorg/unleash-server image against PostgreSQL 15 or later, with the server and admin UI listening on port 4242. Flagsmith's self-hosting documentation lists Docker and Docker Compose for quick starts, along with an asynchronous task processor, Redis caching options and optional Edge Proxies.

Image transfer: Export the images on a connected staging host, move them through your approved media process and load them on the isolated host. Keep the image digests in your change record.
Database ownership: Run PostgreSQL outside the Compose file where possible, so backups and patching follow your database standard.
Single point of failure: One host means one outage domain. Document the recovery procedure and test it.
Update path: Upgrades arrive as new image sets, so plan who builds, scans and carries each release across the boundary.
Edge components: Confirm whether you need an Edge or proxy tier at all for your SDK volume.

Confirm the exact image names, tags and environment variables against the current documentation for the version you select, and test the import in a staging enclave before the cutover.

Kubernetes fits teams that already run clusters and want flag servers managed alongside other workloads. A cluster built without internet access depends on preparing every image in advance. The Kubernetes kubeadm documentation describes using kubeadm config images list and kubeadm config images pull to fetch the control plane images, and the --image-repository flag on kubeadm init to point at a private registry. Application images, the Flagsmith Helm chart and any Unleash or Flagsmith dependencies must follow the same mirroring process.

Control plane images: Pull the kubeadm image list on a connected host, push it to your internal registry and reference that registry during initialization.
Chart and image mirroring: Download the Flagsmith chart from its official Helm repository, verify it, and mirror every image it references into the internal registry.
Database placement: The Flagsmith chart creates its own PostgreSQL server by default. The docs recommend an externally managed database in production, with optional PgBouncer, so decide who operates that database.
Network policy: Restrict egress so pods cannot reach public registries or SaaS endpoints by accident.
Operations: Your platform team owns cluster upgrades, certificate rotation and node patching, which add recurring effort beyond the flag server itself.

Confirm your registry, mirroring and signature verification steps with your platform team and the owner of your software supply chain controls, because the process differs by cluster distribution.

Evidence auditors and regulators ask for

An air-gapped flag server is judged on what crossed the boundary, who changed flags, and how the team proved each package was genuine. The cards below list the records to build before the first assessment, so the evidence exists when a reviewer asks for it. DeployOpen prepares these systems and evidence packs, but independent auditors and certification bodies issue any audit report or certification.

Software bill of materials for imports

Keep a software bill of materials for every image, chart and package carried into the isolated network, including the Unleash or Flagsmith server image, the PostgreSQL version, and any Edge or proxy component. Record the source, version and digest for each item at the point of download. Check that the list matches what runs in the cluster, because a reviewer will compare the two. Confirm with the vendor which artifacts are published with signatures or checksums.

Integrity checks on each transfer

Each media transfer across the boundary needs a recorded hash, a verification step on the inside, and a named person who approved it. Store the checksum list separately from the media so a tampered package cannot update its own record. Repeat the check for every update cycle, not only the first install. Ask your provider how it hashes container images and whether it can reproduce a build from source.

Flag change records

Auditors look for who changed a production flag, when, what the value was before, and who approved it. Unleash Enterprise offers change requests and user groups, while Flagsmith places roles, permissions, change requests and audit logs on its Scale-Up plan and above. The Unleash Open Source edition is limited to basic roles, so plan approvals and log retention before choosing an edition. Export the audit trail to a central store on your own network.

Access control and identity records

Document which people and service accounts can reach the dashboard, API tokens and database, and how each is granted and removed. Single sign-on and SCIM provisioning are Enterprise features in both Unleash and Flagsmith, so the identity source and its logs become part of the evidence. Keep access reviews on a fixed schedule and retain the results. Confirm which controls your edition provides before you design the process around them.

NERC CIP-013-2 supply chain procedures

NERC CIP-013-2 is the control that asks for supply chain processes covering the verification of software integrity and authenticity for vendor software and patches. Write a procedure that names the verification steps for each import, the people who sign off, and the action taken when a check fails. Pair it with the bill of materials and transfer records so each procedure points to real evidence. Ask counsel or your compliance lead to confirm which CIP requirements apply to your systems.

Vendor access and session logs

NERC CIP-005-7 expects interactive remote access to pass through an intermediate system, and it expects methods to detect and disable active vendor sessions. Apply that thinking to support work on the flag server: record every vendor login, the session window, the commands run and the approval for each. Keep the flag server's own logs and the access broker logs in the same retention system. Confirm with your assessor which remote access controls apply to this system.

Questions buyers ask before an air-gapped flag server project

What drives the cost of a self-hosted flag server in an air-gapped network?

The cost is driven by who builds, runs and maintains the stack, not by a subscription fee for the software itself. Cost components include the infrastructure inside your isolated network (compute, PostgreSQL, backups, and any load balancing), the internal staff time to operate and patch it, and any external implementation fee agreed in a written, fixed scope. Unleash Open Source is free to self-host with 1 project and 2 environments, according to the Unleash pricing page, while Unleash Pay-As-You-Go lists $75 per seat per month with a 5-seat minimum for self-hosted. Ask any provider for a quote that separates one-time setup from recurring operations and identifies which features, such as SSO or change requests, require a paid tier.

How long does an air-gapped flag server project take?

No supplied figure gives a duration for this project, so the timeline depends on your environment. The main variables are how many applications and environments need flags, whether SSO and SCIM are required, how your container images and packages are approved for transfer across the boundary, and how much of the LaunchDarkly migration is in scope. Ask for a timeline in the written scope, with milestones for image transfer, database setup, SDK changes and cutover, and confirm which items depend on your change approval process.

What does the client team need to provide for this project?

Expect to supply people and access, not just approvals. You will need an owner for the isolated network, someone who can approve and transfer container images and packages across the boundary, a PostgreSQL administrator, and application engineers who can change SDK calls. Kubernetes or Docker hosts inside the network also need a registry or a process for loading images. Confirm with the provider who holds the LaunchDarkly access token used for export, where the data will live and who signs off on each transfer.

Can our own team build and run the air-gapped flag server without an outside partner?

Yes, a capable platform team can deploy Unleash or Flagsmith from their own images, provided they have the skills to operate PostgreSQL, container platforms and upgrades inside a closed network. Flagsmith publishes an official Helm chart, but its docs recommend an externally managed database in production, and its OpenShift Operator support requires an Enterprise plan. Unleash's getting started guide runs the server image against PostgreSQL 15 or later on port 4242. The real question is ongoing upgrades and patching, so ask whether your team can absorb those recurring tasks.

Does Unleash Edge end of life affect an air-gapped design?

Yes, if your design depends on the open-source version of Unleash Edge. According to the Unleash Edge documentation, OSS Edge entered long-term support on December 12, 2025 and reaches end of life on December 31, 2026, and Unleash recommends OSS Edge users move to an Enterprise plan. Plan for either an Enterprise subscription, a different caching approach, or a design that serves SDKs directly from the server. Flagsmith's Edge Proxy is an alternative to evaluate, and you should confirm its support status with the vendor before committing.

Does the AGPLv3 change in Unleash affect internal use inside our network?

For internal use of unmodified official open-source images, Unleash's blog states the AGPLv3 change does not affect you. Starting with v8.0.0, the server source code moved from Apache 2.0 to AGPLv3, but the official Docker images stay under Apache 2.0 and the SDKs keep permissive licenses. The obligation applies if you modify Unleash and offer it as a public or commercial service, in which case you must publish the source or buy a commercial license. Have your legal team confirm the position for any modified build, and note that Unleash v8.2.0 was released on September 8, 2026.

What is the migration path from LaunchDarkly to a self-hosted server?

Export flag and segment definitions from LaunchDarkly through its REST API, map targeting rules to activation strategies, recreate segments and context fields in the target first, then run both systems in parallel behind an abstraction layer before cutting over. Unleash's August 20, 2026 migration guide maps LaunchDarkly prerequisites to flag dependencies and the Relay Proxy to Unleash Edge. Flagsmith has a built-in LaunchDarkly importer that overwrites existing data in the target project, so import into a fresh project. Within an air-gapped network, the export step runs on a connected staging host, and the exported JSON must be checked before it crosses the boundary.

What do Flagsmith Enterprise features cost, and which ones need them?

Flagsmith lists Enterprise at custom pricing with cloud, private cloud or self-hosted deployment, so there is no published figure to compare. Its pricing page places SAML single sign-on and governance features such as roles, permissions, change requests and audit logs at the Scale-Up plan, which is $250 per month billed yearly. Flagsmith's FAQ states that SAML, Okta and role-based access control are Enterprise features, and the self-hosted open-source version has no API request limits. Ask Flagsmith for a written quote covering self-hosted licensing and support.

How to move flags out of LaunchDarkly while the network is isolated

Export every flag and segment definition from LaunchDarkly while the network still has a route to its REST API. Once the boundary closes, the isolated side cannot reach LaunchDarkly, so the export becomes a one-way task done in advance. Use an access token with the narrowest role that can read projects, environments, flags and segments, and store the JSON output in an approved transfer location. Record which projects and environments were exported, since the export is only as complete as the token's view. Each exported file should then be checked against the transfer rules your organization applies to data carried across the boundary, because this is the point where software and data cross into the isolated network.

Choose the import path based on what you need to carry over. Flagsmith's built-in LaunchDarkly importer reads projects and environments through the LaunchDarkly REST API using an access token, so it needs a live connection to LaunchDarkly and must run before isolation. It overwrites existing environments and flags in the target project, so import into a fresh project. The Unleash migration guide instead exports JSON and recreates flags through the Unleash Admin API or the import feature. Unleash's import feature also requires segments and custom strategies to exist in the target before import, so create those first. Whichever path you take, run both systems in parallel behind an abstraction layer such as the CNCF OpenFeature API, so application code can switch providers without a flag-by-flag rewrite at cutover.

After import, check the results by hand before any production flag is served from the isolated server. Confirm that boolean flags kept their on and off states, that multivariate values map to the intended variations, and that archived or deprecated flags were imported as archived. Compare targeting rules and percentage rollouts against the LaunchDarkly source, because a rollout that reassigns users to new buckets can change what customers see. Test each flag in a non-production environment inside the isolated network, and keep the exported files and a signed-off checklist as evidence of what was imported and when. Ask your vendor or integrator to confirm which of these items the chosen importer handles automatically.

How DeployOpen deploys flag servers under air-gap constraints

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source flag platforms inside the client's own infrastructure, including air-gapped networks. For an isolated flag server, the work starts with a written scope that defines which platform, which SDKs and which boundary the flags must serve across.

How we scope

Written scope fixes the platform choice between Unleash, Flagsmith and GrowthBook before any build work starts
We map which applications, SDK languages and environments must read flags from inside the isolated network
Scope lists the import path from LaunchDarkly, including whether flags, segments and environments move across the boundary

How we build

We deploy the flag server, PostgreSQL database and admin UI inside your data center or isolated cloud account
Container images and packages are verified and carried across the boundary through your approved transfer process
Integration, access control and backup configuration are built and tested against the scope before cutover

How we hand over

Deliverables include architecture notes, runbooks for upgrades and patch transfers, and the configuration record
Evidence for supply chain and access control reviews is prepared for your compliance team and independent auditors
Handover covers restore testing and the steps your staff follow to operate the server without internet access

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
Ongoing support, upgrades and continuous testing are available as a retainer
Confirm with your team and your vendor which release and edition each isolated deployment will run before scoping