Rendered at 21:44:41 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
sgt 9 hours ago [-]
Had a look at their website [1]. Initial thoughts: this is a bit ridiculous, I can just build that myself. And in fact, I have done already.
Thoughts after about 3 minutes of browsing: OK, this actually makes sense and I see why people would pay for this. The value proposition is definitely there
Thanks, "I could build that" → "oh, that's what the other 90% is" is pretty much how Unleash started for us too. What does your homegrown version do? Always interested in where people draw the line between building and adopting.
sgt 2 hours ago [-]
Just basically various means of turning features on/off based on static rules. Settings mostly but occasionally user based or URL params.
Your platform has that and a ton of other things that would be useful for larger platforms, but it would be a pain to develop when you're already building a complicated roadmap.
kleiba2 7 hours ago [-]
Great comeback!
amelius 8 hours ago [-]
Hmm, after 5 minutes of browsing I still don't get it.
jascha_eng 8 hours ago [-]
[flagged]
brookst 8 hours ago [-]
It’s bad form to accuse people of being shills.
I haven’t used unleash but it’s pretty clear your characterization is wildly wrong. 30 seconds looking at docs shows it has features for gradual rollouts, A/B testing, experimentaion with analytics, authentication to control available features, and probably a lot more I missed in a quick skim.
soco 7 hours ago [-]
Which doesn't really explain why all the comments of the OP/author are flagged and dead... competition at work?
nozzlegear 3 hours ago [-]
HN auto-flags comments that look like they're generated by an LLM, and the author's flagged comments definitely have those telltale signs.
cfontes 7 hours ago [-]
I pay for it for my team... it's expensive to be honest, but worth it IMHO. Building it would be a ok, supporting it a pain.
If you work on a small startup, not worth it... on a Big corp with a lot of bureaucracy? It's worth it I think.
We have tried self-hosting it, but it's always a pain to allocate people on infra to do it, so I gave up and started paying for it for my teams, and they love it.
everforward 5 hours ago [-]
From the infra side, it’s something I don’t think makes a lot of sense to self-host. Metrics are the other notable one here.
They have non-linear scaling complexity, so they work fine with bumping up resources until they don’t and now you’re looking at queueing metrics on Kafka or something equally complicated. They’re horrible to change out because a lot of the APIs aren’t compatible and literally everything uses them.
They’re also awful to maintain. Everything uses them so there’s never a window when it’s convenient to shut down the feature flag system for upgrades or to test backup restores. People are much more accepting of “the vendor will be down for 2 hours on Saturday” than “I’m taking the system down for 2 hours on Saturday”.
hinkley 25 minutes ago [-]
The things I most disliked about our in house feature toggle system were:
1) the line between toggle and reloadable config is always fuzzy, in part because you don’t know for sure if it’s a toggle until users give their feedback. About half a percent of toggles stick around in perpetuity as either preferences or emergency relief valves for the operations team. That seems small but when you are doing CD aggressively that’s happening to you once a month or every few weeks which makes it a constant companion.
2) you need a system to track and complain about old toggles. If they survive the end of the Epic that birthed them, they become immortal. And you can see variations on Knight Capital play out when they get toggled years after they were supposed to be static.
hobofan 2 hours ago [-]
I'm not sure which provider you are paying for metrics, that you think has acceptable pricing.
We are on ~400k series, and switching to any hosted provider would instantly make that our single biggest infrastructure expense.
Instead we're self-hosting with less than $100/month for hosting and ~less than a hour per month of maintenance with Victoriametrics (have also switched fron singe-node to cluster over time), and it's a breeze.
hinkley 29 minutes ago [-]
Feels like something that should be a solved problem though.
Part of my last job was winnowing down a convoluted feature toggle system, rebuilding parts of it on top of a FOSS library that did a fraction of the same work. It had become convoluted enough though that it was materially affecting both our deployment time and our cluster density.
To be a little fair to the original author, despite not really respecting him, I had to file a couple serious PRs upstream to simplify the most tortured parts. He worked around a couple of bug/misfeatures but took the scenic route to do it. Guy “never met an abstraction he didn’t like” is not true because his favorite thing was replacing one abstraction with three. And he was one of those guys who learned big words all from books and so he used definitions nobody under 65 has ever used in conversation.
prmph 24 minutes ago [-]
I thought LLMs were supposed to be the death knell for services like this, since you could replicate them and maintain your own code-base with little effort?
At least that's what the AI boosters keep saying.
0x70dd 9 hours ago [-]
Yesterday I saw that LaunchDarkly is a $3B company. How crazy is that?!
notfried 9 hours ago [-]
A million monthly active users, even free ones, would cost you ~$10K/month on LaunchDarkly. A million sounds like a lot, but "active" can mean one visit, even anonymous users. ~$120K/year for feature flags is a ridiculous line item.
These SaaS companies are only valued this much because they charge based on MAUs, not request-based. I prefer PostHog's model. 100M requests/month is ~$2K [*].
[*] I'm not affiliated with PostHog.
ivarconr 7 hours ago [-]
On Unleash Cloud: 100M request per month on Unleash cloud would be $235 + 75$ per seat ($53 Million requests included).
skeeter2020 9 hours ago [-]
Launch Darkly charges on volume across multiple dimensions, including MAU and server-side connections, plus log, trace and error counts. It's bonkers and anyone who can actually predict what it will cost (good luck) will run away as fast as they can.
There is no way a Feature Flag system is a multi Billion dollar company based on the tech, and if there IS a Saas-pocalypse it's coming for players like LD first.
thephyber 4 hours ago [-]
This seems entirely too dismissive of what LaunchDarkly's service does.
pvo50555 8 hours ago [-]
What would you recommend as an alternative?
jhoward321 2 hours ago [-]
There are a number of providers that provide flat-rate or near flat-rate pricing in this space. I'll go ahead and recommend featureflip.io as one such example. ConfigCat is another common one.
I am affiliated with featureflip but it does a ton of the same things for a sane price.
ceuk 3 hours ago [-]
Posthog is absolutely awesome. Its free tier is insanely generous - 91% of its users don't pay anything or something.
We use it at a startup I'm involved in (~5k MAU) and we have never paid a penny which I am constantly surprised by since it's such a backbone for us.
paulryanrogers 7 hours ago [-]
Put flags in your own DB(s)?
figmert 6 hours ago [-]
Ex-LD engineer here. This was a classic mistake we saw most of our customers make, before they had to switch to LD or its competitors when they scaled a little bit more. Using a db is fine but can put heavy load on the server depending on the number of flags. In addition, it doesn't give you various features such as tagetting by users, segments, etc. Nor does it give you things like progressive rollout or automated rollback (yes we were using that in house and had saved us at least a few times).
I'm not advocating for LD, I'm advocating for any feature management system.
deathanatos 4 hours ago [-]
I've designed such a "classic mistake".
> In addition, it doesn't give you various features such as tagetting by users, segments, etc. Nor does it give you things like progressive rollout or automated rollback (yes we were using that in house and had saved us at least a few times).
These are things you can think of quite easily, or you just survey the landscape of what challenges other implementations run into and they inform you of this. The first iteration of our design had all of those; we could target users, always-subscribe internal users, we could have two features have the same segment/ordering of rollout, etc.
Database load wasn't ever a problem, because you're talking about quite literally a single SELECT on an already established & otherwise in use DB connection. But caching is not that much to bolt on afterwards should it become an issue.
It's never been clear to me that the simplicity of understanding that a single query has, even if it might be short a few features, is outweighed by the complexity of a full dependency to an external service.
As it was, our FF system outlived the company, and was sunset when the company ended.
efficax 3 hours ago [-]
Eh, I built a feature flagging system for service with millions of daily active users and it: wasn't hard to do, was easy to extend to support targeting, segments, and progressive rollout, and on top of it flags are easy to cache, so the database pressure was not that big. We did this long before LLMs, and it occupied maybe a month of engineering time for me, here and there as we needed new features, while I was doing other things. We did choose the wrong hash for bucketing in the beginning, but we noticed the stairstep patterns in our buckets quickly (an advantage of having millions of requests per day to measure) and picked a better one. It was much better this way since it meant backend flags without a roundtrip to a 3rd party service (that was the main motivation, we wanted this kind of control without adding latency to our requests). I remain baffled by launch darkly or other such services. And today, with LLMs, just build it yourself is hard to argue against.
figmert 14 minutes ago [-]
As I mentioned, I'm not advocating for LD. I'm advocating for feature management systems (over env vars/db values and other similar naive implementations). The build vs buy is a separate argument.
> that was the main motivation, we wanted this kind of control without adding latency to our requests
Right, and most, if not all, off the shelf feature management systems have this problem solved already. For example LD uses a streaming architecture by default to push out flags to your application within 200ms, for client facing applications (android/ios/web), flags were retrieved once on load from a CDN, keeping the rest of your application snappy. I believe Unleash also has some sort of streaming architecture.
efficax 5 minutes ago [-]
this was almost a decade ago, the options were imo pretty bad
illamint 7 hours ago [-]
What if your DB is down?
mportela 6 hours ago [-]
Wouldn't you be having bigger problems if the DB is down (especially if you have good defaults for the flags)?
thephyber 4 hours ago [-]
My website company 20 years ago was running Memcached keys for each of the feature flags so they only had to be loaded about once per session from the DB most of the time.
Scaling things like this is a mostly solved problem. Having your website load when the DB is down is not.
the_fury 6 hours ago [-]
Have a safe default fallback.
LollipopYakuza 7 hours ago [-]
Unleash Cloud ?
thomaspoignant 6 hours ago [-]
[flagged]
ivarconr 8 hours ago [-]
Biased answer since I work on Unleash, but the pricing point is something we thought about deliberately:
- Self-hosted open source is free, with no usage limits. Run it on your own Postgres and you pay for a small VM.
- Paid plans are priced per seat (people using the admin UI), not per end user or per request. One million MAUs or a hundred million costs the same (we have some protection for high traffic volumes)
- Server-side SDKs evaluate locally, so a flag check never hits our servers and there's nothing to meter. Frontend traffic goes through Edge, which you can also self-host.
If you'd rather not lock into any vendor, put flags behind OpenFeature. Unleash, Flagsmith, GrowthBook and others all have providers, so switching later is a config change, not a rewrite.
Same features as all these big guys, EU hosted, and down-to-earth pricing. Even the free tier got me quite far.
I'm unaffiliated btw.
ivarconr 44 minutes ago [-]
The ConfigCat team is great!
Unleash also originates from Europe.
gib444 4 hours ago [-]
A file syncing app "that could be an FTP server or USB stick" is over double that ;)
7 hours ago [-]
jonhohle 8 hours ago [-]
Are most feature flag systems really just simple Boolean checks like this with no feedback loop? In 2009 Amazon’s equivalent supported multi-variate flags (run test with more than 2 options), a feedback loop for performance/attribution, and
weighting. I don’t see any of that on the unleash home page, but also haven’t seen it in other feature config systems either.
hobofan 8 hours ago [-]
What you are describing is usually part of analytics platforms (Mixpanel, etc.). A feature flag toggle only plays a small part in this (but it may also be used for a lot of other scenarios of how you may want to control feature flags).
Audience is decided by analytics tool -> Feature flag server maps audience to feature flag value -> Analytics tool tracks its events and includes feature flag value as attribute
jonhohle 7 hours ago [-]
So if you want to slowly roll out a feature flag, you need to get a different app involved that can do everything the feature flag tool can do and a whole lot more? What’s the point of the feature flag tool?
Analytics is a much broader set of tooling. It can (and should) report similar things.
hobofan 6 hours ago [-]
The point of the feature flag tool is to control feature flags. They are not just for A/B testing and slow rollouts, and most products are not on the scale of Amazon, where you need to have a feedback loop for the rollout. Of course there is always going to be some overlap between tools, where many analytics platform allow you to do the rudimentary version of this.
The main point of a FF system is that you have a runtime-controllable mapping from user attributes to feature flags, where a set of logic rules can dictate who is exposed to what feature. With most analytics-tool based rollouts, you would be able to only directly set an attribute and you then hard-wire that attribute to the feature toggle in app code, which gives you a lot less flexibility and always requires a engineer in the hot path when it comes to doing rollouts.
horticulturist 8 hours ago [-]
usually some “data science” team takes the results and decides what to do. really heavy process for something that is usually quite simple.
wmichelin 8 hours ago [-]
We have automatically generated readouts that run hourly and daily, show metrics between control and variant across a ton of core business metrics, and we can even opt into measurement of some super esoteric stuff.
Granted we have a whole team supporting just that experimentation platform, but it's pretty cool. They even expose an MCP server for us to have agents do experiment analysis for us using.
jonhohle 7 hours ago [-]
Attributing an event to a flag is a heavy process? Oof.
ivarconr 8 hours ago [-]
[flagged]
hmokiguess 7 hours ago [-]
This domain needs some better ontology and taxonomy, there's so many overlapping and conflated terms whenever I hear about it. To name a few:
- Feature Flags used as Configs;
- Configs used as Feature Flags;
- Live Ops, Control Groups, Experiments, Analytics, and more bundled as "extras" to Feature Flags as if they were the right parent term;
I think classical systems/engineering see feature flags as boolean state in some data store, but these PaaS are pushing it as a new thing and struggling with marketing.
I wish they took the gaming companies lesson and started using the term "Live Ops"
Oh wow I didn't know about this one, thanks for sharing! Great read
kalcode 7 hours ago [-]
To me there two type of feature flag. For tech and not for tech.
If you have good CI/CD practices, an ENV for the environment has what feature is simplest. No new dependencies, change code commit deploy.
Non-tech folks need something else that allows them to switch it on and then off. For a variety of reasons.
figmert 6 hours ago [-]
Ex-LaunchDarkly engineer here.
Feature management goes well beyond an env var. Sure an env var change is fine on it's own, but a change of the feature flag (essentially a release) requires a deployment.
Feature management separates these two. You can deploy without releasing. Because the code is there, but dormant behind an if that can change at runtime, you can actually target users, segments, or even do progressive rollout, and so much more. What this also means is you can test your changes in production without causing prod to go down. Best of all, a release doesn't mean a bad deployment.
It's not just about non-tech folks. It separates deploy and release in the SDLC, and that opens up a whole new world.
ctkhn 7 hours ago [-]
We had a weird constellation of these things at a previous job of mine. In addition to our env variables, we had a config table for more business-side stuff (ie percent of margin to include in bids and quotes for work on the platform) that our business team would upload new values to on our admin GUI with a CSV file, and eventually we jammed into that same table a config check that would enable features just for certain users by email. I was very happy when we eventually moved to Launchdarkly and tossed out the hacky stuff.
VulgarExigency 6 hours ago [-]
This seems a bit reductive. What if you want to do a progressive rollout of the feature? What if it has a problem, and you want to disable it without needing to redeploy across multiple regions? What if you want to A/B test it?
yearesadpeople 40 minutes ago [-]
I mean, well done. It's impressive work to provide such a service, that a surprising number of mid-to-large organisations _will_ seek out _and_ leverage. Quite a throwback this really, like the heyday of the SaaS hype; almost quaint. Thank you for an enjoyable read
ivarconr 32 minutes ago [-]
I will take quaint. We started it as a sideproject in 2014, so the throwback argument is fair. What i find fascinating is the ability to runtime control featurs in production, particularly the ability to kill it, seems more important than ever these days, where AI has made it pretty cheap to produce software.
linesofcode 7 hours ago [-]
Cool! Feature flags are great when you need them. I’ve seen so many different implementations of flags over the years. Even made one myself couple years ago which uses a GitHub issue (and a list of checkboxes) as a persistent store for maintaining and toggling with flags. https://github.com/TimMikeladze/next-flag
You can hardly compare an API specification with an implementing product. So, no, even if Unleash does implement OpenFeature.
sureglymop 4 hours ago [-]
Cool product!
This seem to be open source and self hostable (is it AGPL licensed?).
Can I, for personal use, fully self host every component? Or is it open core and e.g. multi tenancy isn't there etc.
Fidelix 3 hours ago [-]
open core. Almost useless in the free license
ivarconr 4 hours ago [-]
Yes, AGPL. And yes, it’s open core. For personal use you can self-host the server and SDKs with no usage limits, and that covers flags, targeting, gradual rollouts and variants. The paid tiers add things that mostly matter to larger teams: SSO, RBAC, change requests, and Edge for high-volume frontend traffic. For a personal setup, the open source version should be all you need.
(Of course it's fine to use AI tools! We use them heavily ourselves. Just please don't use them to generate or edit text to be read by fellow humans on Hacker News.)
It's impossible to know for sure what was LLM generated or edited, but we have to rely on imperfect classifiers or else the site would be completely flooded by genai text, which is not what the community here wants to read, nor in the intended spirit of HN.
ivarconr 49 minutes ago [-]
Got it, thanks. AI was used to clean up the language, not to generate content.
sureglymop 3 hours ago [-]
Thanks for clarifying and good luck with this endeavour!
Fidelix 3 hours ago [-]
From the website.
```
Yes. Unleash Open Source is free, self-hosted, and has no limit on seats. It covers the core feature set, with a limit of 1 project, 2 environments, and 5,000 feature flags per instance. Thousands of teams run it in production.
It does not include single sign-on, SCIM provisioning, granular role-based access control, change request approvals...
```
1 project, 2 environments. Laughable.
joaohaas 7 hours ago [-]
Literally all their examples can be replaced by some sort of:
if redis_client.get("staging.feature-flag"):
...
For frontend you add an endpoint that exposes this value.
I guess their frontend for managing these is 'nice', but at the end of the day it's a static page that sets flags on redis.
matsemann 7 hours ago [-]
The flags are often not static, though. Varies between environments, markets, user cohorts and whatever rules you can come up with.
dolmen 6 hours ago [-]
So plenty of parameters that could be exposed in Redis as well. No?
stackghost 7 hours ago [-]
What else do you need for feature flags?
ivarconr 5 hours ago [-]
For one app and one team, honestly not much. It starts to matter when you want gradual rollouts where the same user stays in or out across services, different rules per environment or customer, an audit log of who flipped what when something breaks, and a way to find dead flags. And then the boring parts: not doing a network call on every check, and what happens when the store is down.
yuppiepuppie 10 hours ago [-]
Configuration as a Service companies must be a having a tough time these days...
I couldnt imagine a lot of teams are debating anymore whether to build their own or use an off the shelf product like this. The former being a straight forward task for an LLM. And the latter being a point of failure/attack for any one want to mess with the core foundations of a product.
FinnKuhn 9 hours ago [-]
Companies as well as people are still happy to pay for the second S in SaaS.
Building something, updating it, running it, testing etc. still requires resources and attention. One example for this would be taxis. You pay for the comfort of not having to drive the car, do maintenance, take into account road works, cleaning, etc. and not because you couldn't drive a car yourself. That time you can use instead to focus on your actual business.
chanhyounglee 5 hours ago [-]
I build a B2B SaaS. I ran the same PDF through my product and a general-purpose AI. Both had zero number errors, and the AI's design was good enough. So I don't expect people to pay for the output. I think what's left is what happens after: who opened it, inquiries, spec changes, and team collaboration.
leetrout 9 hours ago [-]
At a certain scale (probably bimodal distribution) it makes sense to have a provider you can shrug it off to and point the finger to when things are missing features or the system goes down, etc etc. On the big-co end of that spectrum I think you are right and AI makes this stuff easy to launch internally.
The owner at my current gig has multiple times said "software is over" as it being a sort of gravy train of rent seeking. Products are gonna have to offer real / significant value to attract new customers. Maybe even to keep them, too...
skeeter2020 9 hours ago [-]
>> and point the finger to when things are missing features or the system goes down
This sounds good in theory but - and I speak from experience with a FF system causing a system-wide outage - clients don't care why YOU had an outage, or that it's not immediately your fault, and they really shouldn't have to. The reality is more like you're paying for a dependecy that you can't mitigate.
hobofan 7 hours ago [-]
Being able to point fingers is also a moot point from a theoretical perspective.
Given that every FF system comes with a bunch of different mechanisms that prevent your system from being catastrophically impacted in case the provider goes down, its still the fault of the integrating party if you experience an outage due to a FF provider.
gerardnico 9 hours ago [-]
You miss where the value of software is nowadays.
Just the hosting of this thing is worse to pay for.
higeorge13 9 hours ago [-]
Analytics, documentation, configuration, etc saas companies must be having the same hard time.
anonymous908213 9 hours ago [-]
> Release, experiment, and kill anything AI ships
The only appealing marketing I've seen in the past three years
ivarconr 8 hours ago [-]
[dead]
ltbarcly3 7 hours ago [-]
Wow a server that can help you manage your booleans. That's so useful. Let me just add one more thing to my infrastructure so my list of booleans can be managed.
4lx87 4 hours ago [-]
We are an unserious industry run by idiots and grifters. We deserve to be replaced by AI. AI isn't going to purchase a SaaS to store a fucking boolean.
My company has used 3 different feature flag services in 5 years, spent thousands of dollars, with multiple migrations and teams of engineers involved. All to basically implement `SELECT 1 FROM feature_flags WHERE team_id = ?`. Makes me want to blow my brains out.
konfusinomicon 6 hours ago [-]
managed in the sense that values keep getting thrown onto the pile and then people somehow manage to never think about or touch them ever again regardless of their temporary nature
ivarconr 5 hours ago [-]
This is the real problem in my experience. Creating flags is easy, removing them isn’t. We ended up building lifecycle tracking for it: each flag type has an expected lifetime, flags get marked potentially stale when they pass it, and you can see when a flag was last evaluated in each environment so you know it’s safe to delete. Someone still has to remove the code though :)
ltbarcly3 2 hours ago [-]
No, it gives you one pretty heavy way to not throw things into a pile. It doesn't keep people from making a mess anyway.
If you have the discipline to use this thing, you have the discipline to manage things yourself without this thing.
selinajing1001 6 hours ago [-]
open-source = FIRE
sneak 7 hours ago [-]
“open source” but it’s the nonfree AGPL, and naturally RBAC and SSO are behind a paywall. I’m tired of fake open source projects that just want the street cred and free marketing.
kleiba2 7 hours ago [-]
AGPL is as free as it gets. Perhaps the word you're looking for is non-permissive?
sneak 7 hours ago [-]
Don’t believe the hype. AGPL violates free software freedoms 0 and 1. It was designed by people who think that receiving a free gift confers obligation to reciprocate.
AGPL does not require you to share your changes if you use it (like most people) internally. It does if you host it for others as a service. Pretty fair trade.
Freedom to use, modify and distribute, clearly enforced for the Internet age.
sneak 5 hours ago [-]
> AGPL does not require you to share your changes if you use it (like most people) internally.
The text of the AGP License does not support this claim.
thunderfork 4 hours ago [-]
A lot of the arguments in this second link fall flat (e.g. "ohh you're violating the license if you npm run on your dev machine!") and it'd be more convincing if it spent less time trying to nitpick nonsense like that and just stuck to the moral argument it's trying to make
Fidelix 3 hours ago [-]
[flagged]
ivarconr 10 hours ago [-]
Hi HN, I'm Ivar, creator of Unleash.
Unleash started in 2014 as an internal tool at my company at the time, because we wanted to ship to production continuously without big-bang releases. It's an Open-Source feature flag platform with SDKs for >25 languages.
A few design choices that might be interesting:
- Local evaluation: server-side SDKs fetch the flag config and evaluate in-process, so user data never leaves your app and a flag check is a memory lookup, not a network call.
- Shared Rust engine (Yggdrasil): the evaluation logic is written once in Rust and embedded in the SDKs, so behaviour is the same across languages.
- Unleash Edge: a Rust proxy/cache for frontend and edge clients at scale. (Commercial)
- OpenFeature: supported if you don't want to lock into our SDKs.
icecrime 4 minutes ago [-]
We were happy customers with my startup (before we died).
Unleash does a lot more than it seems on first look. It helped us a ton as we were shooting in all directions searching for pmf.
gegtik 7 hours ago [-]
I can see using something mature if you are starting from scratch.
if you already are in a platform capture situation, eg. Azure App Configuration or AWS AppConfig where you already integrate with platform tools using the native auth primitives, what is the benefit one can expect from switching to unleash?
ivarconr 55 minutes ago [-]
If your current platform support (AppConfig etc) is sufficient, you should probably keep using it.
We see teams move when they have more complicated needs, either in terms of compliance, 4-eyes approvals, scalability and lifecycle tracking.
Anything you’re missing today, or is it working fine?
Thoughts after about 3 minutes of browsing: OK, this actually makes sense and I see why people would pay for this. The value proposition is definitely there
[1] https://www.getunleash.io/
Your platform has that and a ton of other things that would be useful for larger platforms, but it would be a pain to develop when you're already building a complicated roadmap.
I haven’t used unleash but it’s pretty clear your characterization is wildly wrong. 30 seconds looking at docs shows it has features for gradual rollouts, A/B testing, experimentaion with analytics, authentication to control available features, and probably a lot more I missed in a quick skim.
If you work on a small startup, not worth it... on a Big corp with a lot of bureaucracy? It's worth it I think.
We have tried self-hosting it, but it's always a pain to allocate people on infra to do it, so I gave up and started paying for it for my teams, and they love it.
They have non-linear scaling complexity, so they work fine with bumping up resources until they don’t and now you’re looking at queueing metrics on Kafka or something equally complicated. They’re horrible to change out because a lot of the APIs aren’t compatible and literally everything uses them.
They’re also awful to maintain. Everything uses them so there’s never a window when it’s convenient to shut down the feature flag system for upgrades or to test backup restores. People are much more accepting of “the vendor will be down for 2 hours on Saturday” than “I’m taking the system down for 2 hours on Saturday”.
1) the line between toggle and reloadable config is always fuzzy, in part because you don’t know for sure if it’s a toggle until users give their feedback. About half a percent of toggles stick around in perpetuity as either preferences or emergency relief valves for the operations team. That seems small but when you are doing CD aggressively that’s happening to you once a month or every few weeks which makes it a constant companion.
2) you need a system to track and complain about old toggles. If they survive the end of the Epic that birthed them, they become immortal. And you can see variations on Knight Capital play out when they get toggled years after they were supposed to be static.
We are on ~400k series, and switching to any hosted provider would instantly make that our single biggest infrastructure expense.
Instead we're self-hosting with less than $100/month for hosting and ~less than a hour per month of maintenance with Victoriametrics (have also switched fron singe-node to cluster over time), and it's a breeze.
Part of my last job was winnowing down a convoluted feature toggle system, rebuilding parts of it on top of a FOSS library that did a fraction of the same work. It had become convoluted enough though that it was materially affecting both our deployment time and our cluster density.
To be a little fair to the original author, despite not really respecting him, I had to file a couple serious PRs upstream to simplify the most tortured parts. He worked around a couple of bug/misfeatures but took the scenic route to do it. Guy “never met an abstraction he didn’t like” is not true because his favorite thing was replacing one abstraction with three. And he was one of those guys who learned big words all from books and so he used definitions nobody under 65 has ever used in conversation.
At least that's what the AI boosters keep saying.
These SaaS companies are only valued this much because they charge based on MAUs, not request-based. I prefer PostHog's model. 100M requests/month is ~$2K [*].
[*] I'm not affiliated with PostHog.
There is no way a Feature Flag system is a multi Billion dollar company based on the tech, and if there IS a Saas-pocalypse it's coming for players like LD first.
I am affiliated with featureflip but it does a ton of the same things for a sane price.
We use it at a startup I'm involved in (~5k MAU) and we have never paid a penny which I am constantly surprised by since it's such a backbone for us.
I'm not advocating for LD, I'm advocating for any feature management system.
> In addition, it doesn't give you various features such as tagetting by users, segments, etc. Nor does it give you things like progressive rollout or automated rollback (yes we were using that in house and had saved us at least a few times).
These are things you can think of quite easily, or you just survey the landscape of what challenges other implementations run into and they inform you of this. The first iteration of our design had all of those; we could target users, always-subscribe internal users, we could have two features have the same segment/ordering of rollout, etc.
Database load wasn't ever a problem, because you're talking about quite literally a single SELECT on an already established & otherwise in use DB connection. But caching is not that much to bolt on afterwards should it become an issue.
It's never been clear to me that the simplicity of understanding that a single query has, even if it might be short a few features, is outweighed by the complexity of a full dependency to an external service.
As it was, our FF system outlived the company, and was sunset when the company ended.
> that was the main motivation, we wanted this kind of control without adding latency to our requests
Right, and most, if not all, off the shelf feature management systems have this problem solved already. For example LD uses a streaming architecture by default to push out flags to your application within 200ms, for client facing applications (android/ios/web), flags were retrieved once on load from a CDN, keeping the rest of your application snappy. I believe Unleash also has some sort of streaming architecture.
Scaling things like this is a mostly solved problem. Having your website load when the DB is down is not.
- Self-hosted open source is free, with no usage limits. Run it on your own Postgres and you pay for a small VM.
- Paid plans are priced per seat (people using the admin UI), not per end user or per request. One million MAUs or a hundred million costs the same (we have some protection for high traffic volumes)
- Server-side SDKs evaluate locally, so a flag check never hits our servers and there's nothing to meter. Frontend traffic goes through Edge, which you can also self-host.
If you'd rather not lock into any vendor, put flags behind OpenFeature. Unleash, Flagsmith, GrowthBook and others all have providers, so switching later is a config change, not a rewrite.
Same features as all these big guys, EU hosted, and down-to-earth pricing. Even the free tier got me quite far.
I'm unaffiliated btw.
Unleash also originates from Europe.
Audience is decided by analytics tool -> Feature flag server maps audience to feature flag value -> Analytics tool tracks its events and includes feature flag value as attribute
Analytics is a much broader set of tooling. It can (and should) report similar things.
The main point of a FF system is that you have a runtime-controllable mapping from user attributes to feature flags, where a set of logic rules can dictate who is exposed to what feature. With most analytics-tool based rollouts, you would be able to only directly set an attribute and you then hard-wire that attribute to the feature toggle in app code, which gives you a lot less flexibility and always requires a engineer in the hot path when it comes to doing rollouts.
Granted we have a whole team supporting just that experimentation platform, but it's pretty cool. They even expose an MCP server for us to have agents do experiment analysis for us using.
- Feature Flags used as Configs;
- Configs used as Feature Flags;
- Live Ops, Control Groups, Experiments, Analytics, and more bundled as "extras" to Feature Flags as if they were the right parent term;
I think classical systems/engineering see feature flags as boolean state in some data store, but these PaaS are pushing it as a new thing and struggling with marketing.
I wish they took the gaming companies lesson and started using the term "Live Ops"
If you have good CI/CD practices, an ENV for the environment has what feature is simplest. No new dependencies, change code commit deploy.
Non-tech folks need something else that allows them to switch it on and then off. For a variety of reasons.
Feature management goes well beyond an env var. Sure an env var change is fine on it's own, but a change of the feature flag (essentially a release) requires a deployment.
Feature management separates these two. You can deploy without releasing. Because the code is there, but dormant behind an if that can change at runtime, you can actually target users, segments, or even do progressive rollout, and so much more. What this also means is you can test your changes in production without causing prod to go down. Best of all, a release doesn't mean a bad deployment.
It's not just about non-tech folks. It separates deploy and release in the SDLC, and that opens up a whole new world.
This seem to be open source and self hostable (is it AGPL licensed?).
Can I, for personal use, fully self host every component? Or is it open core and e.g. multi tenancy isn't there etc.
(Of course it's fine to use AI tools! We use them heavily ourselves. Just please don't use them to generate or edit text to be read by fellow humans on Hacker News.)
It's impossible to know for sure what was LLM generated or edited, but we have to rely on imperfect classifiers or else the site would be completely flooded by genai text, which is not what the community here wants to read, nor in the intended spirit of HN.
It does not include single sign-on, SCIM provisioning, granular role-based access control, change request approvals... ```
1 project, 2 environments. Laughable.
I guess their frontend for managing these is 'nice', but at the end of the day it's a static page that sets flags on redis.
I couldnt imagine a lot of teams are debating anymore whether to build their own or use an off the shelf product like this. The former being a straight forward task for an LLM. And the latter being a point of failure/attack for any one want to mess with the core foundations of a product.
Building something, updating it, running it, testing etc. still requires resources and attention. One example for this would be taxis. You pay for the comfort of not having to drive the car, do maintenance, take into account road works, cleaning, etc. and not because you couldn't drive a car yourself. That time you can use instead to focus on your actual business.
The owner at my current gig has multiple times said "software is over" as it being a sort of gravy train of rent seeking. Products are gonna have to offer real / significant value to attract new customers. Maybe even to keep them, too...
This sounds good in theory but - and I speak from experience with a FF system causing a system-wide outage - clients don't care why YOU had an outage, or that it's not immediately your fault, and they really shouldn't have to. The reality is more like you're paying for a dependecy that you can't mitigate.
Given that every FF system comes with a bunch of different mechanisms that prevent your system from being catastrophically impacted in case the provider goes down, its still the fault of the integrating party if you experience an outage due to a FF provider.
The only appealing marketing I've seen in the past three years
My company has used 3 different feature flag services in 5 years, spent thousands of dollars, with multiple migrations and teams of engineers involved. All to basically implement `SELECT 1 FROM feature_flags WHERE team_id = ?`. Makes me want to blow my brains out.
If you have the discipline to use this thing, you have the discipline to manage things yourself without this thing.
https://en.wikipedia.org/wiki/The_Free_Software_Definition
https://sneak.berlin/20250720/the-agpl-is-nonfree/
AGPL does not require you to share your changes if you use it (like most people) internally. It does if you host it for others as a service. Pretty fair trade.
Freedom to use, modify and distribute, clearly enforced for the Internet age.
The text of the AGP License does not support this claim.
Unleash started in 2014 as an internal tool at my company at the time, because we wanted to ship to production continuously without big-bang releases. It's an Open-Source feature flag platform with SDKs for >25 languages.
A few design choices that might be interesting:
- Local evaluation: server-side SDKs fetch the flag config and evaluate in-process, so user data never leaves your app and a flag check is a memory lookup, not a network call.
- Shared Rust engine (Yggdrasil): the evaluation logic is written once in Rust and embedded in the SDKs, so behaviour is the same across languages.
- Unleash Edge: a Rust proxy/cache for frontend and edge clients at scale. (Commercial)
- OpenFeature: supported if you don't want to lock into our SDKs.
Unleash does a lot more than it seems on first look. It helped us a ton as we were shooting in all directions searching for pmf.
if you already are in a platform capture situation, eg. Azure App Configuration or AWS AppConfig where you already integrate with platform tools using the native auth primitives, what is the benefit one can expect from switching to unleash?
We see teams move when they have more complicated needs, either in terms of compliance, 4-eyes approvals, scalability and lifecycle tracking.
Anything you’re missing today, or is it working fine?