Feature flags in air-gapped networks

Why feature flags in air-gapped networks need a different plan

Unleash and Flagsmith can both run on a self-hosted footprint with no outbound internet connection, so the platform itself is rarely the blocker. What decides whether the setup works is the image pipeline, the SDK evaluation model and the flag transfer process. A team that must ship flag changes from a production enclave needs to know how every container image, database migration and SDK package gets in, how flag state gets out or moves between environments, and whether each SDK can keep evaluating flags when the server is unreachable. Those three answers shape the architecture far more than the choice between the two products. Unleash runs from the unleashorg/unleash-server image against PostgreSQL 15 or later, listening on port 4242, and its import and export feature moves flag configurations as JSON between instances. Segments and custom strategies travel only as references, so they must already exist in the target before an import runs. Flagsmith ships Docker, Docker Compose and an official Helm chart, but its chart creates its own PostgreSQL server by default, which the documentation advises against in production. Both platforms have an open-source core, and both place governance features such as SSO, roles, change requests and audit logs in paid editions. Confirm early, in writing with each vendor, whether air-gapped support, your identity provider and the approval workflow you need are included in the edition you plan to run, because that decision changes the license cost and the controls you can evidence.

Which requirements an air-gapped flag platform must meet

This table maps each requirement to its source, what it asks of the flag platform build, and where the evidence usually comes from. Read it as a list of design questions to settle before choosing Unleash or Flagsmith, because each row changes hosting, access or update procedures. Auditors and assessors decide whether a system conforms, while DeployOpen prepares the configurations, procedures and evidence those reviews will sample.

Requirement	Source	What it means for the build
No outbound internet at runtime and during updates	Air-gapped deployment constraint set by the network owner	Pull server, database, Edge and SDK images into an internal registry, and move each update through a reviewed media transfer with a recorded checksum.
Remote access to OT-adjacent flag servers passes through an Intermediate System with MFA and session disable	NERC CIP-005-7 (Electronic Security Perimeter)	Admin access to the flag server and database is brokered through a hardened jump host, and vendor sessions must be detectable and terminable. Confirm with your assessor whether the flag platform sits inside the perimeter.
Software integrity and authenticity of vendor software and patches	NERC CIP-013-2 (Supply chain risk management)	Verify signatures or digests of each image, package and SDK before it crosses the boundary, and keep the procurement record that links each artifact to its vendor source.
Segmented control networks and OT security practices	NIST SP 800-82 Rev. 3 (OT security guide)	Place flag servers and their database in a zone with defined boundaries, and document which systems may query flag evaluations and which may only receive exported configuration files.
Controlled Unclassified Information scoping for defense contractors	32 CFR Part 170 (CMMC Program)	Identify whether flag configurations, targeting attributes or logs contain controlled information, since that decides which systems are in assessment scope.
Cloud-hosted service in scope for federal use	FedRAMP Scope (M-24-15)	If any part of the flag service runs as a cloud offering, confirm whether it falls under FedRAMP scope. A fully self-hosted deployment inside your own boundary avoids this question but must still be documented.

What data and systems the flag platform touches

The flag platform holds two different kinds of data, and an air-gapped design treats them differently. Configuration data is the set of flags, environments, projects, segments, strategies and their rules. It lives in the flag server's PostgreSQL database (PostgreSQL 15 or later for Unleash), and the server and admin UI listen on port 4242. Runtime evaluation data is what SDKs produce when they check a flag: the flag name, the context they send, and the result. Configuration changes rarely and flows from people who manage flags. Evaluation data is generated continuously by applications inside the isolated network. Map both to a named component and an owner before you choose where each one runs.

Targeting attributes need the most scrutiny. Any user ID, device ID, account tier or location value used in a rule identifies a person or a device, so it must stay inside the enclave and must never be copied to a SaaS dashboard, a vendor support bundle or a telemetry export. Edge or proxy layers, such as Unleash Edge or Flagsmith Edge Proxies, sit between SDKs and the API and cache configuration, so confirm which of them hold attribute data in memory or logs and how long those logs are kept. Also confirm whether each SDK evaluates locally or calls the server, because that decides where attributes travel at runtime. Audit trails for flag changes should be retained inside the boundary, and you should confirm which edition provides them, since Flagsmith places audit logs in its Scale-Up tier and Unleash places change requests in Enterprise.

Segments and custom strategies deserve their own check before any migration or import. Unleash's import and export moves flag configurations as JSON, but segments and custom strategies travel only as references, so they must already exist in the target instance with the same names. Build a sequence that creates them first, then imports flags, then verifies each flag's rules in the target. Document every object that must be pre-created, because a missing segment fails silently in a way that is hard to spot during a change window. Ask your implementation partner to produce this inventory as part of the scope.

Which platform fits an air-gapped flag deployment

Unleash runs its server from the unleashorg/unleash-server image against PostgreSQL 15 or later, with the server and admin UI listening on port 4242. The open-source Docker images remain under Apache 2.0. Starting with v8.0.0, the source code in the main repository and the unleash-server npm package moved to AGPLv3, which matters if you modify the source or offer Unleash as a service. The open-source edition is limited to 1 project and 2 environments with basic roles, so an air-gapped deployment serving several product lines usually needs the Enterprise edition for unlimited projects and environments.

Image mirroring: Confirm which image tags and digests Unleash publishes for each release, and how you mirror them into your internal registry without an outbound pull.
Update procedure: Ask how security fixes are delivered to offline sites, including whether patch images and release notes arrive as signed artifacts you can verify.
Governance features: SSO, SCIM provisioning, project and custom roles, user groups and change requests are Enterprise features. Confirm these in the current comparison before you size the deployment.
Import and export: Flag configurations move as JSON, but segments and custom strategies must already exist in the target instance. Plan the order of import in the isolated network.
Edge layer: The open-source version of Edge reaches end of life on December 31, 2026, so confirm the supported Edge option for local SDK evaluation before design.

Confirm with Unleash in writing whether the Enterprise edition's offline procedure covers images, Edge and license validation without a phone-home step.

Deployment patterns that keep runtime offline

An air-gapped flag service has to be built, updated, evaluated and restored without reaching the internet. The six patterns below cover the supply chain into the enclave, the runtime path that serves flags, and how configuration moves between environments.

Private registry mirror for images

Every container image the flag server, database and sidecars need is copied into a registry inside the enclave before deployment. Kubernetes shows the pattern: kubeadm can pull control plane images in advance and point at a private registry with --image-repository. Illustrative: a cluster build can list required images, pull them on a connected staging host, then push them across the boundary. Confirm with the vendor which images the flag platform needs and whether its own offline procedure matches this approach.

Local OS and database packages

Operating system packages, language runtimes and PostgreSQL packages come from a local repository mirror, not from public package indexes at install or patch time. Unleash's getting started guide targets PostgreSQL 15 or later, so the mirror must carry a version that meets that floor. Check whether the platform's Helm chart or Compose file pulls anything at startup from external hosts, such as plugins, geo data or telemetry endpoints, and remove those dependencies before the cluster goes offline.

Local SDK evaluation with cached configuration

Server-side SDKs can evaluate flags in the application process from a locally cached configuration, so a request does not depend on a live call to the flag server. The risk is staleness: define how long a cached configuration is trusted, what default value applies when no configuration is present, and how a kill switch reaches services that are cut off from the server. Test both a cold start with no cache and a server outage during peak traffic.

Edge or proxy layer inside the enclave

A proxy or edge layer placed inside the enclave serves cached flag configuration to many SDK clients, which reduces load on the central server and keeps evaluation close to the workloads. Unleash Edge and Flagsmith Edge Proxies both fill this role. Verify the open-source status of the proxy you choose: Unleash states that the open-source version of Edge reaches end of life on December 31, 2026, so a long-lived design needs an Enterprise plan or a different proxy plan.

Staged promotion by signed export and import

Flag configurations move from development to test to production as JSON files exported from one instance and imported into the next, carried across the boundary by approved media or a controlled transfer. Segments and custom strategies travel only as references, so they must exist in the target first. Sign each export with a hash or signature checked on import, and record who approved the file. Confirm whether the chosen edition supports change requests so promotion is approved inside the platform.

Offline backup and restore of the database

The database holds the flag definitions, environments, audit history and access settings, so it needs its own offline backup chain. Store backups inside the enclave on media that the security team controls, and test restore into an isolated copy on a schedule. Flagsmith's Helm chart creates an in-cluster PostgreSQL by default, but its documentation recommends an externally managed database in production, which is the cleaner target for backup tooling. Confirm the restore procedure with the vendor before go-live.

How the rollout moves from staging to the isolated network

The sequence moves a feature flag platform from an internet-connected staging zone into the isolated network in controlled stages, so each stage closes with a verified artifact before the next one begins. Each step names what it produces and who signs it off.

Confirm edition and scope decisions
Before any build work, the team decides between Unleash Open Source, Unleash Enterprise, the Flagsmith editions, or another option, based on the features the enclave actually needs. The decision covers project and environment limits, single sign-on and provisioning requirements, governance features such as change requests and audit logs, and whether air-gapped support is included in the chosen license. DeployOpen documents the edition decision with the client's security and compliance owners, and the output is a signed scope record listing the platform, edition, licence obligations and the list of integrations that must work offline. Confirm the licence terms with the vendor in writing before the staging build starts.
Build and mirror images in staging
In a connected staging zone, the team pulls the platform images, database and any sidecars such as an edge or caching layer, then pins exact versions and records their digests. Dependencies, operating system packages and SDK packages for each language used in the enclave are collected the same way. Everything is transferred to controlled media with a manifest of file names, versions and checksums. The output is a bill of materials and an image bundle that the security team has reviewed and accepted for import.
Harden the platform and connect identity inside the enclave
Inside the enclave, the platform is deployed against an internal database and private registry, with no outbound route to the internet. The team applies the client's hardening baseline, sets administrative roles, and connects the identity provider and any directory the edition supports, testing login, session timeout and access revocation. Backups and restore are tested at this stage. The output is a hardening record, an access matrix and a restore test result that the client accepts before any flag data is loaded.
Import the initial flag configuration
Flag definitions are exported from the source environment as JSON and imported into the enclave instance. Segments and custom strategies are exported only as references, so the team creates them in the target before importing the flags that depend on them. Imported states are compared against the source export, including archived flags, multivariate values and environment names. The output is a reconciliation report signed by the flag owners, listing any differences that were corrected by hand.
Integrate SDKs and test local evaluation
Application teams point their SDKs at the internal server or an internal edge layer, then test evaluation with the network path blocked from the internet to confirm nothing depends on an external call. Tests cover default values when the server is unreachable, cache refresh behaviour, and the flag states seen by a sample of services. The output is a test record for each application showing that flags evaluate correctly with no outbound access, plus the agreed default values for failure cases.
Cut over with a parallel run when migrating
If flags currently live in a SaaS tool, both systems run in parallel for a defined period, with applications reading from the enclave platform while the old system remains as a fallback. Discrepancies are logged and resolved before the old system is disabled. The team confirms the length of the parallel run with the client, since no duration is fixed here. The output is a cutover approval record, a list of retired integrations and a rollback procedure tested before the old system is switched off.
Run the recurring update cycle on controlled media
After go-live, each platform, SDK and dependency update follows the same path as the first build: it is pulled in staging, checked, carried across on controlled media with a checksum manifest, verified inside the enclave, and then promoted. Flag configuration changes made in the enclave remain inside it, and exports are made only when another environment needs them. The output is a change log for each cycle and an updated bill of materials, which also supports the software integrity and authenticity checks that supply chain controls expect.

How flag configurations move between environments without a network path

In an air-gapped network, a flag change made in a higher environment has to travel by a controlled medium, so the transfer itself becomes a change record. In Unleash, environment import and export moves feature flag configurations as JSON, either between environments in one instance or between separate instances. Segments and custom strategies are exported only as references, so the target must already contain identically named segments and custom strategies before the import runs, or the flags will not evaluate as expected. Build those objects in the target first, then import, and keep the exported JSON file, its checksum and the approver's name together as the transfer record. Confirm the exact import and export commands and their options against the Unleash documentation for your version before writing a transfer procedure.

Flagsmith handles transfers differently, and the difference matters for the procedure. Its built-in LaunchDarkly importer, for example, overwrites existing environments and flags in the target project, so an import into a project that already holds production configuration can silently replace it. Archived or deprecated flags arrive as archived, and boolean on and off states are kept while multivariate variations map to Flagsmith multivariate values. Treat every Flagsmith import as a manual review: take a backup of the target database before the run, compare flag states and values environment by environment against the approved source, and record who checked each one. Confirm with Flagsmith which import paths are available in your edition, since governance features such as change requests and audit logs start at the Scale-Up plan.

Whatever the platform, the target must be prepared before any configuration is moved, and each transfer needs an integrity and approval gate. Agree which environment is the source of truth, freeze changes in the target while the transfer is pending, and confirm that the server version in the isolated network matches the version that produced the export. Scan and verify each carried package and image under the software integrity expectations in NERC CIP-013-2 if your operator is in scope, and have a second person approve the file hash before it crosses the boundary. After import, run a smoke test of critical flags and keep a rollback copy of the previous configuration. A transfer procedure that cannot be rehearsed on a non-production instance is not ready for a regulated environment.

What auditors and assessors ask to see from the flag platform

This table maps each evidence item an assessor may sample to what it shows and the component that produces it. Read it as a starting inventory: the platform and edition you choose determine which artifacts exist natively and which must be assembled from transfer and patch records. DeployOpen prepares these artifacts, but assessors decide whether they are sufficient for your obligations.

Evidence item	What it shows	Which component produces it
Flag configuration exports with hashes	The state of flags in each environment at a point in time, and that an imported file matches the file that was approved	Platform JSON export (environment import and export), plus a hash recorded by your transfer process; segments and custom strategies must be confirmed as referenced in the target
Image bill of materials and signature records	Which container images, versions and digests run in the enclave, and that they match the vendor-published artifacts verified before crossing the boundary	Image mirror or internal registry, SBOM tooling and signature verification logs; confirm with the vendor which artifacts are signed
Change history and approvals	Who changed a flag, what changed, when, and who approved it before production	Platform audit log and change requests; confirm in your edition whether change requests and audit logs are included
Access review records	Which accounts hold admin, editor and read roles, and that stale or shared accounts were removed on review	Platform user and role listings, identity provider group exports (for example SSO or SCIM if licensed), and signed review records kept by your team
Transfer logs for removable media	What was carried across the isolated boundary, by whom, when, and which checks ran at each crossing	Media control log, scan results from the transfer station, and hash manifests recorded at export and import
Update and patch records tied to CIP-013-2 style verification	That each platform release and dependency was verified for integrity and authenticity before installation, and when it was applied	Release verification records, offline update packages, change tickets and deployment logs from the enclave, matched to the vendor's release notes
Backup and restore test results	That flag configuration and the database can be recovered inside the enclave and that the restore was tested	Database backup jobs, restore test reports and the platform version recorded with each backup
Edition and license records	Which edition runs in the enclave and which features it includes, so the evidence set matches the controls claimed	Vendor license documents and the deployed version; confirm feature entitlements such as SSO, audit logs and change requests with the vendor in writing

Questions buyers ask about air-gapped feature flags

What drives the cost of an air-gapped feature flag deployment?

The cost comes from four areas: the platform licence, the implementation work, the infrastructure, and the internal staff time needed to run it. Open-source Unleash and Flagsmith self-hosted editions carry no licence fee, but air-gapped work adds effort: building an offline image set, a private registry, a database, an identity connection and an import process for flag configurations. Implementation is largely one-time. Infrastructure, patching, offline media handling and support recur. Costs rise with the number of environments, the need for Enterprise features such as SAML single sign-on or change requests, and the number of SDKs and services that must be validated offline. Ask any quote to split one-time and recurring lines and to name the edition it assumes.

Can our internal team deploy air-gapped feature flags without a partner?

Yes, a capable platform team can do it, but it needs skills across Kubernetes or container hosting, PostgreSQL, identity, secure media transfer and SDK behavior. The main gaps are usually offline image mirroring, validating every package before it crosses the boundary, and writing a repeatable process for flag export and import between environments. Flagsmith documents a Helm chart that creates its own PostgreSQL server by default, while its docs recommend an externally managed database in production, so the team must make that decision deliberately. A partner can take on a fixed scope with written deliverables. Your team should confirm it has capacity to run upgrades after go-live, which is where in-house efforts often stall.

How long does an air-gapped feature flag rollout take?

The timeline depends on the scope you define and on how your network approvals work. The main drivers are the number of environments, whether you need a staging enclave to assemble and test offline media, how long your security team takes to review each transfer, and whether migration from an existing tool such as LaunchDarkly is included. Unleash publishes a migration path that recommends running both systems in parallel behind an abstraction layer before cutover, which adds time. No standard duration applies to every organization. Ask for a timeline tied to written milestones, and confirm which approval steps sit on your side of the schedule.

What does the client team need to provide for an air-gapped engagement?

Plan for access and decisions from several groups before work starts:

A staging network with outbound internet access, used only to assemble and verify image bundles before they cross the boundary.
Identity owners who can approve how users and roles connect to the platform, including whether SAML or SCIM is needed.
Named approvers for flag change policy, production access and each media transfer.
A media handling process, with logs, checksums and a rule for who may carry removable media across the boundary.
Database, storage and certificate administrators inside the isolated network.

NERC CIP-013-2 names verification of software integrity and authenticity for vendor software and patches, which is the control your transfer process should evidence. Confirm these owners early, since they often set the pace.

Do we need an Enterprise edition for air-gapped feature flags?

Not necessarily for the core flag service, but the edition determines which governance features you get. Unleash Open Source is free and self-hosted with 1 project, 2 environments and 5,000 feature flags per instance, according to its pricing page. Unleash Enterprise adds unlimited projects and environments, single sign-on, SCIM provisioning, project and custom roles, user groups and change requests. Flagsmith's FAQ states that its core is BSD 3-Clause, while role-based access control, SAML single sign-on and certain database integrations are closed source and require a license. On Flagsmith's pricing page, governance features start at the Scale-Up plan, which is listed at $250 per month billed yearly. Confirm the exact edition terms with the vendor before you commit, because limits change.

How do we handle updates without internet access?

Updates are assembled outside the boundary, verified, and carried in as a controlled release bundle. The bundle should contain the server image, the admin UI, the database migration path, SDK versions your applications use, and release notes. Pull images from the vendor's published source, record digests, scan and test them in a staging enclave that mirrors production, then transfer them with checksums and an approval record. Confirm the vendor's supported upgrade path for your version and edition. Unleash Edge's open-source version reaches end of life on December 31, 2026, so any Edge deployment needs a plan before then. Build time for this process into the operating model.

How do we move flag configurations between environments without a network connection?

Export flag configurations as JSON from the source environment, transfer the files through your approved media process, and import them into the target. Unleash's import and export moves configurations between environments or instances, but segments and custom strategies are exported only as references, so they must already exist in the target before import. Flagsmith's importer overwrites existing environments and flags in the target project, so run it only in a controlled window and check results by hand afterwards. Keep each export, its checksum and the approval that authorized it, since auditors often test this trail.

What to ask an implementation partner before signing

Start with the offline image pipeline, because it decides who can patch the platform later. Ask who builds the offline bundle of container images, Helm charts and database migrations, where it is signed, and who holds the signing keys. Ask how the partner verifies each artifact before it crosses the boundary, and which step records that verification. If the platform is Flagsmith on Kubernetes, confirm whether the external PostgreSQL and any optional PgBouncer or Redis components are included in the bundle. If the platform is Unleash, confirm the image references used by the Unleash Edge layer. Ask for the bundle manifest in writing so the team can check it without the partner present.

Next, ask how updates and CVE handling work when no connection to the internet exists. Ask who monitors upstream advisories for Unleash, Flagsmith, PostgreSQL and the base operating system, how a finding becomes a transfer request, and how long an accepted patch takes to reach the enclave under the partner's process. Ask whether the partner will deliver a written evidence pack with each release, what format it takes (for example, a software bill of materials and scan output), and whether that evidence supports the supply chain expectations in NERC CIP-013-2. Confirm the edition and license terms in the same conversation. Unleash v8.0.0 moved the main repository to AGPLv3, while its official Docker images remain under Apache 2.0, and the Unleash blog says that modifying Unleash to offer it as a public or commercial service requires publishing the source or buying a commercial license. Ask the partner to confirm in writing whether any customization they build triggers those obligations. Also confirm that Unleash Edge OSS reaches end of life on December 31, 2026, and ask which Enterprise plan or replacement design they recommend for the enclave.

Finally, ask how support continues after go-live, and how the fixed scope and exit conditions are written. A fixed-scope agreement should name the platform version, the delivered artifacts, the acceptance tests run inside the network, and the handover of runbooks and keys. Ask what a retainer covers for offline upgrades, who performs them, and how long the partner commits to respond to security findings. Ask for exit conditions in writing, including export of flag configurations as JSON, the rule that segments and custom strategies must exist in the target before import, and the handover of the offline bundle process to the client team. Ask who owns the data and configuration if the engagement ends.

How DeployOpen scopes and builds an isolated flag platform

An isolated flag platform succeeds or fails on decisions made before any installation starts. The cards below follow the order DeployOpen works in: a written scope, planning inside the client's network, an offline build, testing, evidence and ongoing support. Each step is agreed in writing so the security team can check what is delivered against what was promised.

Fixed scope in writing

Most engagements are fixed-scope, so the platform choice, edition, hosting target, integrations and deliverables are agreed in writing before work starts. For an air-gapped flag platform, the scope should name the edition, because features such as SSO, SCIM, change requests and audit logs can sit in paid tiers. Ask the partner to list which edition features are included and which are excluded, and who maintains the offline update path after go-live.

Planning inside your network

Architecture planning happens inside your own cloud accounts, data centers or isolated networks, so the design reflects the real boundary and not a diagram. Planning covers where the server and PostgreSQL database run, how SDK clients reach the server, and which proxy or caching layer sits between them. Confirm early whether your environment permits any outbound path, even for logs or time synchronization.

Offline build and hardening

The build assembles every container image, package and configuration on the inside of the boundary, using images transferred through approved media. Hardening covers access to the admin interface, database credentials, network segmentation and the configuration of the server itself. Ask for a bill of materials listing each image and version, and a documented method for verifying the integrity of every item that crosses the boundary.

Security testing after deployment

Security testing targets the platform as deployed in the isolated environment, not a generic copy. It covers the application, the APIs that SDKs call, the administrative access paths and the infrastructure underneath. Findings are reported with reproduction steps and agreed remediation work. Confirm the test scope, the testing windows and how test data is handled before testing begins, since flag rules often reference sensitive targeting attributes.

Evidence for assessments

DeployOpen prepares systems, controls and evidence for compliance assessments, such as configuration records, change logs, access reviews and export and import records for flag configurations. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so ask your assessor early which evidence formats they accept and where the records must be stored.

Retainers for updates and testing

Ongoing support, upgrades and continuous testing are available as retainers. In an isolated network, a retainer usually covers preparing offline update bundles, validating them in a staging environment and repeating security testing after changes. Agree in advance who approves each update, how long a patched release may stay outside the boundary, and what happens to flag configurations during an upgrade.