Is there an open-source alternative to LaunchDarkly Experimentation?
Yes, for experimentation the open-source option is self-hosted GrowthBook. It runs the experiment analysis against your own data warehouse, sending read-only SELECT queries to sources such as Snowflake, BigQuery, Redshift or Postgres and receiving back only aggregated statistics. If your renewal or Data Export cost is pushing you to review LaunchDarkly experiments, the core question is whether your event data can stay where it already lives and whether your team is comfortable owning the statistics and metric definitions. GrowthBook's approach moves that work into your warehouse rather than into a vendor's event pipeline, so the export line item largely goes away, but the warehouse compute and the modeling work become your responsibility.
Be precise about what the free tier covers. The self-hosted Open Source plan is free with unlimited users, but it is limited to 1 project, and bandits, holdouts, sticky bucketing, approval workflows, SSO and SCIM are only in the self-hosted Enterprise tier. If your experiments depend on holdouts or sticky bucketing to keep users in a stable variant across sessions, budget for Enterprise or confirm with GrowthBook that the free version meets that requirement. Check the current limits on the GrowthBook pricing page before you model costs, since tiers change.
You do not have to move your flags to get experiments. GrowthBook can run experiments on feature flags it manages, but many teams keep release flags in Unleash or Flagsmith and use GrowthBook only for analysis, wiring exposure events from the flag SDK into the warehouse. Confirm that your flag platform's exposure events carry the assignment and user identifiers GrowthBook needs, and test that path in a staging environment before you cut over.
Which LaunchDarkly Experimentation capabilities map to GrowthBook
This table compares the main LaunchDarkly Experimentation capabilities with what GrowthBook offers in its free self-hosted Open Source plan and in self-hosted Enterprise. Read the tier column first, because several capabilities that matter for mature experiment programs sit behind the paid tier. Confirm each row against your own LaunchDarkly contract before you plan the migration, since packaging varies by agreement.
| Capability | GrowthBook self-hosted Open Source | GrowthBook self-hosted Enterprise |
|---|---|---|
| Experiment setup linked to feature flags | Experiments attach to feature flags with a single project and unlimited users | Same flag-linked setup, with approval workflows added on top |
| Warehouse analysis against your own data | Runs SELECT queries against your warehouse and sends only aggregated statistics back | Same warehouse analysis, with the same read-only query model |
| Supported data sources | Covers BigQuery, Snowflake, Redshift, Databricks, Postgres, MySQL and other listed sources | Same source list; confirm connector coverage for your exact warehouse version |
| Metric definitions and reuse | Metrics are defined against the warehouse and reused across experiments | Same metric model; confirm governance over who can edit shared metrics |
| Statistical analysis | Built-in statistics engine runs in the bundled Python service | Same engine; confirm any statistical methods your analysts currently rely on in LaunchDarkly |
| Gradual rollouts and ramp schedules | Basic rollouts are available through flags | Not applicable |
| Safe rollouts and ramp schedules | Not applicable | Yes |
| Sticky bucketing | Not applicable | Yes |
| Holdouts | Not applicable | Yes |
| Multi-armed bandits | Not applicable | Yes |
| Approval workflows | Not applicable | Yes |
| SSO and SCIM provisioning | Not applicable | Yes |
| Advanced permissioning | Not applicable | Yes |
GrowthBook, Unleash and Flagsmith: which option fits experiments
GrowthBook is the only one of these three that runs experiments natively, so it is the default choice when experiments are the main need. Unleash and Flagsmith are flag-first platforms that need a separate analysis tool for statistics. The cards below set out what each option includes, what its license and free tier allow, and what to check before you commit.
GrowthBook as the experimentation platform
GrowthBook handles flags and experiments in one product and analyzes results against your own warehouse with SELECT queries, so event data stays where it already lives. The self-hosted Open Source plan is free with unlimited users but allows only one project, which is often the first limit a multi-team organization hits. Confirm how many projects you need before you size the deployment, and check whether the Enterprise features you depend on (bandits, holdouts, sticky bucketing) are in the paid self-hosted tier.
GrowthBook licensing boundaries
Code outside GrowthBook's enterprise directories is MIT licensed, while the enterprise directories fall under the GrowthBook Enterprise License. This split matters for legal review, because a fork or internal patch touching the enterprise directories is governed by different terms than the rest of the codebase. Have counsel read the LICENSE file against the exact version you plan to deploy, and record which directories your team modifies.
Unleash as a flag-first option
Unleash is built around release flags, strategies and environments, and it does not ship a statistical experimentation engine in its open-source edition. Teams that choose Unleash for experiments pair it with a separate analysis tool, which means a second system to license, integrate and govern. Its Open Source edition is limited to 1 project and 2 environments, so check whether that scope covers your release process before you assume the free tier works for a multi-team rollout.
Unleash license and edition trade-offs
Starting with v8.0.0, the Unleash server source code moved to AGPLv3, while the official open-source Docker images remain under Apache 2.0. Running unmodified images for internal use does not trigger the source-publication duty, but modifying the server and offering it as a service does. Confirm with counsel whether any internal patch or hosted offering you plan falls under the AGPLv3 terms, and decide whether the Enterprise tier, which adds SSO, SCIM and change requests, is needed.
Flagsmith as a flag and config platform
Flagsmith combines feature flags and remote config on PostgreSQL, and it offers a built-in LaunchDarkly importer. Its experimentation capability is not a statistical engine comparable to GrowthBook's, so experiment results typically come from an external analytics or warehouse tool. Verify what Flagsmith's experiment features cover in your target version before you design the analysis pipeline around them.
Flagsmith edition and governance limits
Most of Flagsmith is BSD 3-Clause licensed, but role-based access control, SAML single sign-on and certain database integrations are closed-source Enterprise features. Governance features such as roles, change requests and audit logs start at the Scale-Up plan on the pricing page, and SAML is Enterprise-only. If your audit or access requirements depend on these controls, price the paid tier into the comparison rather than assuming the free self-hosted build covers them.
Which metrics move when experiments leave LaunchDarkly
The metric definitions, event tables and statistical analysis that teams run against LaunchDarkly do not travel as a single export. What moves is the underlying event data, usually through LaunchDarkly's Data Export add-on, and then the metric logic has to be rebuilt where that data lives. In a self-hosted GrowthBook setup, metric queries run against your own warehouse as read-only SELECT statements, and only aggregated statistics come back to the GrowthBook application. Plan the move as a rebuild of metrics in your warehouse, not as an import of finished results.
For analysts, the biggest change is that metrics become SQL. A conversion or revenue metric defined through LaunchDarkly's interface becomes a query against a specific table, with a user identifier, an event timestamp and a value column. Before cutover, confirm the event schema for every metric in use: the table names, the column that identifies the experiment unit, how exposure events are recorded, and whether custom events arrive with the fields the metric expects. Ask your data team to check for duplicate events and late-arriving data, because those change results in a warehouse query in ways a hosted tool may have hidden.
Expect some metrics to need a decision rather than a copy. Any metric that depended on a LaunchDarkly-specific event shape, or on data that was never exported, must be recreated from source data or retired. Run the old and new metric values side by side for at least one full experiment cycle and document every difference, so that analysts can explain why a number moved. Ask GrowthBook and your warehouse team to confirm which data source types and permissions your setup needs before you commit to a timeline.
What GrowthBook's free plan leaves out for experiments
The self-hosted Open Source plan is free and allows unlimited users and unlimited API requests, with one project. For experiments, this means you can run warehouse-native analyses against your own data, define metrics, and read results without paying per seat. The plan's limits are structural rather than per-experiment, so a single project is the constraint to plan around. Teams that need several isolated product areas will hit that limit before they hit any statistics limit.
- Experiment analysis: Standard A/B tests run against your warehouse with aggregated statistics returned to GrowthBook.
- Unlimited users: Analysts, engineers and product owners can all log in without a seat charge on the free tier.
- One project: Multiple product areas must share one project, which affects naming, permissions and reporting.
- Unlimited API requests: Automated pipelines that read flags or results are not metered on the free plan.
- Operational ownership: Your team patches, backs up and upgrades the self-hosted stack.
Before committing, confirm the current feature list for the free self-hosted plan on the GrowthBook pricing page, since packaging can change between releases.
Several advanced experiment methods are listed as self-hosted Enterprise features, not part of the free plan. These include multi-armed bandits, which shift traffic toward better-performing variations during a test, and holdouts, which keep a control group out of a set of launches so you can measure the cumulative effect of several changes. Sticky bucketing, which keeps a user in the same variation across sessions and devices, is also listed as Enterprise. Without these, teams can still run standard fixed-horizon A/B tests but must build their own holdout and bucketing conventions if they need them.
- Multi-armed bandits: Adaptive traffic allocation during an experiment, useful when the cost of showing a weaker variation is high.
- Holdouts: Long-running control groups for measuring the combined impact of a release program.
- Sticky bucketing: Consistent variation assignment when user identifiers or attributes change over time.
- Standard A/B tests: Fixed allocation experiments remain available on the free plan for most common use cases.
- Workaround cost: Replicating holdouts or stable bucketing in application code adds engineering and testing effort that recurs with each change.
If your program depends on these methods, ask the vendor to show them working against your warehouse before you size the migration.
Governance features that control who can ship and change experiments are also gated to self-hosted Enterprise. The pricing page lists safe rollouts, ramp schedules, approval workflows and advanced permissioning in that tier. Safe rollouts monitor guardrail metrics during a gradual release, and ramp schedules increase traffic on a planned timetable. Approval workflows require a second person to sign off before a change goes live. For regulated teams, these controls often matter more than the statistics features, because they define the change record that auditors ask to see.
- Safe rollouts: Automatic checks on guardrail metrics during a gradual release.
- Ramp schedules: Planned traffic increases over time, reducing manual changes during a release.
- Approval workflows: Required reviewers before a flag or experiment changes state.
- Advanced permissioning: Finer control over which roles can edit experiments and flags in each environment.
- Change records: Approval history gives your change management process evidence to review.
You can approximate some of these with process and your existing change tooling, but document the gap and the compensating control in writing.
SSO and SCIM provisioning are listed as self-hosted Enterprise features. SSO lets your identity provider handle sign-in, and SCIM lets it create and remove GrowthBook users automatically when people join, change roles or leave. On the free plan, you manage local accounts, which is workable for a small analytics group but adds a recurring access review task. The gap matters most for organizations with strict joiner-mover-leaver processes or where local credentials are not allowed by policy.
- SSO: Sign-in through your existing identity provider instead of local passwords.
- SCIM: Automated user lifecycle changes driven by your identity provider.
- Local accounts on the free plan: You are responsible for password policy, MFA enforcement at the application layer and removing stale users.
- Access reviews: Recurring reviews become manual on the free plan and should be scheduled in your own process.
- Identity integration: Confirm which identity protocols and provider configurations the Enterprise tier supports before purchase.
Ask the vendor for the current Enterprise feature list in writing and check it against your identity architecture.
Feature gating changes, so the list in this section should be treated as a starting point rather than a final specification. Build a short requirements table with each experiment method, governance control and identity requirement your program needs, then mark which tier provides each one. Ask for a quote based on the written list of features and the number of users and projects you expect. Also ask whether the Enterprise license changes how you deploy, upgrade or back up the stack.
- Gated list: Compare the current features on the GrowthBook pricing page with your requirements table.
- Project count: Map how many isolated product areas you need, since the free plan allows one project.
- Test in a non-production environment: Run one bandit, holdout or ramp schedule against a copy of your data.
- Licensing scope: Confirm which directories are under the enterprise license and how they affect your internal use.
- Quote basis: Request pricing tied to the written feature list, user count and deployment model.
Running GrowthBook alongside LaunchDarkly flags or Unleash
Most teams do not need to move every flag at once. The options below separate who assigns users to variants from who analyzes the results, because that boundary decides how much migration risk you carry. Read them in order before you pick a split, since each one changes what has to match across systems.
Keep LaunchDarkly for flags, GrowthBook for analysis
You keep LaunchDarkly as the system that serves flags and assigns users, and point GrowthBook at your warehouse to compute results from the same exposure events. This removes the need to migrate flag definitions first, but it means the analysis depends on LaunchDarkly exposure data reaching your warehouse. Confirm with your data team how LaunchDarkly events land there today, and whether that feed is part of the Data Export add-on you pay for.
Keep Unleash or Flagsmith for flags
If your flags already live in Unleash or Flagsmith, GrowthBook can run experiments against the exposure events those systems produce, and you avoid a second assignment system. Check that each exposure record carries the experiment key, variant and a stable user identifier that matches your warehouse tables. Unleash Open Source is limited to 1 project and 2 environments, so confirm your tier before you plan more experiments on top of it.
Two assignment systems, two answers
When LaunchDarkly or Unleash assigns a user to a variant and GrowthBook also assigns that user, the two systems can bucket the same person differently. A user may see one variant in the flag SDK and be counted in another in the analysis, which biases results. Pick one system as the source of assignment for each experiment, and treat any second assignment as a defect to test for before launch.
Sticky bucketing and holdouts
Sticky bucketing keeps a user in the same variant across sessions and config changes, and holdouts keep a share of users out of a rollout to measure its long-term effect. The GrowthBook pricing page places both among the features the self-hosted Enterprise plan adds, not the free Open Source plan. If your experiments depend on either, ask for that tier in a quote and confirm which system will hold the assignment record.
OpenFeature as a buffer layer
OpenFeature is a CNCF project that sits between your application code and the flag vendor, so calls to LaunchDarkly can later be routed to another provider without rewriting every call site. Provider coverage differs by language and by vendor, so check the SDK languages and providers your services need against the OpenFeature documentation before you rely on it. It does not remove the need to match assignments during cutover.
Moving experiments, metrics and results out of LaunchDarkly
This sequence moves running and planned experiments into self-hosted GrowthBook against your own warehouse, and proves the new numbers agree with the old readouts before any team relies on them. Each step ends with a check you can show to an auditor or a product owner.
Inventory running and past experiments
Experimentation owners list every experiment that is live, paused or scheduled in LaunchDarkly, along with its flag, primary metric, guardrail metrics, audience and start and end dates. Past experiments that informed launch decisions go on the same list, marked as reference only. Data or analytics engineers confirm which events and warehouse tables each metric depends on. The step is done when every experiment has an owner and a named source table, and the list is stored with the decision records it supports.
Export experiment and flag definitions
An engineer pulls flag, segment, environment and project definitions from the LaunchDarkly REST API using a scoped access token, and saves the JSON in version control. Experiment metadata is exported the same way where the API returns it, and anything that cannot be exported is recorded by hand. Confirm the export scope and token permissions with your LaunchDarkly account team before running it. The step is done when the exported files can be read back and the object counts match the LaunchDarkly console.
Recreate experiments and metrics on warehouse tables
Analytics engineers rebuild each metric as a SQL definition in GrowthBook, pointing at the exposure and event tables in your own warehouse. GrowthBook runs read-only SELECT queries and transmits only aggregated statistics, so the event data stays where it already lives. Where LaunchDarkly used Data Export files, the same logic is rebuilt from the warehouse copies you already control. The step is done when each metric query runs against the warehouse without errors and returns the expected row counts for a sample date range.
Import flags and confirm what the importer skips
The team runs GrowthBook's LaunchDarkly importer, which fetches projects, environments and flags into a preview before anything is written. Review the preview, then import the pending flags. GrowthBook's documentation states that the importer targets flags and does not carry over historical experiment results, so confirm this with GrowthBook documentation and your own test import before relying on it. The step is done when imported flags match the exported definitions and the historical results gap is written down.
Validate results against LaunchDarkly readouts
For a closed experiment with a known LaunchDarkly readout, an analyst reruns the same audience, dates and metric in GrowthBook and compares the sample sizes, conversion rates and confidence intervals. Differences in statistics engine, bucketing or metric definitions are recorded with their cause, not forced to match. Pick at least one experiment per primary metric type so the comparison covers the definitions your teams use. The step is done when each comparison has a signed-off note explaining any gap.
Replace the LaunchDarkly SDK in each application
Engineers switch each application from the LaunchDarkly SDK to a GrowthBook SDK, or to an OpenFeature provider if the team has wrapped flag calls behind OpenFeature first. Assignment logic and sticky bucketing settings are checked so that users already in an experiment keep their variant. Changes ship behind a feature flag per service. The step is done when staging traffic shows consistent variant assignment for a test user across two sessions.
Cut over new experiments first
Only new experiments start in GrowthBook, while experiments already running in LaunchDarkly finish there so their results stay intact. Each new experiment has a documented primary metric, an owner and a reviewed sample size before launch. Running experiments are migrated only at a natural end point, because moving a user between systems mid-test can re-bucket them. The step is done when two experiment cycles have completed in GrowthBook with results reviewed by the product owner.
How much effort and cost does this replacement take?
What actually drives the cost of self-hosted GrowthBook experimentation?
The cost is a set of separate components, and only some of them are software licenses. The main ones are the infrastructure that runs GrowthBook, the MongoDB or compatible database that stores its metadata, the warehouse compute that runs the experiment queries, any paid GrowthBook seats, and the staff time to operate it. GrowthBook's self-hosted Open Source plan is free with unlimited users, 1 project and unlimited API requests, according to the GrowthBook pricing page, so the recurring spend shifts to hosting, database and compute. Ask your team to size warehouse query costs against your current experiment volume, because those queries run against your own data source.
Which GrowthBook features need a paid Enterprise plan?
The self-hosted Open Source plan leaves several experimentation features behind a paid tier. According to the GrowthBook pricing page, self-hosted Enterprise adds multi-armed bandits, holdouts, sticky bucketing, safe rollouts, ramp schedules, approval workflows, advanced permissioning, and SSO with SCIM. Teams that depend on holdouts or sticky bucketing for valid experiment results should price an Enterprise quote before committing to a migration plan. Confirm current Enterprise pricing directly with GrowthBook, since it is listed as custom.
Can our team run this migration without an outside implementation partner?
A team with Kubernetes or Docker operations experience, a database administrator and an engineer who can connect the warehouse can usually deploy GrowthBook itself. GrowthBook ships as a single Docker image with an official Helm chart, so the deployment part is well documented. The harder work is application-side: replacing the LaunchDarkly SDK in each service, validating statistics against your metric definitions, and confirming that warehouse queries return the aggregates you expect. Teams without these skills in-house can scope that work with DeployOpen as a fixed-scope engagement, with deliverables and timelines agreed in writing before work starts.
How long does the migration take for a small versus a large experiment program?
The duration depends on the number of experiments, metrics, data sources and services that call the LaunchDarkly SDK. A program with a few experiments and one warehouse usually moves faster than one with many metrics, multiple data sources and dozens of services, because each metric definition must be rebuilt and checked. No timeline figure is supplied for this work, so ask any vendor or partner for a timeline tied to your inventory of experiments, metrics and SDK call sites. Running LaunchDarkly and GrowthBook side by side for a period is a common way to compare results before cutover.
What does the migration need from our data team?
The data team owns most of the validation work. They need to provide read-only credentials for the warehouse, confirm which tables hold exposure and event data, and rebuild key metric definitions in SQL. GrowthBook runs only SELECT queries and transmits aggregated statistics, which makes access review simpler, but the team still has to confirm that identity keys match across exposure and conversion tables. Plan for data engineers to check a sample of past experiments against LaunchDarkly results before trusting the new numbers.
What should we ask for in a quote for this replacement?
Ask for a written scope that lists each deliverable, the environments covered, and the systems in and out of scope. The quote should separate one-time work, such as deployment, SDK replacement, metric rebuilding and validation, from recurring work, such as upgrades, backups, monitoring and support. Ask which experiments and metrics are included, how many services will be migrated, and who validates the statistical results. Request a list of the GrowthBook features assumed in the design, so you can confirm whether Enterprise licensing is needed. DeployOpen does not publish a price list, and a quote follows from the written scope.
What recurring costs should we budget for after go-live?
After go-live, recurring costs include the servers or cluster capacity that host GrowthBook, the managed database, warehouse query spend, Enterprise subscriptions if you need them, and staff time for upgrades. GrowthBook releases new versions regularly, with v5.1.0 released on September 22, 2026, according to its GitHub releases page, so budget time for periodic upgrades and testing. Retainers for ongoing support, upgrades and continuous testing are available from DeployOpen if your team prefers an outside party to carry that load.
Does the cost change if we keep our flags in Unleash or Flagsmith?
Yes, because the flag management layer and the experiment layer are priced and operated separately. Unleash Open Source is free and self-hosted with 1 project, 2 environments and 5,000 feature flags per instance, according to the Unleash pricing page, and Flagsmith's Free plan is hosted, so self-hosted Flagsmith cost comes from your own infrastructure. Keeping flags in one tool and experiments in GrowthBook means you pay for two systems to run, so compare the operating effort of both before deciding. Confirm the current limits and paid tiers with each vendor.
How DeployOpen scopes an experimentation migration
DeployOpen works as a fixed-scope implementer for teams that want GrowthBook running in their own infrastructure, and the written scope is where an experimentation migration is won or lost. Before any work starts, the scope should name the GrowthBook deployment target, the data sources the statistics engine will query, the metrics and experiments in use today, the LaunchDarkly Experimentation features in active use, and which of those features need an Enterprise license of GrowthBook. That last item matters most. Bandits, holdouts, sticky bucketing and approval workflows sit on the self-hosted Enterprise tier, so the scope must decide whether those features are required at cutover or can wait.
The deliverables we agree on typically cover the GrowthBook deployment itself, which bundles the Next.js front end, Express API and Python statistics engine in one Docker image with MongoDB or a compatible database behind it, and a Helm chart path for Kubernetes. They also cover read-only warehouse connections, with the data source user limited to SELECT queries, validation that aggregated results match the numbers the team already trusts, hardening of the network path to the warehouse, backups of the metadata store, and documentation for the operators who will run it. Scope should also say who owns the metric definitions, since those move from a vendor console into the team's own repository of definitions.
Ongoing work is priced separately from the initial build. A retainer can cover GrowthBook upgrades, backup restore tests, security patching of the underlying images and databases, and periodic re-testing of the deployment. Ask for the retainer terms in writing, including what is in and out of each upgrade. DeployOpen prepares systems, controls and evidence for compliance reviews, but it does not issue audit reports or certifications, so any SOC or internal audit work needs an independent assessor named in the scope. A quote should follow directly from this written scope, and any item not in the scope should be treated as an open question until it is added in writing.
