Self-hosted feature flags put the flag service on infrastructure you own, which means you run the server, the database behind it, the upgrade path, and the pager that fires when it stops answering. The alternative is a hosted service where somebody else does that and you pay them.
Most comparisons of the two settle into an argument about money, license fee against engineering hours, roughly, with a nod at data residency. That argument is real and it is also the easy half. The harder question is what each model does to your ability to turn a feature off during an incident, and the answer is less intuitive than it looks, because modern flag SDKs already changed where the uptime requirement sits.
Key Takeaways
- Local-evaluation SDKs mean a flag service outage freezes propagation while evaluation carries on from cache.
- You lose the ability to change anything during that outage, which is exactly what an incident needs.
- Self-hosting inside your production cluster puts the kill switch in the blast radius it exists to protect you from.
- Data residency, air-gapped networks, and regulated workloads are the cases where self-hosting wins outright.
- If you self-host, run the flag plane somewhere your application failures cannot reach.
1. What you are actually choosing between
A flag platform has two halves that fail independently.
The control plane is where flags are created, targeted, and toggled. Dashboard, API, database, audit log. It is a fairly ordinary web application. Its availability requirement is that of any internal tool.
The data plane is the part that answers “what value does this user get for this flag”. In a local-evaluation architecture, that answer comes from memory inside your own process. The SDK holds a copy of the flag configuration, keeps it current over a streaming or polling connection, and evaluates against it without a network call. Evaluating a flag costs a map lookup and some rule matching.
Self-hosting means taking on the control plane. It is worth being precise about that, because the phrase “self-hosted feature flags” gets used as though it meant your application stops depending on anything external, and with local evaluation that dependency was already gone.
This is a different question from whether to build a flag system yourself. That one is covered in the build-versus-buy breakdown, and the answer there turns on maintenance slope and opportunity cost. Here you have already decided to adopt a platform. The only question left is who operates it.
2. Local evaluation already decoupled uptime
When the flag service becomes unreachable, a local-evaluation SDK does not start failing. It has the configuration in memory. Every variation() call keeps returning the same values it was returning a second earlier, at the same speed, with no errors and no timeouts. Your checkout flow does not care that a server somewhere stopped answering.
Propagation stops. New flag changes have nowhere to arrive from. The config in memory is frozen at whatever it said when the connection dropped, and it stays frozen until the connection comes back.
Recovery is where implementations differ, and it is worth checking before you commit to any of this. An SDK that treats a connection error as terminal will sit there serving stale config long after the service came back, and you find out during the next deploy. We wrote up what makes recovery the hard part after auditing our own SDKs for exactly that failure.
3. The control plane sits inside your blast radius
Now put the two facts together.
During that outage you can still evaluate flags, and you cannot change them. The moment you most need to change one is during an incident, when something is on fire and the kill switch is the fastest thing you own.
Self-hosting is what decides whether those two events are correlated.
Run the flag service in the same Kubernetes cluster as your application, and a bad day for that cluster is a bad day for both. Control-plane pressure, a node pool exhausted, a networking change that partitions services from each other, a database at connection limits. Any of those can take out your application and your flag service in the same minute. You reach for the kill switch and the dashboard will not load.
A hosted control plane sits outside that boundary by construction, running on someone else’s infrastructure in a failure domain that has nothing to do with your cluster. It has its own outages and those are entirely outside your control, which is a real cost you are accepting. Its bad days will not coincide with yours, though, because nothing connects the two.
The mitigation, if you self-host, is to stop treating the flag service as just another workload. Separate cluster at minimum, and a separate account or region is better still. Anything that keeps the plane you use to fix production from depending on production. Teams that self-host well already do this. Teams that self-host because it was the default deployment in the docs usually have not thought about it, and they discover the coupling at the worst possible moment.
4. When self-hosting is the right call
Plenty of situations point the other way, and they tend to be about data rather than money.
Evaluation context cannot leave your perimeter. This is the strongest case. If the attributes you target on are regulated health data, classified material, or anything under a residency rule with real teeth, then sending them to a third party is off the table regardless of certifications. Local evaluation narrows what crosses the boundary here without closing it, and the difference is worth checking rather than assuming. A server SDK evaluates inside your process, so the targeting attributes never leave for the decision itself, though analytics events typically carry the user identifier back to the vendor afterwards. Client SDKs invert that entirely and send the evaluation context to the service to be evaluated there. Featureflip works this way too, so if your residency rule covers identifiers rather than only payload data, that is the specific thing to verify on any vendor including us.
The network is air-gapped. With no outbound path there is no hosted option to evaluate, whatever its merits elsewhere.
Procurement will not clear a new vendor. Sometimes the blocker is organizational rather than technical, and standing up an open-source server beats waiting out a nine-month security review.
You already run this class of service well. A platform team with an existing on-call rotation, a paved path for stateful services, and a habit of upgrading things absorbs a flag server at low marginal cost. Where that team differs from most is that someone’s job already covers the maintenance.
License cost dominates at your scale. Per-seat pricing on a large engineering organization can reach numbers where a self-hosted open-source edition wins on arithmetic even after you price the operational work honestly. That calculation is worth doing properly rather than assuming either direction, and how the pricing models actually differ walks through the shapes.
If none of those describe you, self-hosting is usually a cost you are choosing rather than one you are avoiding.
5. What the hosted model costs you
Being fair about the other column matters, because a page that only lists one model’s downsides is an advertisement.
You take on a vendor dependency for the control plane, so their outage becomes your inability to change flags, on their timeline, with their status page as your only visibility. You accept that flag configuration crosses a network boundary. You accept a pricing model you do not control, and the risk that it changes in a direction you dislike after you have adopted it. Migrating off is real work even where the SDK layer is portable through OpenFeature.
Those are genuine. The reason the trade usually still favours hosted is that the failure modes are uncorrelated with your own, and the operational work is somebody’s full-time job rather than an interrupt in yours.
6. Where Featureflip sits
Featureflip is a hosted service, and that is the deliberate shape of it. Every self-serve plan runs in our cloud. There is no proxy, sidecar, or cluster for you to operate, and the eight server SDKs evaluate in-process so a backend request path never waits on us. The five client SDKs work the other way round, fetching a pre-evaluated snapshot for the browser or device.
On-premise deployment exists as part of an Enterprise agreement, for the residency and isolation cases in section 4. It is negotiated directly rather than offered on a self-serve plan, so Solo, Pro, and Business are hosted only and self-hosting is not something you can turn on yourself.
Which path fits depends on what is actually driving the requirement, and the two drivers get conflated often enough to be worth separating. If the constraint is residency or isolation, where the data genuinely cannot leave infrastructure you control, that is the case the Enterprise on-premise arrangement exists for and the pricing page has the route to it. If the constraint is a license fee of zero, an open-source project serves that better than we do and Unleash is the obvious one. The full comparison of the two approaches covers where its open-source edition’s limits sit and what the operational trade looks like in practice.
The shorter version
Local evaluation means a flag service outage leaves evaluation intact and freezes everything else. Your application keeps serving flags from its in-memory cache, at the same speed, with no errors. Changing a flag is the thing that stops working, and incidents are precisely when changing one matters.
That reframes the self-hosting decision. Running the flag service inside your production cluster correlates its failures with your application’s, so the kill switch goes down alongside the thing it was supposed to switch off. Self-host anyway when data residency, air-gapping, or procurement demand it, and when you do, run it outside the blast radius. Otherwise let the control plane live somewhere your outages cannot reach.
Frequently asked questions
Are self-hosted feature flags more secure?
They change the shape of the risk rather than reducing it. Self-hosting keeps flag configuration inside your perimeter, which matters under residency or air-gap rules. It also makes you responsible for patching, access control, backups, and the database, which is where most real incidents start. A hosted service concentrates that work with a provider whose job it is. The genuine security argument for self-hosting is about where data sits, and the precise answer depends on which SDK you use: server SDKs evaluate targeting attributes inside your own process, while client SDKs send the evaluation context to the service. Analytics events carry user identifiers back either way, so check what your vendor transmits rather than assuming local evaluation means nothing leaves.
What does self-hosting a feature flag platform actually cost?
The license fee on an open-source edition is zero, and everything after that is engineering time. Running the service, the database behind it, upgrades, monitoring, and on-call coverage for a service your incident response now depends on. Teams that already operate stateful internal services absorb this cheaply. Teams without a platform function tend to underestimate it, because the install is an afternoon and the maintenance is permanent.
Can you self-host Featureflip?
On-premise deployment is available as part of an Enterprise agreement, and it is negotiated directly rather than offered on the self-serve plans. The Solo, Pro, and Business tiers are hosted only. If free self-hosting is the requirement, an open-source project like Unleash fits that better, and our comparison page lays out the trade-offs without pretending otherwise.
Does a feature flag outage take your application down?
With local-evaluation SDKs, no. The SDK holds the flag configuration in memory and keeps evaluating from it, so calls return the same values at the same speed while the service is unreachable. Propagation stops, and new changes cannot reach your fleet until the connection recovers, which is a different problem from an outage. Architectures that call the flag service on every evaluation behave very differently, so check which one you are running.
When should you choose a hosted feature flag service?
When your flag platform’s failures should be uncorrelated with your application’s, when nobody on the team wants to own another stateful service, and when no residency or air-gap rule forbids it. That covers most teams. The cases that genuinely point at self-hosting are specific and usually obvious: regulated data that cannot leave the perimeter, a network with no outbound path, or a procurement process that blocks new vendors outright.
Featureflip is a hosted feature flag platform with flat pricing, 13 official SDKs with local evaluation on the eight server ones, and streaming updates on every plan including the free one. Start free and see whether the hosted trade-off fits how your team works.