Replacing LaunchDarkly with Self-Hosted Feature Flags
LaunchDarkly charges per MAU and the bill climbs fast. Unleash, Flagsmith, and GrowthBook deliver the same capability self-hosted for under $200/month.
By Andrii Votiakov on
Feature flags are one of those tools where the value is obvious and the pricing model eventually becomes painful. LaunchDarkly started as the clear default — great SDKs, solid reliability, excellent documentation. Then the per-MAU billing kicks in at scale and you realise you're paying $2,000-10,000/month for a service that is, in practice, a key-value store with a fancy UI.
Quick answer
LaunchDarkly charges roughly $10-20/month per 1,000 MAU on their Team and Business plans (2026 pricing). At 50,000 MAU that's $500-1,000/month; at 200,000 MAU you're in enterprise pricing territory. Unleash (open-source) or Flagsmith (open-source) self-hosted typically costs $80-250/month in compute at any MAU count, because they don't charge per-user. For most teams above 20,000 MAU, the case for self-hosting is strong.
How LaunchDarkly pricing compounds
LaunchDarkly's Team plan starts at around $200/month for up to 1,000 MAU (monthly active users for feature flag evaluations). Beyond that:
- $0.02-0.05 per MAU per month on Team/Business plans
- The Business plan adds SSO, approval workflows, and audit log — required for most companies over 20 engineers
- Experimentation (A/B testing) is an additional add-on, priced per event
- Data Export (to your warehouse) is another paid add-on
- Enterprise plan unlocks custom roles, compliance features, and — in many cases — triggers the "talk to sales" pricing conversation
A company at 100,000 MAU, using the Business plan with Experimentation, can easily be at $3,000-6,000/month. That's significant for a tool whose core function is: "is this flag on or off for this user?"
The MAU model has a specific sting for B2C products with large user bases who have low flag evaluation frequency. If 80% of your users barely touch the flagged features, you're still paying MAU for all of them.
The self-hosted options
Unleash
Unleash is the most mature open-source feature flag system. It's been around since 2014, has a robust API, good SDKs (all major languages), and an active community. The open-source version covers the core use cases: feature toggles, gradual rollouts, A/B testing by user segment, canary releases.
Running Unleash: Postgres + the Unleash server (Node.js). Single server handles enormous load — flag evaluation is read-heavy and cheap. Add a Redis proxy layer if you need sub-millisecond latency at very high evaluation rates.
Compute cost: a single medium instance ($30-80/month) handles most production workloads. Add a managed Postgres ($30-60/month) and you're done.
Unleash Enterprise (hosted by them) starts at $75/month for 5 users — still significantly cheaper than LaunchDarkly at any real scale, and includes SSO, advanced segments, and Jira integration.
One thing I like about Unleash: the SDK communication model. SDKs poll the Unleash server directly (or via a Redis-backed proxy), rather than making per-evaluation API calls. This means flag evaluations are fast and don't add latency to your request path.
Flagsmith
Flagsmith is another strong open-source option. It covers feature flags, remote configuration, and user segment targeting. The UI is cleaner than Unleash, which matters for non-engineering stakeholders who use the flag admin panel.
Flagsmith's architecture is simpler than Unleash — Django app + Postgres. Easy to self-host on a single VM or in Kubernetes.
Worth considering Flagsmith over Unleash if:
- You need remote configuration (not just flags, but actual config values that update at runtime)
- Your product managers and non-engineers will be using the admin UI frequently
- You want a cleaner API for multi-environment management
Flagsmith Cloud is also available at reasonable pricing if you want managed hosting without the per-MAU model.
GrowthBook
GrowthBook's angle is experimentation first. It's less about feature flags in the traditional sense and more about A/B testing infrastructure — statistical analysis, feature rollout tied to experiment results, warehouse-native analysis.
If your primary use case for LaunchDarkly is experimentation (not just flags), GrowthBook is worth a look. The warehouse-native approach (experiments pull data from your data warehouse rather than running their own event collection) avoids the event pricing issue entirely.
GrowthBook open-source is MIT-licensed. The cloud version has a generous free tier. Self-hosted runs as a Docker container alongside a MongoDB or Postgres database.
GO Feature Flag
GO Feature Flag (GOFF) is the minimal option. Flags are defined in a YAML/TOML/JSON file hosted on S3, GCS, GitHub, or an HTTP endpoint. No database. No persistent server. SDKs fetch the flag file on startup and poll for changes.
This is genuinely the right architecture for teams that want zero ops overhead. No server to manage, no database to maintain. The trade-off: no admin UI, no audit log, no complex segments. Everything is in the flag file.
For teams with 10-30 feature flags and strong engineering culture (no PM self-service needed), GO Feature Flag is the cleanest possible solution. I've seen companies run this pattern at hundreds of millions of flag evaluations per day with essentially no infrastructure cost.
OpenFeature
OpenFeature deserves a mention as a standard rather than a tool. It's a CNCF sandbox project that provides a vendor-agnostic SDK interface for feature flags. The idea: instrument your code against the OpenFeature spec, then plug in whichever backend you want (LaunchDarkly, Unleash, Flagsmith, or your own) without changing application code.
If you're currently on LaunchDarkly and instrumented with their native SDK, migrating to any other provider means touching every flag call in your codebase. OpenFeature solves this at the abstraction layer: write once against the OpenFeature interface, swap backends without code changes.
Worth adopting now, even before you migrate, to make the next migration cheaper.
The migration
Step 1: Audit your LaunchDarkly usage
Before starting, understand what you actually have:
- How many feature flags exist? (Often more than people think — dead flags accumulate)
- Which flags are in active use vs dormant?
- Which SDKs and which services?
- Are you using LaunchDarkly Experiments (A/B tests)?
- Are you using LaunchDarkly segments, or just simple on/off targeting?
Delete dormant flags before migrating. I've seen codebases with 300+ flags in LaunchDarkly where fewer than 60 are actually evaluated in the last 90 days. Migration is a good forcing function to clean house.
Step 2: Deploy your replacement
Stand up Unleash or Flagsmith in your staging environment. Wire up SDKs alongside the existing LaunchDarkly SDKs — dual-evaluate for a week to verify both systems return the same results for the same users.
Step 3: Migrate flags
Export your flag configurations from LaunchDarkly (there's a Terraform provider and an API). Recreate in Unleash/Flagsmith. For simple on/off flags, this is mechanical. For complex targeting rules (percentage rollouts by segment, specific user attribute targeting), review each one manually.
Step 4: Cut over by service
Migrate service by service, not all at once. Start with the least critical service, validate for a week, then proceed. This limits blast radius if something behaves unexpectedly.
Step 5: Cancel LaunchDarkly
Keep it running in read-only mode for 30 days after the last service is migrated. Then cancel.
When self-hosting isn't right
Self-hosting feature flags doesn't make sense when:
- You're very small (< 5 engineers). The ops overhead and context-switching cost isn't worth it.
- You're doing heavy experimentation at large scale and the statistical analysis tooling in LaunchDarkly Experimentation genuinely saves you time.
- Your primary use case is mobile flags with client-side evaluation at very high frequency — some edge cases around SDK streaming connections are better served by LaunchDarkly's infrastructure.
The decision is a straightforward application of the build-vs-buy framework: high enough cost, low enough feature utilisation, generic enough workflow.
What you give up
- LaunchDarkly's reliability guarantees and their global edge network for fast flag delivery. Unleash and Flagsmith are perfectly reliable; you just own that reliability.
- Tight Jira/Linear integrations on the open-source tier (available on Unleash Enterprise).
- Automated stale flag detection — LaunchDarkly has tooling to find flags that haven't been evaluated recently. You can build this; it's a SQL query against your event table.
- LaunchDarkly's vendor support — you're now on Slack/GitHub issues for open-source.
What you gain
- No MAU-based pricing. Serve 1M users or 10M users; your compute bill changes slightly, your flag bill doesn't.
- Your flag data stays in your infrastructure. No third party receiving every flag evaluation event.
- No limits on flags or environments. LaunchDarkly gates some features by plan; self-hosted has no artificial limits.
- OpenFeature compatibility — instrument once, swap backends forever.
Realistic numbers
Client — B2C product, 90,000 MAU, LaunchDarkly Business plan with Experimentation:
- LaunchDarkly: $2,800/month
- Replaced with: Unleash self-hosted on EKS (single deployment + managed RDS Postgres)
- Compute + DB: ~$130/month
- Migration: 2 weeks engineering (flag audit, SDK swap, staging validation)
- Total new cost: $130/month
- Saving: $2,670/month, $32,040/year
The Experimentation migration was the interesting part. They had 8 active experiments in LaunchDarkly. Five were simple percentage rollouts — trivially rebuilt in Unleash. Three were proper A/B tests with statistical analysis. Those moved to GrowthBook (free tier covers their usage) which they run alongside Unleash. Result: better experimentation tooling than they had before, at lower total cost.
For context on how I think about these decisions in general, the build-vs-buy framework walks through the full scoring approach.
If your LaunchDarkly bill is climbing with your MAU count and you want to know what migration actually involves, book a call.