Why a LaunchDarkly alternative for FedRAMP environments starts with the authorization boundary
The choice for an agency or contractor comes down to two models: LaunchDarkly's FedRAMP federal instance, which runs as a cloud service, or a flag server that the organization runs inside its own authorization boundary. Before comparing features, decide which of those models fits where feature flag data and evaluations must live under federal rules. FedRAMP's scope turns on a specific question: does the cloud service create, collect, process, store or maintain federal information on behalf of an agency? According to the FedRAMP scope guidance under OMB M-24-15, systems used only for a single agency's operations on cloud infrastructure, and not offered as a shared service, fall outside that scope. A flag server that stays wholly inside the agency's own boundary is therefore a different authorization question from a shared SaaS flag platform.
The answer also changes control inheritance. When a vendor's FedRAMP authorization covers the flag service, the vendor carries the controls it implements, and the customer answers for its own configuration, identity, access and data handling. When the flag server runs in the customer's boundary, the organization owns the controls for the host, database, network paths, logging and patching, and the assessment is written against that system. NIST SP 800-53 Rev. 5 supplies the control catalog for both models, and SP 800-53B defines the low, moderate and high baselines that set how many controls apply. Confirm with the authorizing official which baseline the system is categorized at and which controls LaunchDarkly's package inherits, because the mapping is specific to each agreement.
DeployOpen plans, implements and documents self-hosted platforms inside the client's own cloud accounts, data centers or air-gapped networks, and it prepares evidence for compliance assessments. It does not issue authorizations, attestations or certifications. An independent assessor and the authorizing official decide whether either model is acceptable. Before choosing, ask LaunchDarkly for its current FedRAMP package and the list of services it covers, and map each service to the systems that will call it. Then document the data flow for flag keys, user contexts and evaluation events, since those fields can carry federal information even when the flags themselves do not.
Which federal requirements shape a feature flag decision
A flag server touches federal data only when it evaluates flags for users or stores targeting context about them, so the requirements below decide whether the flag service sits inside an authorization boundary. Each card names a requirement family, who it binds, and what to confirm before choosing between LaunchDarkly's FedRAMP instance and a self-hosted flag server.
NIST SP 800-53 Rev. 5 baselines
NIST SP 800-53 Rev. 5 is the federal control catalog, and SP 800-53B selects the low, moderate and high baselines of 149, 287 and 370 controls and enhancements. Most agency and contractor systems are assigned a baseline by their system categorization, and that baseline sets the controls your flag server must meet. Ask which baseline your authorizing official assigned and whether the flag service is in scope as a component or as an external service.
FISMA and agency oversight
NIST lists FISMA and OMB Circular A-130 among the laws behind SP 800-53, and under FISMA Inspectors General independently assess agency system security and report to OMB. This means a flag server used by an agency needs documented control evidence that an Inspector General can test, not only a vendor assurance letter. Confirm which party owns each control, including access control, audit logging and configuration management for the flag service.
FedRAMP scope under M-24-15
FedRAMP covers cloud products that create, collect, process, store or maintain federal information for an agency, and OMB memo M-24-15 of July 25, 2024 sets that scope. A system used only for one agency's operations on cloud infrastructure and not offered as a shared service may fall outside FedRAMP, which changes who must hold an authorization. Confirm with your agency's authorizing official whether a self-hosted flag server is an agency system or a cloud service that needs its own authorization.
CJIS encryption and scanning rules
Applies only to criminal justice workloads. CJIS Security Policy version 6.1 requires FIPS 140-3 validated modules or FIPS 197 AES with at least 256-bit keys for criminal justice information in transit and at rest outside physically secure locations, and vulnerability scanning at least monthly. If a flag context can carry CJI fields, such as case or offender identifiers, confirm that the flag server and its database meet these settings and that scans cover the flag stack.
CUI safeguards under NIST SP 800-171
Applies to contractors and agencies handling controlled unclassified information. Under 32 CFR 2002.14(h)(2), agencies use NIST SP 800-171 when setting requirements for CUI on non-federal systems, unless the CUI category's own authority prescribes other safeguards. A flag server that evaluates targeting rules on CUI-tagged attributes must sit inside that boundary, so confirm with the contracting officer which safeguards apply to your system before you send any CUI-derived context to a SaaS flag service.
CMMC Level 2 cloud rule
Applies to defense contractors pursuing CMMC Level 2. Under 32 CFR 170.17(c)(5), a contractor may store or process CUI in a cloud service only if that service is FedRAMP Authorized at the Moderate baseline or higher, or meets equivalent requirements. Non-cloud providers are assessed within the contractor's own scope. A self-hosted flag server inside your own assessed boundary avoids this cloud service condition, but the flag server then counts toward your scope and must be assessed with it.
How LaunchDarkly's federal instance compares with self-hosted options
LaunchDarkly's federal instance runs on .us endpoints and is the option where the vendor operates the platform inside an authorized environment. The agency or contractor inherits many infrastructure controls through the provider's authorization package, while still owning identity configuration, user access, the data it sends and the controls on its side of each connection. The trade-off is in the integration list and the data exit path, both of which need checking against your architecture.
- What it meets: A FedRAMP-authorized SaaS path that procurement and security offices can review through existing vendor documentation.
- What it does not: A smaller integration list than the commercial instance, so some SDKs, tools or pipelines may not connect.
- Data exit: Data Export is available only through Kinesis, so any downstream analytics or warehouse pipeline must accept that destination.
- Confirm with the vendor: The FedRAMP authorization level and current package, the date it was granted, which features sit outside the federal instance, and whether the Relay Proxy and your SDK languages are supported.
Request the current authorization package and the customer responsibility matrix before any production data or flag traffic moves.
Self-hosted Unleash runs the server, admin UI and SDK endpoints inside infrastructure you operate, backed by PostgreSQL 15 or later and listening on port 4242. Authorization responsibility moves to your team: you own the hosting controls, the access model and the evidence package. DeployOpen can plan, configure and document that environment and prepare evidence for assessment, but it does not issue authorizations or certifications.
- Licensing: From v8.0.0, the server source is AGPLv3. Unleash states that running the official Apache 2.0 Docker images without modification does not trigger the AGPLv3 change, but offering a modified build as a service does. Read the Unleash AGPLv3 announcement
- Open Source limits: 1 project and 2 environments with basic roles. A multi-program agency will need Enterprise for more projects, single sign-on, SCIM provisioning and custom roles.
- Edge dependency: Open-source Unleash Edge reaches end of life on December 31, 2026, so a high-scale design needs an upgrade or replacement plan.
- Confirm with the vendor: Whether Enterprise SSO and SCIM meet your identity requirements, and what the Enterprise license terms say about your deployment.
Have counsel confirm the AGPLv3 position for any modified build before you adopt one, and match the Open Source limits to the number of projects you need.
Flagsmith's code is mostly BSD 3-Clause, and its self-hosted open-source version has no API request limits. The governance features that assessors often examine sit in the Enterprise edition: role-based access control and SAML single sign-on are closed source and require a license. Its Helm chart suits regulated Kubernetes clusters, but the default database and the OpenShift Operator support both have boundaries your platform team must handle.
- Licensing: Most of the code is BSD 3-Clause, with Enterprise features such as RBAC, SAML and certain database integrations closed source.
- Database default: The Helm chart creates its own PostgreSQL in the cluster. The docs recommend an externally managed database in production, which should sit under your existing database controls.
- OpenShift: Helm charts run on OpenShift, but support for the OpenShift Operator requires an Enterprise plan.
- Access control gap: Without Enterprise RBAC and SAML, access control and sign-in must be built with other tools, and the assessor will examine that design.
Confirm with Flagsmith which Enterprise features are licensed for your self-hosted deployment and who provides support for your Kubernetes platform before you commit to the architecture.
GrowthBook suits agencies and contractors who run experiments against data they already govern. It is MIT licensed outside its enterprise directories and runs read-only SELECT queries against sources such as Snowflake and BigQuery, so experiment results stay in the warehouse your boundary already covers. Its free self-hosted plan is limited in scope, and some experimentation features sit in paid tiers. Because GrowthBook is a self-hosted application in your boundary, an assessor may place it inside your own scope.
- Data location: Queries run against your warehouse, so event data does not need a separate export path. Review GrowthBook's data source documentation
- Licensing: MIT outside the enterprise directories, which the project's license file sets out.
- Free plan limit: 1 project with unlimited users, which fits a single program but not a multi-program estate.
- Feature gaps: Bandits, holdouts and sticky bucketing are paid features, so confirm they are not needed for your study design.
- Confirm with the vendor: Which Enterprise features you need, and the scope of the read-only warehouse credentials.
Confirm that the warehouse sits inside your authorization boundary and agree the credential scope with your assessor before connecting any data source.
Who owns which controls in each model
This table compares control families in a FedRAMP-authorized SaaS federal instance with a flag server your agency or contractor runs inside its own boundary. Each row shows whether the provider, the customer or both are expected to carry the control, so you can see where your System Security Plan work sits. Treat every allocation as a starting point and confirm it against the vendor's control documentation and your own SSP before you rely on it.
| Control family | FedRAMP SaaS federal instance | Self-hosted flag server in your boundary |
|---|---|---|
| Boundary definition (CA, SC) | Provider defines the authorized service boundary; customer defines how its tenants and endpoints connect to it | Customer defines the full boundary, including database, container platform, load balancer and SDK network paths |
| Access control (AC) | Shared: provider secures the platform, customer configures roles, users and API tokens | Customer implements all account, role and token controls, plus any SSO integration |
| Audit logging (AU) | Shared: provider logs platform events, customer must retain and review its own admin activity records | Customer implements log generation, storage, retention and review for the application and database |
| Encryption in transit and at rest (SC-8, SC-28) | Provider inherits platform encryption; customer confirms endpoint TLS and key handling for its SDKs | Customer selects FIPS-validated modules and key lengths, and manages database and certificate keys |
| Vulnerability scanning (RA-5) | Provider scans its platform; customer scans its own SDK integrations and configuration | Customer scans the server, container images, OS and database on the cadence its baseline requires |
| Configuration and patching (CM, SI) | Provider patches the managed service; customer manages flag definitions and change approvals | Customer owns image builds, patching, upgrades and configuration baselines |
| Contingency and backup (CP) | Provider handles platform resilience; customer confirms export and recovery procedures for its flag data | Customer implements backup, restore testing and recovery of flag definitions and the database |
How to deploy a flag server inside your authorization boundary
This sequence moves flag delivery and flag management inside your own authorization boundary, so evaluation traffic and flag data stay in systems you control. It ends with LaunchDarkly retired as the source of truth, with the self-hosted server validated against your baseline.
Define the boundary and data classes
The compliance lead and the system owner list every system that will hold or serve flags, and the data classes those flags touch, such as user attributes, targeting keys and any controlled information that appears in rule names or segments. They confirm with the authorizing official which control baseline applies to the system, and whether any flag data falls under CJIS, CUI or other regimes. Done when the boundary diagram and data classification are signed off and name every inherited control from the cloud provider.
Select the platform and licensing model
The architect compares Unleash, Flagsmith and GrowthBook against the required features, the project and environment limits of the free editions, and the license terms that apply to internal use. Enterprise-only items such as SSO, SAML, SCIM and granular roles should be listed explicitly, because they determine whether a paid plan is needed. Done when a written decision records the platform, edition, license review outcome and the procurement path for any paid features.
Deploy PostgreSQL outside the Helm default
The platform engineer provisions a managed or hardened PostgreSQL instance inside the boundary, with backups, encryption and access logging that match the boundary's requirements. The Flagsmith Helm chart creates its own database in the cluster by default, but its documentation recommends an externally managed database in production, so the chart should point at this instance. Done when the application connects over the approved network path, backups restore in a test, and the database is absent from any public network route.
Configure SSO, roles and audit logging
The identity team connects the flag server to the agency or contractor identity provider and maps groups to roles. Flagsmith's SAML single sign-on and governance features such as roles, change requests and audit logs are Enterprise features, and Unleash's SSO, SCIM and custom roles sit in its Enterprise plan, so confirm those licenses before relying on them for access control. Done when test users from each role can sign in, unauthorized changes are rejected, and audit records reach the central log store.
Stand up in-network delivery with Edge or Edge Proxy
The platform engineer places the caching layer inside the boundary so that SDKs fetch flags without calling the management plane directly. For Unleash, Edge is the component to deploy, but the open-source version of Edge reaches end of life on December 31, 2026, so the design should either use a supported plan or plan a move before that date. For Flagsmith, the optional Edge Proxy plays this role. Done when internal application traffic reaches the caching layer, and a test confirms the flag server still resolves flags when the upstream is unreachable from the application network.
Import flags from LaunchDarkly
The migration lead exports flag and segment definitions from LaunchDarkly through its REST API with a scoped access token, then loads them with the importer or the target's API. Flagsmith's built-in importer reads projects and environments directly, but it overwrites existing data, so it should run into a fresh project. Unleash's guide maps targeting rules to activation strategies and recommends recreating segments and context fields first. Done when counts of projects, environments, flags and segments match the export, and each flag's boolean and variant state has been checked by hand.
Run both systems in parallel
The engineering team places both systems behind an abstraction layer, such as the OpenFeature API with a provider for each vendor, and mirrors reads and changes for a defined set of low-risk flags. Partial rollouts need careful handling, because a changed bucketing rule can move users between variants. Done when evaluation results from both systems agree for the sampled traffic and any differences have a recorded cause and fix.
Cut over and retire the SaaS connection
The change owner switches production SDK traffic to the self-hosted flag server, records the cutover in the change system, and keeps the rollback path open until the parallel period has ended. Once the team is satisfied, they revoke LaunchDarkly tokens, remove SaaS endpoints from egress rules, and confirm that no flag data is still being sent outside the boundary. Done when the assessor receives evidence that the SaaS connection is closed and the self-hosted server is the sole source of truth.
What assessors and inspectors ask for
Whichever model you choose, an assessor will test the same question: who controls each safeguard, and can you show it. The cards below list the records to assemble for a self-hosted flag server inside your boundary, and they note where the evidence comes from in the FedRAMP instance. Auditors and inspectors decide what is sufficient; DeployOpen prepares the evidence, but it does not issue audit reports or authorizations.
Boundary and data flow diagrams
Assessors start with a diagram that shows where the flag server, its PostgreSQL database, the SDK endpoints and any edge caches sit, and which network paths SDKs use to reach them. For a self-hosted model, the diagram must also show the identity provider, log destinations and backup targets, because each one may hold flag data or user context. For the LaunchDarkly federal instance, ask the vendor for its own boundary documentation and the endpoints your SDKs will call, including the .us hosts. Check that the diagram matches what the servers actually reach.
Control inheritance statements
Every control in your baseline is either implemented by you, inherited from a provider, or shared between you and the provider. In the FedRAMP model, the provider's authorization package defines what it covers, and your agency or contractor must still document the controls that fall to your configuration and user management. In the self-hosted model, the cloud or data center provider's controls and your own controls are mapped separately, with no gaps between them. Write one statement per control and name the owner.
Configuration baselines and encryption settings
Record the hardened configuration of the flag server, including TLS versions, the database connection encryption and how keys are stored and rotated. CJIS Security Policy v6.1 requires FIPS 140-3 certified modules or FIPS 197 AES with at least 256-bit keys for criminal justice information in transit and at rest outside physically secure locations, so confirm the cryptographic module and key length for each component that handles that data. Keep baseline files under version control so the approved state is provable on any date.
Access reviews and role records
Assessors test who can change production flags, who can create API tokens and who can view user context. The open-source tiers limit project and environment counts and offer basic roles, so access controls may depend on paid editions or on your identity provider. Document each role, its members and the review cadence, and export the access list at each review. Confirm which single sign-on and provisioning features your chosen edition includes before you promise a control to an assessor.
Vulnerability scan records
Under CJIS Security Policy v6.1, vulnerability scanning of systems that handle CJI must run at least monthly, which maps to the RA-5 control. Keep dated scan reports, the findings list, the remediation tickets and the exceptions with approvals. Cover the flag server image, the database host and the operating system, and retain the results for the period your assessor specifies.
Backup, migration and change logs
Assessors look for evidence that flag state can be restored and that changes are traceable. Keep backup job records, restore test results and the dates of each test. For migrations, record the exported flag definitions, the import steps, the parallel-run period and the cutover approval. Change logs should show who changed each flag in production, when and under which ticket, and they should be retained alongside the audit logs your chosen edition provides.
Questions agencies and contractors ask before choosing
Does a self-hosted flag server remove the need for FedRAMP authorization?
It depends on scope, not on where the server runs. FedRAMP's scope covers cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency. The OMB memo M-24-15 and the FedRAMP scope guidance also exclude systems used only for a single agency's operations on cloud infrastructure that are not offered as a shared service. A flag server that DeployOpen implements inside your own accounts and authorization boundary is therefore a question for your authorizing official and your compliance lead, who should confirm how the system is classified. If the flag service stores or evaluates user or context data about federal users, the controls under NIST SP 800-53 Rev. 5 still apply to your system, whichever model you choose.
What drives the cost of a self-hosted flag server for government use?
Cost falls into four components: software licensing, infrastructure, staff time and implementation. Open-source Unleash Open Source is free to run but limited to 1 project and 2 environments, while the Unleash pricing page lists Pay-As-You-Go at $75 per seat per month with a 5-seat minimum for self-hosted, and Custom Enterprise on annual contracts. Flagsmith keeps governance features such as SAML single sign-on, roles and audit logs on its Scale-Up plan and above. Infrastructure, your database, backups and monitoring inside your boundary, is paid to your own cloud or data center provider. Staff and implementation are one-time for setup and recurring for upgrades and patching. Ask any quote to separate licenses, infrastructure, fixed-scope implementation and ongoing support.
How long does a migration from LaunchDarkly take?
No duration in the supplied material is firm enough to quote, so confirm it in the written scope before work starts. The main variables are the number of projects, environments, flags and segments, whether you must run LaunchDarkly and the new server in parallel, how many SDK integrations change, and the accreditation and change-control steps inside your authorization boundary. Unleash's migration guide recommends exporting definitions through the LaunchDarkly REST API, recreating them, and running both systems behind an abstraction layer before cutover. DeployOpen's fixed-scope engagements agree deliverables and timelines in writing before work starts, so ask for the schedule to be tied to each of those steps.
What does the work need from our own team?
Your team owns the decisions that no implementation partner can make for you. Expect to provide the authorization boundary and the system security plan owner, the cloud or data center account, network and identity integration, approval for the change record, and people who know which flags gate which features. Engineering staff must replace LaunchDarkly SDK calls or wrap them with OpenFeature. Someone with authority must sign off on the flag and segment inventory before cutover. Ask the partner to list these dependencies in the written scope so the responsibilities are clear from the start.
Can our team run the migration ourselves without a partner?
Yes, a capable internal team can run it, and the open-source projects publish their own documentation. Unleash documents a scripted route, Flagsmith includes a built-in LaunchDarkly importer, and GrowthBook has a two-step importer. The question is whether your team has the capacity to test targeting parity, handle identity and access controls, document evidence for assessors, and maintain the platform after go-live. Flagsmith's importer overwrites existing environments and flags in the target, so import into a fresh project and check results by hand. If your team is short on time or compliance evidence experience, a fixed-scope engagement can cover those parts while your staff keep ownership.
What does the AGPLv3 change mean for internal government use?
Starting with Unleash v8.0.0, the server source code moved from Apache 2.0 to AGPLv3, while the official open-source Docker images remain Apache 2.0. Unleash states that teams running the official images without modifying the source are not affected. Modifications offered as a public or commercial service must have their source published or be covered by a commercial license. Internal use by an agency or contractor that does not modify the server and does not offer it to outside users is the case Unleash describes as unaffected, but legal counsel should confirm how your contract and the license apply, especially if you change the code. Flagsmith's core is BSD 3-Clause with closed-source Enterprise features, which is a different licensing question to review.
Which controls does the agency or contractor own in each model?
In a FedRAMP-authorized vendor model, the vendor's authorization covers the cloud service, and you still own customer responsibilities such as access, configuration and data handling. In a self-hosted model inside your own boundary, you own the whole stack: operating system, database, network, identity, logging, backup and the flag server itself, mapped to NIST SP 800-53 controls in your system security plan. Defense contractors should note that under 32 CFR 170.17(c)(5), CUI in a cloud service requires FedRAMP Moderate or equivalent, and CJIS work has its own FIPS 140-3 and vulnerability scanning requirements. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors and authorizing officials issue the decisions and attestations.
What is a flag server's security exposure that assessors will ask about?
Assessors will focus on who can change flags in production, how those changes are logged, how the server is patched, and where flag evaluation data is stored. Unleash Open Source has basic roles only, while Enterprise adds single sign-on, SCIM provisioning and change requests, so check whether the access model you need is in the free tier. Flagsmith's role-based access control and SAML are Enterprise features. Plan for encryption in transit and at rest meeting the cryptographic requirements of the frameworks you follow, and for scheduled vulnerability scanning. DeployOpen can run security testing against the deployed service as part of readiness work.
What changes for your team after the decision
The first change is ownership. With LaunchDarkly's FedRAMP instance, the provider runs and patches the flag service, and your team inherits the controls that concern how you configure, access and monitor it. Once you run Unleash, Flagsmith or GrowthBook inside your own authorization boundary, your team patches the operating system, the database, the container images and the flag server itself, and it runs vulnerability scanning on all of them. The FBI CJIS Security Policy v6.1 requires vulnerability scanning at least monthly where CJI is involved, so confirm the scan owner, the scanner and the remediation window before cutover, not after. Also decide who holds the encryption keys for the PostgreSQL database and backups, and who can rotate the SDK keys and access tokens. Those keys become your responsibility, and so does proving that FIPS 140-3 validated modules are in use where your scope requires them.
Incident response moves with the platform. A flag outage that once went to the vendor's status process now goes to your on-call rotation, and your incident runbook needs steps for a stalled flag server, a bad targeting change and a compromised SDK key. Keep the SDK change separate from the flag change: OpenFeature lets applications call one evaluation API while a provider talks to the flag system underneath, so you can switch the provider in configuration instead of editing every service. Treat targeting rules and segments as a second migration track. Unleash maps LaunchDarkly targeting rules to activation strategies and segments to segments, and it requires segments to exist in the target before an import. Run both systems in parallel during cutover, and verify that users in partial rollouts keep the same variation, because a change in bucketing can flip features for live users. Confirm each decision in writing with the assessor and your implementation partner before the old flags are retired.
How DeployOpen deploys flag servers under federal constraints
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For a flag server in a federal or contractor boundary, that means agreeing the control ownership and the authorization path in writing before any build work starts.
How we scope
- Confirm which system boundary the flag server sits in and who holds the authorization decision for it.
- Map each flag server component and data flow to the control owner: the agency, the contractor or the hosting provider.
- Agree deliverables, timelines and exclusions in writing before work starts, since most engagements are fixed-scope.
- Identify which data is in scope, such as user context attributes, to decide whether CUI or CJI handling rules apply.
How we build
- Deploy the chosen platform, such as Unleash, Flagsmith or GrowthBook, in your own environment with a managed PostgreSQL database.
- Configure SSO, role separation, TLS, encryption keys and logging to the requirements agreed in the scope.
- Test application and API security, including access control on flag management endpoints, before cutover.
- Run any LaunchDarkly export and import steps in a staging environment and check results by hand against the source.
How we hand over
- Deliver system documentation, architecture diagrams and a control responsibility matrix that names who owns each control.
- Prepare compliance evidence and runbooks for your assessor, while noting that independent auditors issue any attestations.
- Document backup, restore, upgrade and open-source version tracking so your team can operate the platform after handover.
- Walk your administrators through day-to-day operations, change control and the incident steps for the flag servers.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers that follow the agreed scope.
- Plan upgrades against the open-source release and license changes that affect your design, confirmed before each change.
- Schedule periodic security testing of the flag server and its integrations as part of a retainer if your assessment cycle requires it.
- Keep the control matrix current when the platform, hosting or authorization boundary changes.
