LaunchDarkly vs Flagsmith: which to choose

When LaunchDarkly or Flagsmith is the better fit for your flag platform

Flagsmith fits when you want flags and remote config on your own PostgreSQL and can accept a paid Enterprise tier for the governance controls you need. LaunchDarkly stays the better fit when your teams already depend on its hosted integrations and want the vendor to run the service. The decision usually starts with a renewal, a change in how LaunchDarkly bills you, or a rule that application data must stay in your own environment. Start by listing which of these actually drives the move, because each one points to a different answer.

Work through four questions. First, do you need SAML single sign-on, role-based access control, change requests or audit logs? Per Flagsmith's pricing page, these governance features start at the Scale-Up plan, and SAML and Okta integrations are Enterprise features in the open-source edition's licensing model, so confirm which edition covers each control with Flagsmith before you budget. Second, must flag state and evaluation data stay in your PostgreSQL? Flagsmith's Helm chart creates its own database by default, so plan for an externally managed PostgreSQL in production. Third, who will operate the platform, including upgrades and on-call? Fourth, does your current bill scale with service connections or with requests? Flagsmith's Free and paid plans meter API calls, so high-traffic SDK polling can change your cost profile.

Before you commit, run a short proof of concept. Import one LaunchDarkly project into a fresh Flagsmith project, since the importer overwrites existing data, and compare the imported boolean and multivariate flags with the source. Check the governance controls your auditors will ask about, and confirm with Flagsmith in writing which features are covered by the open-source license and which need an Enterprise license. Ask your platform team to estimate the operating effort for a PostgreSQL-backed deployment on your own cluster. If your own review finds the governance gap manageable and your operations team is ready to own the stack, Flagsmith is a sound choice. If not, a hosted option may still be the simpler path.

Which option fits which buyer situation

This table matches common buyer situations to the option that fits best and the condition that would change the answer. Read each row as a starting point, then check the condition against your own environment, identity requirements and budget before deciding.

Buyer situation	Better fit	Why and when the answer changes
Flags plus remote config on a self-managed PostgreSQL	Flagsmith	Flagsmith's self-hosting docs describe an external database for production and its Helm chart can point at it. The answer changes if you need Enterprise governance features, which are closed source and licensed.
Team that needs SSO and approvals on day one	LaunchDarkly or a paid Flagsmith tier	Flagsmith lists SAML single sign-on and governance features such as roles, change requests and audit logs at the Scale-Up plan and above. Confirm current tier contents on the pricing page before committing.
Platform team with no appetite for running a service	A managed Flagsmith plan or a hosted vendor	Self-hosting adds upgrades, database backups and cache operations to someone's queue. The answer changes if DeployOpen or an internal team will operate the stack under a written scope.
Regulated team needing flag data in its own database	Flagsmith, self-hosted	Flagsmith runs in your cluster against your PostgreSQL, so flag and environment data stays under your controls. Confirm with your assessor which database controls apply to the flag store.
OpenShift shop	Flagsmith via Helm, with a plan check	Flagsmith runs on OpenShift through its Helm charts, but the OpenShift Operator is Enterprise only. The answer changes if your platform team requires an Operator-managed lifecycle, which makes Enterprise the right tier to price.
Team migrating from LaunchDarkly with active targeting rules	Flagsmith importer, then manual review	The built-in importer copies projects, environments and flags, but it overwrites existing data and needs hand checks afterwards. Import into a fresh project to avoid losing work in an existing one.
Team expecting unlimited API calls on a self-hosted install	Flagsmith open-source edition	Flagsmith's FAQ states the self-hosted open-source version has no API request limits. Request-based billing applies only to its hosted plans, so the answer changes if you move to the hosted service.
Illustrative: a 20-person team with no SSO requirement and one primary PostgreSQL	Flagsmith, self-hosted open-source edition	Without SAML or governance needs, the open-source edition covers the core flag workflow. Confirm that no audit log or approval requirement appears in your control set.

Where flag data lives on a self-hosted Flagsmith

On a self-hosted Flagsmith, the flags, environments and identities sit in the PostgreSQL database you provide, inside your own cloud account or data center. Redis handles caching, and optional Edge Proxies can be placed closer to services that need lower latency. LaunchDarkly, by contrast, keeps its flag management control plane in its own SaaS, so the question for your team is no longer whether flag data leaves your network but who operates the database, its backups and its failover. Confirm this with your architects before anything else, because the answer determines your backup, restore and audit evidence.

The Flagsmith Helm chart (flagsmith/flagsmith) creates its own PostgreSQL server inside the cluster by default. That is convenient for a pilot but is not the production pattern the Flagsmith Kubernetes documentation recommends, which favors an externally managed database with optional PgBouncer for connection pooling. Decide early which database service, instance class and storage encryption you will use, who holds the credentials and how they are rotated, and whether the Helm values point to that external endpoint. A default in-cluster database can quietly become the system of record if nobody changes it. Note that the Flagsmith Operator for OpenShift is an Enterprise feature, so the chart remains the route for OpenShift users on the open-source edition.

Your residency and recovery position is defined by your environment, not by the software. Ask your database and cloud teams to confirm where the PostgreSQL primary and replicas run, where automated and point-in-time backups are stored, how long they are retained, and whether a restore into a separate region has been tested. Confirm that Redis and any Edge Proxies hold only data you are comfortable replicating, and that logs and telemetry from the Flagsmith pods do not leave your boundary. Write these answers down as part of your data flow record, since an auditor or a data protection officer will ask for them, and DeployOpen can help prepare that evidence without issuing any attestation.

Hosting models, identity and compliance implications

Flagsmith can be run in several ways, and each one moves a different share of work, risk and evidence onto your team. The cards below cover the quick-start, production, OpenShift and identity choices, plus the compliance boundary that stays with you in every model.

Docker Compose for quick starts

Docker and Docker Compose are the documented quick-start paths for self-hosted Flagsmith. They suit a proof of concept, a test import of LaunchDarkly projects or a sandbox for SDK changes. Treat a Compose stack as a non-production setup: you still choose the database, backups, TLS termination and the upgrade path. Before any import, confirm which Flagsmith release you will pin and how you will roll it back.

Helm chart with external PostgreSQL

The official Helm chart creates its own PostgreSQL server inside the cluster by default. For production, Flagsmith's documentation recommends an externally managed database, with optional PgBouncer for connection pooling. Your team then owns the database engine, its patching, backup and restore tests, and the credentials Flagsmith uses. Ask your platform team which managed or self-run PostgreSQL service will hold flag and audit data before you commit to this layout.

OpenShift through Helm charts

Flagsmith runs on OpenShift through its Helm charts. Support for the Flagsmith OpenShift Operator is available only with an Enterprise plan. Without that plan, your team manages the chart values, security context constraints, route configuration and upgrades itself. Confirm with your OpenShift administrators which image and permission settings the chart needs, and decide whether the operator's lifecycle support is worth the Enterprise cost.

SAML and Okta as Enterprise features

SAML single sign-on, including Okta integrations, is an Enterprise Edition feature and is closed source. Flagsmith's FAQ also states that LDAP is not configured out of the box. If your workforce signs in through a central identity provider, plan for either the Enterprise license or a separate access path for administrators. Map who may change flags in production, and confirm how the Enterprise role-based controls that start at the Scale-Up plan would replace them.

Controls prepared, not certified

Self-hosting Flagsmith gives you the configuration, logs and access records that an assessor will ask for, but it does not make the system compliant on its own. Certification and attestation come from independent auditors and certification bodies. DeployOpen prepares systems, controls and evidence for a compliance assessment without issuing audit reports. Ask any implementation partner to name which control evidence it will produce and which assessor will review it.

Patching and access reviews by model

In a SaaS model, the vendor patches the platform and hosts the access logs. In a self-hosted model, your team patches the Flagsmith release, the Kubernetes or OpenShift nodes, PostgreSQL and any PgBouncer layer, and runs the quarterly access reviews for administrators and flag editors. Write this split into your responsibility matrix before cutover. Name the owner of each patch window, the owner of each access review and the owner of the audit log export.

What the Flagsmith editions and license change for internal use

Most of the Flagsmith codebase is released under the BSD 3-Clause license, which permits internal use, modification and redistribution with attribution and the license notice retained. Flagsmith's own FAQ states that the self-hosted open-source version has no API request limits, so an internal deployment does not meter evaluation calls the way the hosted plans do. The core covers flag and remote config management, environments, projects and the SDK-facing API, which is the foundation most teams run.

Permissive core: BSD 3-Clause covers the majority of the code, so internal use does not trigger copyleft obligations.
No request metering: the self-hosted open-source version has no API request limits, unlike the request-based hosted tiers.
Core features: flags, remote config, environments and the API are part of the open-source code base.
Deployment choice: Docker Compose for quick starts and Helm for clusters both run the open-source edition.
Scope boundary: the license covers the open-source code, not the Enterprise directories described in the other tabs.

Confirm the license file in the exact release you deploy, since the repository layout and edition boundaries can change between versions.

How the cost of each option is built

LaunchDarkly and Flagsmith bill on different units, so the same team can land on very different invoices. The cards below separate the subscription from the infrastructure, database, staff time and upgrade work that a self-hosted Flagsmith deployment carries, and list what to ask for before comparing totals.

LaunchDarkly billing units

LaunchDarkly bills on service connections and client-side monthly active users, so cost follows how many services connect to flags and how many end users run client-side SDKs. Growth in either unit moves the invoice even when your team size stays flat. Ask the vendor to model your current service connection count and client-side MAU against its current plan terms, and confirm which features sit behind Enterprise pricing, since those are priced separately from the base plan.

Flagsmith request-based tiers

Flagsmith's cloud plans scale with API requests: Free covers 50,000 requests per month with one team member, Start-Up covers 1,000,000 with three, and Scale-Up covers 5,000,000 or more. Extra API calls on Free, Start-Up and Scale-Up cost $50 per million per month, so a busy client-side integration can push you into overage before you change plans. Self-hosting removes this metering on the open-source edition, because Flagsmith's FAQ states it has no API request limits.

Enterprise and governance pricing

On Flagsmith's pricing page, SAML single sign-on and governance features such as roles, permissions, change requests and audit logs start at the Scale-Up plan, and Enterprise is custom-priced for cloud, private cloud or self-hosted deployment. Self-hosted Flagsmith Enterprise features are closed source and need a license. Ask for a written quote that names each Enterprise feature you need, the deployment model and the support terms, because these lines often decide the total.

One-time setup and migration

The one-time work includes standing up the Helm or Compose deployment, planning the import of LaunchDarkly projects and environments, checking imported flags by hand and swapping SDKs or wrapping calls in OpenFeature. Flagsmith's importer overwrites existing data in the target project, so a fresh project and a rehearsal in a non-production environment usually add effort. Ask for the migration scope in writing, including how many SDK integrations and environments are in play.

Recurring infrastructure and database

Self-hosting makes you pay for compute, storage, backups and the PostgreSQL service. Flagsmith's Helm chart creates its own PostgreSQL server in the cluster by default, but the docs recommend an externally managed database in production, with optional PgBouncer. Redis caching, the asynchronous task processor and any Edge Proxies add further components. Ask your platform team to price each component in your own cloud account, since the cost depends on your region, sizing and backup policy.

Upgrades, support and staff time

Recurring staff time covers upgrades, security patching, backups and on-call coverage for the flag service, which sits on the critical path of releases. Flagsmith v2.286.0 was released on October 15, 2026, so the upgrade cadence is a planning input: track the GitHub releases page and budget engineer time per release. OpenShift support for the Flagsmith Operator requires an Enterprise plan, which changes whether support is bundled. Ask who owns each upgrade and what the support terms cover.

How a move from LaunchDarkly to Flagsmith unfolds

The sequence moves flags and environments into a Flagsmith instance on your own PostgreSQL, verifies what the importer carried over, and switches applications over only after both systems have agreed on flag behavior.

Deploy Flagsmith on your PostgreSQL
Your platform team deploys Flagsmith with Docker Compose for a trial or with the official Helm chart for production, and points it at an externally managed PostgreSQL instance rather than the chart's default in-cluster database, which the Flagsmith Kubernetes documentation recommends for production. Confirm the database backup and restore process, the connection pooling choice (the docs describe optional PgBouncer), and whether Redis caching is needed for your traffic. The step is done when the admin console loads, a test user can sign in, and a backup of the empty database has been restored successfully once.
Create a fresh target project
Before any import, create an empty Flagsmith project that will receive the LaunchDarkly data. The importer overwrites existing environments and flags in the target project, so do not reuse a project that already holds configuration you need. Name the project so it is clearly a migration target, and record which LaunchDarkly project it will mirror. The step is done when the empty project exists and a written list of LaunchDarkly projects to import is agreed by the owning team.
Add the LaunchDarkly access token
A team member with administrator rights in both systems creates a LaunchDarkly access token with the narrowest read permissions the importer needs, then adds it in the Flagsmith project settings to start the import. Each LaunchDarkly project becomes a Flagsmith project and each LaunchDarkly environment is copied as a Flagsmith environment, so review the token's scope against the projects listed in the previous step. Store the token in your secrets manager and revoke it after the import. The step is done when the importer reports completion and the token has been removed from the settings.
Review imported environments and flags
The engineering lead compares each imported environment and flag count against the LaunchDarkly console, paying attention to environment names, the number of flags and the archived flags. Flagsmith keeps boolean on and off states and maps multivariate variations to Flagsmith multivariate values, but Flagsmith's documentation says imported flags should be checked by hand afterwards. Record every mismatch in a migration log. The step is done when every environment is accounted for and each mismatch has an owner and a resolution.
Verify boolean and multivariate flag values
QA engineers test each flag in each environment by evaluating it through the Flagsmith API or SDK and comparing the result with the value the same user receives in LaunchDarkly. Pay particular attention to multivariate flags, default variations, and any targeting rules or segments that the importer did not map as expected. Confirm the outcome for a representative set of test identities in every environment. The step is done when the test matrix passes or each difference has a documented decision from the product owner.
Decide how to handle archived and deprecated flags
Product and platform owners review flags that LaunchDarkly marked as archived or deprecated. Flagsmith imports these as archived, which keeps them out of active use but still in the record, so decide which ones should remain for audit history and which should be removed from code before cutover. Check that no application still evaluates an archived flag by accident. The step is done when each archived or deprecated flag has a recorded disposition and the code search for those flag keys comes back clean.
Swap SDKs or move to OpenFeature providers
Engineering teams replace the LaunchDarkly SDK calls with Flagsmith SDK calls in each service, or wrap the calls behind the CNCF OpenFeature API and switch the provider. Using OpenFeature reduces the number of code changes at cutover if you expect to change vendors again, though the provider you choose must cover your languages. Test that user context values, such as keys and attributes, are passed the same way so targeting does not change. The step is done when every service builds, passes its tests and evaluates flags against the Flagsmith test environment.
Run both systems in parallel before cutover
Run LaunchDarkly and Flagsmith side by side for a period the owners agree, with the new SDK code deployed behind a control that lets you switch a service back. Compare evaluations for sampled traffic and watch for any change in user bucketing in partial rollouts, since moving a rollout between systems can reassign users. Confirm the rollback path works in a staging environment before you go live. The step is done when the parallel comparison shows no unexplained differences and the sign-off from the product, security and platform owners is recorded.

Questions buyers ask before choosing Flagsmith over LaunchDarkly

What drives the cost of self-hosting Flagsmith compared with LaunchDarkly billing?

Your cost is driven by the infrastructure you run and the people who run it, while LaunchDarkly bills on service connections and client-side monthly active users. Flagsmith's self-hosted open-source version has no API request limits, so its software line item is zero, but you pay for compute, a PostgreSQL database, Redis, backups, monitoring and the engineering time to upgrade and patch. Costs rise with the number of environments, SDK polling volume and availability targets. Ask LaunchDarkly for a quote based on your actual service connections and MAU, and ask your own platform team to price the hosting components, because those are the two numbers you will compare.

Does Flagsmith's request-based pricing change as our traffic grows?

Yes, if you use Flagsmith Cloud, request volume is the billing unit, and additional API calls on the Free, Start-Up and Scale-Up plans cost $50 per million per month, according to the Flagsmith pricing page. Self-hosting removes that meter because the open-source version has no API request limits, so growth shows up as more load on your servers instead of a higher invoice. Plan for database connections, caching and the Edge Proxy as traffic increases, and load test with your real SDK polling pattern before you commit to a sizing.

How much time and what staff does a Flagsmith self-hosting project need?

The work needs a platform or DevOps engineer for deployment, a database owner for PostgreSQL, and an application owner who knows the SDK integrations. Deployment choices shape the effort: Docker Compose suits small evaluations, while production Kubernetes setups need an externally managed database and optional PgBouncer, as the Flagsmith Kubernetes documentation recommends. Ask any implementation partner for a written scope listing deliverables and timelines before work starts, since DeployOpen works on fixed-scope engagements agreed in writing. Ongoing upgrades and support can be handled by your team or by a retainer.

Can our own team migrate from LaunchDarkly to Flagsmith without outside help?

A capable engineering team can run the built-in importer, but it helps to know what it does before you start. Flagsmith's importer uses a LaunchDarkly access token, maps each LaunchDarkly project to a Flagsmith project and copies every environment. It overwrites existing environments and flags in the target project, so import into a fresh project. Your team still has to swap the LaunchDarkly SDK calls in each application, or wrap them behind OpenFeature first, and verify targeting behavior. If those tasks exceed your capacity, a fixed-scope engagement can cover them.

Does Flagsmith's importer copy everything, and what should we check by hand?

No, the importer covers the main flag structures but not every detail, so treat its output as a starting point. According to the Flagsmith documentation, it keeps boolean on and off states, maps multivariate variations to Flagsmith multivariate values, and imports archived or deprecated flags as archived. Check targeting rules and segments, percentage rollouts, flag defaults in each environment, and any custom attributes your rules depend on. Compare results environment by environment in a test project, since the documentation says the output should be reviewed by hand afterwards.

Do SAML and RBAC require the Flagsmith Enterprise license?

Yes. Flagsmith's FAQ states that Enterprise Edition features such as role-based access control and SAML single sign-on are closed source and require a license. The Flagsmith pricing page places SAML single sign-on and governance features, including roles, permissions, change requests and audit logs, from the Scale-Up plan onward. Confirm current terms with Flagsmith before you design your access model, because a self-hosted deployment that relies on these controls needs a paid license. Also confirm which database integrations are Enterprise-only, since the FAQ groups some of them with the closed-source set.

Is OpenShift deployment supported without the Flagsmith Operator?

Flagsmith runs on OpenShift through its Helm charts, and the Operator is the part that requires an Enterprise plan. According to the Flagsmith Kubernetes documentation, Helm chart deployment is the route available to teams on the open-source version, while Operator support is limited to Enterprise. Confirm the chart version, security context requirements and your database setup against the Flagsmith documentation and your own OpenShift policies before deployment. The Helm chart creates its own PostgreSQL server by default, so most production teams will override that with an externally managed database.

How DeployOpen helps evaluate, implement or migrate Flagsmith

DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure, including Flagsmith. For LaunchDarkly vs Flagsmith, the work starts with a written scope that settles which features you need, which edition you run and where the flag data lives.

How we scope

Inventory which LaunchDarkly projects, environments and flags are in use, and which are archived or stale.
Confirm whether Enterprise features such as RBAC, SAML and audit logs are required, since they are closed source.
Agree in writing the target PostgreSQL, Kubernetes or OpenShift footprint, and the SDK languages to cover.

How we build

Deploy Flagsmith with the official Helm chart against an externally managed PostgreSQL database.
Run the built-in LaunchDarkly importer into a fresh project, then check flags and environments by hand.
Test SDK integrations and evaluation results in a staging environment before any production cutover.

How we hand over

Document the deployment, configuration, backup and upgrade procedures in your own environment.
Provide a reconciliation record listing each imported flag and the checks performed on it.
Walk your platform and engineering teams through running Flagsmith and the SDK changes they own.

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 after handover.
Quotes follow from the written scope, so ask for line items covering each deliverable and any retainer.

LaunchDarkly vs Flagsmith