Open-source feature flags vs a managed platform: the real trade-off

Search for an open source feature flag tool and you will find several genuinely good ones. Unleash, Flagsmith, and GrowthBook are mature projects with real communities, sensible SDKs, and code you can read line by line. If your instinct is "why would I pay for this when I can run it myself," that instinct is not wrong. It is just incomplete.

The real question is not "open source or paid." It is "who runs the service, and what does running it actually cost." This post tries to answer that honestly, including the cases where self-hosting is clearly the right call.

What you actually get from open source flags

The strengths of self-hosted open source flags are real, and it is worth naming them plainly rather than waving at them.

• Control. You decide the version, the upgrade schedule, the database, the network layout, and the retention policy. Nobody deprecates an API out from under you, and nobody sunsets a plan you depend on.
• Data residency. Flag evaluations often carry user attributes: IDs, plans, regions, sometimes email domains. If your compliance rules say that data cannot leave your infrastructure or your country, self-hosting answers the question completely. No vendor DPA review, no subprocessor list to audit.
• No vendor bill. The license cost is zero. For a hobby project or an internal tool, that can settle the whole debate on its own.
• Inspectable code. When targeting behaves strangely, you can read the evaluation logic instead of filing a support ticket and waiting. For teams that have been burned by opaque vendor behavior, this matters more than any feature.
• No lock-in anxiety. Your flag definitions live in your own database. Migrating away is an export, not a negotiation.

None of this is theoretical. Platform teams at plenty of companies run these tools well and are happy with them.

The part of the bill that is not on the invoice

Here is the trade you are actually making. A feature flag service is not a dashboard you visit occasionally. It sits in the request path of everything. Every page load, every API call, every background job that checks a flag depends on it, directly or through cached SDK state. The day you adopt flags seriously, the flag service becomes tier-0 infrastructure, and self-hosting means you just volunteered to run tier-0 infrastructure.

That has concrete consequences:

• High availability is now your problem. One instance behind one load balancer is not a plan. You need redundancy, health checks, a database with failover, and a story for what SDKs do when the service is unreachable. Good SDKs default to cached values, but "what do we serve during an outage" is now a design decision you own.
• Upgrades are your problem. Security patches, breaking changes between major versions, database migrations that lock tables. Each one is a change window someone has to plan, run, and be ready to roll back.
• On-call is your problem. This is the honest heart of it. The moment your flag service pages someone at 2am, it stopped being free. You are paying in engineer hours and sleep instead of dollars, and engineer hours are usually the most expensive currency you have.
• Scaling and storage are your problem. Evaluation traffic grows with your product. Audit logs and event data grow forever unless someone builds retention. These are small tasks individually and a steady tax collectively.

A useful way to reason about the cost, as illustration rather than as claimed data: suppose keeping the service healthy takes a slice of one engineer's time across setup, upgrades, incidents, and the on-call rotation. Even a modest slice of a loaded engineering salary is often more than a flat platform subscription. The math flips only when you already have a platform team whose job is running shared services, because then the marginal cost of one more service is genuinely low.

The feature gap is real too, in both directions

Open source cores are strong at the fundamentals: boolean flags, percentage rollouts, targeting rules. But several things teams end up needing tend to live in paid tiers, hosted versions, or simply take real work to assemble:

• Experimentation. A/B testing needs assignment, event collection, and statistics that resist peeking. GrowthBook is notably good here; with other tools you are often wiring up your own analytics pipeline.
• SSO and audit trails. The moment security review asks "who changed this flag and when, and can we enforce SAML," you are frequently looking at an enterprise tier anyway, which changes the "it's free" math.
• Reliability of the kill switch itself. A kill switch is only as dependable as the service that serves it. If you turn flags off during incidents, the flag service must be more reliable than the systems it protects. We wrote more about that bar in our kill switches post.

To be fair, the arrow points the other way sometimes. Self-hosted tools can be extended in ways a vendor never will be, and deep integration with internal systems is easier when you own the code.

Self-hosted vs managed at a glance

Dimension	Self-hosted open source	Managed platform
License cost	Zero	Subscription
Real total cost	Engineer time: setup, upgrades, on-call, scaling	The subscription, mostly
Data residency	Full control, stays in your infrastructure	Depends on the vendor's regions and terms
Availability	Yours to engineer and staff	Vendor's job, backed by their SLA
Time to first flag	Days to weeks of infrastructure work	Roughly an afternoon
Experimentation and SSO	Varies; often paid tiers or DIY	Usually built in, check the plan
Lock-in	Minimal	Real; mitigate with clean SDK boundaries

When self-hosting is genuinely the right call

Managed is not always the answer, and pretending otherwise would be selling, not advising. Self-host when:

1. You have strict data residency or air-gap requirements. If evaluation data legally cannot leave your network, the decision is made for you. Run Unleash or Flagsmith and do it well.
2. You have a platform team that wants to own it. If running shared internal services is already someone's job, adding a flag service is a reasonable marginal cost, and the control is worth it.
3. It is a hobby or internal project. If nobody gets paged when it breaks and downtime costs nothing, the calculus that favors managed simply does not apply. A container on a small VM is fine.
4. You need deep custom behavior. Custom evaluation logic or unusual integrations are easier when you own the source.

When managed wins

Managed is usually the better trade when:

1. You are a small team. Five engineers running tier-0 infrastructure for their own tooling is a poor use of five engineers. Every hour on flag-service upkeep is an hour not spent on the product.
2. Your flags are incident-critical. If flipping a flag is how you stop the bleeding during an outage, that flip must work while your own infrastructure is on fire. An independent, externally hosted control plane is a feature, not a compromise.
3. You want experimentation without building a stats pipeline. Assignment, exposure tracking, and honest significance testing are easy to get subtly wrong. Buying them is cheaper than debugging them.
4. Security review is coming. SSO, role-based access, and audit logs arrive checked off instead of becoming a quarter of platform work.

One caveat on managed pricing: many vendors charge per seat, which quietly punishes the best practice of giving everyone access to feature toggle management, including PMs and support. When you compare options, read the pricing model as carefully as the feature list. We wrote up how seat-based models compound in our guide to picking a LaunchDarkly alternative, and the same lens applies to feature flag software pricing generally.

A decision rule you can defend

Strip the ideology out and the decision is short:

• Hard residency requirement, or a platform team eager to own it: self-host an open source tool. They are good. Use one.
• Hobby or internal project where downtime is free: self-host the simplest thing that works.
• Everyone else, especially small teams whose flags gate real releases and real incidents: buy the managed service and spend the reclaimed hours on your product.

Whichever way you go, keep your SDK usage behind a thin wrapper in your own codebase. It keeps lock-in low, makes either future migration cheap, and costs almost nothing today. Comparing feature flag tools gets much less stressful when switching is an export and a config change.

Where we fit: Toggled is a managed feature flags platform with A/B testing, built around flat per-team pricing and unlimited seats, so the whole team gets access without the per-seat math. Self-hosting is planned for the Enterprise tier for teams with residency requirements. We are in early access right now, so no launched-product claims from us, just a live demo on the homepage and a plain explanation of how it works if you want to judge the trade-off for yourself.