Never underestimate the power of a zero-network-hop abstraction over f(feature_name, context).
And context can be extremely tailored to your niche: specific inventory, from a specific supplier, for a specific user of a specific B2B client of a specific business model subtype, who should or shouldn’t see certain features on that specific inventory at certain times.
When you can write your own logic, and just run this in a tight loop as easily and performantly as you can use a constant, it makes your business incredibly agile. Think some text might change for some customers? Just write the code to make it configurable, and you get tests and flags for free.
Sadly, that zero-hop setup requires a sophisticated client execution engine, which it doesn’t appear Cloudflare has implemented here. Makes sense for their memory constrained workers, less sense for traditional infrastructure.
Statsig has an approach here that I quite like:
> To be able to do this, Server SDKs hold the entire ruleset of your project in memory - a representation of each gate or experiment in JSON. On client SDKs, we evaluate all of the gates/experiments when you call initialize - on our servers.
You can also roll your own - just sync your rulesets to a few data structures every few seconds in a background thread and atomically swap the reference to them. Then you just need a CRUD interface over the applicability ruleset dimensions.
Just be careful to have governance on who can play with which would-be constants. Great power and great responsibility and all that!
When reading your comment, it just reminds me on how feature flags can be misused as application configuration/customization. An antipattern i could observe at various organzations already.
For me feature flags go along with trunk based development to enable features in QA settings, but not on PROD yet, for PO/PM testing. Trunk based development allows for fast/easy devops, without complicated branching strategies.
Application configuration is, for me, part of the application and has the business context for customizing the application accordingly. Not sure if there are specific frameworks/tools out there. But one should clearly distinguish these two.
> it just reminds me on how feature flags can be misused as application configuration/customization. An antipattern i could observe at various organzations already.
feature flags are perfect for configuration and customization, why using them for this purpose is 'misuse' is beyond me and I've heard this claim from multiple people. they're literally configuration. feature with a flag to turn it on, off or give the flag a value. where's the misuse? is it a problem I'm not running experiments when switching over redis to valkey or whatever?
Feature flags need to be treated as short-lived and experimental otherwise they end up getting abused for everything and make it very difficult to reason about your application.
If it's config/customization, it should be in code. If it's experimental it can be a flag until it solidifies, and then it needs to get moved to code.
When I was at Shopify a couple of years ago they mandated that feature flags had to be short-lived (Like 2-4w lifetime tops, some had exceptions) because they would end up getting left in code and never cleaned up, or for extended periods of time like months. Hard to tell if it's genuinely a "feature flag" or actually just a normal part of the system at that point.
Feature flags being flipped in prod was also a major source of incidents, in part because people didn't treat them as experimental and with the associated risk profile of something experimental.
The only exception where having long-lived flags was useful and required was for operational killswitches (E.g. disable Apple Pay because it's having issues), but that is explicitly not application config.
This is the kind of design wisdom that’s both true and difficult to win an argument over.
It reminds me of arguments related to over-engineering and complexity. The principles are super important to having a codebase that scales and continues to be efficient to work in as the team grows, but they are hard to objectively measure.
Locally or in isolation something may sound like a great idea. Being able to step back and see the greater ripple effects require some experience and intuition that can’t always be used to convince people otherwise.
I disagree with just about everything you said being a problem except the process of cleaning up is absolutely required.
Notably feature flags triggering incidents is expected and desired vs the alternative of shipping the code and having to roll a release back because there is no other way to remove the feature from prod.
In a company the size of Shopify people flipping their feature flags would very often impact *other teams*, and like I said feature flags got abused with even seemingly innocuous changes being put behind them or being left long periods of time before being fully used.
When someone else flips a flag that impacts your team and they have no idea they even caused a problem, it becomes very difficult to resolve the issue. Usually you can check for recent deploys, instead you have to go and guess at which feature flag which was recently flipped could possibly be affecting your code. I experienced this several times.
Also, it was actually more desirable for most of these things to go straight to production. Test it properly before shipping, then when you ship it soaks on a 5% traffic canary at which point you can monitor and cancel the deploy if you see errors. That is generally safer than a feature flag rollout unless you are doing something very high impact/risk, in large part because it gives any other team affected by your rollout the ability to respond and be able to easily find the source of errors.
In my org it was a fairly common failure mode to ship something and accidentally cause an issue for another team. Usually it was other teams/orgs shipping things that impacted us.
Runtime evaluated feature flags can always be used for control plane levers and emergency handbrakes.
You just have to label them as such and prevent other teams from fiddling with them.
This is not an antipattern, it's just semantic hand-wringing.
My team managed critical systems in the online flow of billions of dollars of daily payment volume. We also wrote the feature flag system that the rest of the company used. Not only were we completely fine with feature flags as long-lived control plane levers, we heavily used the system that way ourselves.
You just have to clearly distinguish between ephemeral rollout flags (and clean them up or expire them) and the permanent control plane levers.
It's the exact same functionality for both sets of tools. Just different practices around the two usages.
I completely agree with your distinction and that is exactly what they mandated :)
I don't think that is what most people colloquially mean by "feature flags" though. Even most teams in Shopify abused "ephemeral" flags for long periods of time.
When they rolled out the mandate it was very annoying for my team because we had a lot of operational flags like you're describing that we needed to get exemptions for.
One well known issue is that when you have a lot of separate feature flags that can interact, you explode the number of test cases you have to cover. For example if you have three feature flags that can interact in a module that has 100 test cases, you actually have 900 test cases if you are going to test with each possible combination of flags. Many teams don't test them all because they "already know" that doesn't apply here, and find out in production which combination of feature flags is unworkable.
But you have this same issue if you store those 3 bits of state as "app config" instead of as "feature flags".
I think it's useful to distinguish between kinds of feature flags -- "traditional" feature flags for safe rollout of new features (these should be removed on a strict timeline, to preserve maintainability) vs. "config"-type flags that are designed to remain indefinitely and optionally be configurable by certain end users. But I don't yet see a reason why the actual mechanism for these two things (namely, a function with a descriptive name that can be called to quickly return a small datum that is periodically refreshed from somewhere in the background) can't be the same.
Yes people are speaking past each other to some extent here; but if we're going to talk about "Feature Flags" we aren't talking about using a flag service for "normal" configuration - whatever that means. But what, exactly - does that mean? I normally consider things like the following configuration:
API Host Names, client Ids, secrets,
Database connection strings
Other runtime settings like pool sizes, replica counts etc
Most of those things are secrets, or they are specific scalar values closely tied to the application runtime, that often need to be known at startup. Are people putting those in a "feature flag" service? If not, what is a good example?
My comment only applies to "configuration" that alters behavior, usually in binary off/on manner. Which is what I'd call a "Feature Flag".
Yes, feature flags are conflated with remote configs (or its more useful variety: "dynamic configs"). The difference is subtle, hence why people are talking past each other.
Feature flags are gates for whether a piece of code runs; basically, an if-condition. Remote configs are a mechanism for changing runtime values without redeploying[1].
For example:
# Feature flag — variant gate for rollout
flag = sdk.check_gate(user, "checkout_flow")
if flag == 'open':
render_new_checkout()
elif flag == 'warning':
render_warning_checkout()
else:
render_old_checkout()
# Raw remote config pulled — structured values for tuning behavior
config = sdk.get_config(user, "checkout_settings") # if the config changes based on user or context, this "remote" config is considered "dynamic"
timeout_ms = config.get("timeout_ms", 5000)
max_items = config.get("max_items", 50)
allowed_tlds = config.get("allowed_tlds", [".com", ".org"])
In practice, feature flags are implemented on top of dynamic configs[2] to manage the temporary lifecycle of a feature — aka, ship a new block of code, ramp its execution up to 100%, then delete the flag. Whereas dynamic configs are a deeper primitive meant for semi-permanent/safer operations like tuning rate limits or changing text copy on a marketing website.
As I've seen it: the forcing function that separates the concepts are experimentation platforms: when human-control of feature flags is shared (via dynamic configs) with automated & randomized assignments. That's how Statsig built their system and, in part, why they could sell for a billion. Whereas companies that ignored the difference, like LaunchDarkly, struggled outside of feature flags.
I think feature flags, remote configs, and experiments are all the same thing. Semantically they differ in how you're applying the config and interpreting the outcomes.
That's not a feature flagging service then (config as a service! not a thing really...)
I've done both client and server side implementations of the launch darkly sdk and that's how it's done to know client context.
If you're initialising the entire SDK only to load 1 set of configuration items, I'd argue you can host the config as a json file on a CDN and be done with it - feature flagging is overkill.
Which is not hard to do (it is a modulo over a mersenne twister or something similar), but in my recent gigs just Flipper with optional "state of the flags table as of now" endpoint was more than enough. That modulo+random combo required tools like LaunchDarkly to ship SDKs in several languages, and the ones I had to work with were just plain horrible fit for their language of choice. But because the evaluation was relegated to the edge, the whole system got way more complex than desirable. In actuality, I think a refetch of the current flags table "for this customer" every so often is just fine, and way less of a nuisance.
So glad Flipper exists and I don't have to deal with this stuff anymore.
> Sadly, that zero-hop setup requires a sophisticated client execution engine, which it doesn’t appear Cloudflare has implemented here.
It doesn't have to be sophisticated and they don't need to implement it themselves. They piggy-back on OpenFeature where the client libraries have a simple targeting rule evaluation engine integrated.
But why would you wrap some proprietary solution around your neck instead of rolling your own custom solution or extending some open source?
The answer for most things pertaining to encloudification seems to be "because it's easy and we are already using cloud provider X". Death by a thousand clickops.
Good advice. I'll add a protip / reminder that feature flags, AB tests, and entitlements are three distinct concepts. This blog post (no affiliation) has framing I found helpful:
Statsig is a half-baked product bought out by OpenAI for data harvesting. We already reported 2 documentation issues and 1 critical technical issue, and we're barely using it.
> Sadly, that zero-hop setup requires a sophisticated client execution engine, which it doesn’t appear Cloudflare has implemented here. Makes sense for their memory constrained workers, less sense for traditional infrastructure.
wait what? what kind of logic do you need to do that CF Workers can't do?
This is why I prefer open source software. I can modify it
One person can use librsync to create a Dropbox company. Another person can use librsync for noncommercial purposes, e.g., to transfer and sync their own files
I mean... I, for my own needs, which are rather simple, can replace Dropbox with rsync. That's one thing. But yes, it's an entirely different thing to consider you don't need, or worse, could own, such business, on the simple premise you don't need it at your own level. That would be madness to mistake one for the other.
The data science is where the real value comes in. 10x flags changed this release - which one caused the improved CTR? Booleans as a service need to address this, and there are benefits to having your boolean service live next to your other services
It makes sense to not want to create an admin dash, but to avoid having to keep track of thousands of feature flags in your db, it seems all you're doing here is moving them to another db
Git is typically fairly slow if you have to wait on a test suite and deployment pipeline. Usually at least 10 minutes but sometimes 30, 60, 90+ minutes. A lot of purprose-built feature flag platforms hot reload the config in seconds.
JSON in the repo also risks introducing customer data to git if you want to rollout based on specific customer attributes (sometimes, for us, it's a list of early opt-in customers we have meetings with to discuss/develop new features)
It's also less accessible for "business users" like product/project managers, sales, and marketing they want to coordinate feature rollout with other business initiatives (and don't want to bother engineers when they do)
This gives you a distribution unrelated to active use, puts users in the same bucket (with the same number you’re going to have the same users in the first 10%) and links combinations together.
Often problems are more complex than they seem at first sight and I have found it’s a good approach to think “what am I missing” rather than “lots of people must be making very obviously bad decisions” and reach the latter conclusion only after more work. Usually I’ve missed something.
> This gives you a distribution unrelated to active use
Is that a problem?
> puts users in the same bucket (with the same number you’re going to have the same users in the first 10%) and links combinations together.
Are you trying to do a bunch of separate staged rollouts at the same time?
> Often problems are more complex than they seem at first sight and I have found it’s a good approach to think “what am I missing” rather than “lots of people must be making very obviously bad decisions” and reach the latter conclusion only after more work. Usually I’ve missed something.
They said it gets you 80% of the way there, and that seems fitting with the replies they got.
Yes! Are you totally missing some countries, did you set it to try and hit 20% but it’s actually 60% of traffic, does it happen to include some VIP type users, how does it impact the thing you’re trying to measure while you do this?
Do you give qa user ids in the right ranges to get applied and non applied views?
Even then you’re not able to get specific combinations.
> Are you trying to do a bunch of separate staged rollouts at the same time?
That would be very common yes, otherwise a staged rollout can be a big blocker.
But more than that it means there’s one user who always gets the beta testing of everything for example.
Assuming you want a random distribution and don't want to take any other attributes into account.
We're a small company but new feature release for big features is typically targeted at low risk users/customers first. That usually means a few attributes are taken into account (age, customer value, customer sentiment, which features they use)
Looking at the docs for their JS SDK, they have this warning:
> The client provider requires an API token to fetch flag values. This token is not scoped to a single app, so anyone with the token can evaluate flags across all apps in your account. Use the client provider with caution in public-facing applications.
Can anyone clarify... why the client SDK, designed to be deployed to browsers, requires caution? Does this mean that any client could send requests with a new targetingKey and observe other users' flags?
While flags probably shouldn't be critical information, this seems like an interesting design choice.
instead of polishing their existing products (and most of them do require a lot of work) they jump into any other niche someone thought was a good idea. My guess is that with ai being able to prototype things quickly they just started doing everything that is even a bit relevant.
I think they were doing that before AI got big the last couple years.
Their core network stuff always seemed pretty robust but all the newer stuff was much more thrown together. Thinking specifically of Zero Trust/Argo Tunnels which has been around a few years (and I do like) but has some rough edges.
Both Cloudflare and Vercel have feature parity. Flags is a feature already in Vercel. While customer-first is a thing, it is also a no-brainer to start with: we use it, Vercel has it, let us build it.
If you’re specifically thinking of native ephemeral workers with very fast startup, it seems like those would have to be sandboxed somehow, and WebAssembly seems like a decent solution. Is there really a significant native code gap between WebAssembly workers and native containers?
Containers seem to only be "Available on Workers Paid plan", whereas Vercel supports it on the hobby account as well.
Kind of relevant on those cheapskate projects that only start paying licenses after the SOW is signed, but already expect some kind of prototyping in place.
WebAssembly is a solution looking for a problem outside the browser, with worse development experience.
If I want bytecode based runtimes, I already have them with first class development experience, and decades of deployment experience, between Erlang, JVM and CLR.
Haven't used Vercel but back in the Heroku/CloudFoundry days it was pretty easy to jam arbitrary binaries into the runtime containers and some of the build packs were flexible enough you could override most of the functionality.
Not sure if that's possible/how easy it is on Vercel
That’s really about creating an MVP for a startup, because too many founders stay in a cave trying to make it “perfect” before collecting valuable user feedback.
This does not apply to Cloudflare, especially not for an auth token that needs to be published on your website that cannot be restricted.
Yes, this! I am dying for need of zerotrust enterprise features and am about to have to actually talk to one of the enterprise sales folks, which will chew up a bunch of time and add stress I’d rather avoid.
Cloudflare are winning these days, they’re just lacking good fine grained permissions. You still have to make an entirely separate account for prod, which messes up SSO since one domain can only be bound to one account.
Their products are cool and I've been happy with them over the years, but their blog right now has had some blunders recently. Also their reliability seems to have been having trouble but does seem better recently.
Their pricing is not ridiculous like some providers. It would be very hard to rack up that kind of bill, especially considering their rate limiting rules are now free to use.
One account gets compromised and your doomed. A lot of companies even have prod access be a request based system. Most modern security models with zero trust don't let everyone have access to everything, quite the opposite.
It’s pretty useful. We used it at a previous company. We built a custom backend, but used the spec and SDKs.
It took like 2 weeks to build a full custom backend. SDKs across languages worked flawlessly (okay, we did find one bug, reported it, and it was fixed within the day)
I have had a lot of experience with OpenFeature, and have early commits in a few of the client libraries. It's definitely the future of feature flagging, and the ecosystem is really growing.
Full disclosure, I am the CTO of Flagsmith, and we have seen a clear curve in adoption of OpenFeature over the last few years. It used to be that we were pushing customers to try it out, now they come to us with OpenFeature as a requirement.
The vendor support is pretty mature now and there is coverage across almost all languages. If you're integrating feature flags into a new service, or looking to migrate from e.g. home-grown to a third party solution, OpenFeature is definitely the way I would recommend going.
The flags (whether they be booleans, strings, numbers, or anything else) are the trivial part. It's the targeting and rollout rules (i.e. who gets to see which flags), and the requirements for extremely fast and consistent evaluation of these rules, that can get surprisingly complicated fast, and folks who have rolled their own usually find that product management or marketing or sales wants to target using more complex rules, and the problem balloons.
I agree that problem is not particularly hard in the grand scheme of things, but it is actually quite big, meaning it requires a lot of features that aren't obvious at first glance.
Edit: Thought of another analogy that may help explain the complexity. At their heart, feature flags are really a permissioning system: only certain users get access to certain pieces of functionality. Anyone who has ever dealt with permission systems know how complex they can be: group membership, including hierarchical groups, roles, ACLs, etc. All of those things are really analogous (actually, a subset really) to the various types of targeting rules that can be used in a feature flags system.
Percentage rollouts, RBAC, audit history, A/B testing, multivariate - it gets complex quick. That boolean turns into a whole system you have to maintain and operate.
How do you set a boolean to only return true for queries to 5% of the fleet? And which 5% of the fleet? And then ramp up on a predefined cadence? Or how about returning true only for customers in the preview group for the feature? Does the database return false automatically if the 5% of the fleet where it's true start crashing or throwing exceptions? Does it hook into your observability stack?
Fundamentally, sure, you could just implement it as a boolean in the database. It's the integration and tooling that works with the rest of your stack that makes it worthy of the name "feature flag".
They're not always booleans - for example, we often see feature flags being used for A/B rollouts.
Cloudflare themselves even uses them internally as such, by shipping new features/builds to their free customers first, and then progressively larger customers after a settling period.
Feature flags can also be randomly turned on, for a sort of fuzz testing. Don't think of them just as 'new things' - it could be 'changed behavior'.
I guess you could think of them as a boolean on every client but they're generally not implemented that way.
This is just an implementation detail, a feature flag can very well be implemented with a Boolean in a database.
To me the main appeal of feature flags is that they allow to work on large features that often require months and many commits to finish in a main branch. This, at least to me, results in a more lightweight and more iterative development process. This contrasts with maintaining a separate branch, with perhaps separate deployment target for a large in-development features.
These are booleans with a bit more context. They may only apply to a particular geographic area, and may have dependencies: if we turn off flag X, we automatically turn off flag Y.
efficient delivery of the single bit (and especially the flip event) to the desired audience is the use case. the actual payload almost doesn't matter as long as it's reasonably small.
Then why did they deliberately make it compatible with Open Feature, explicitly making it easy to swap out a different Open Feature provider?
Oh, that's right, you just spouted a "big company bad" mantra without bothering to read the article. Look, I know saying RTFA goes against the HN guidelines, but the amount of increasingly lazy spew i see from folks (or bots) who haven't bothered to read the article is so tiresome and annoying.
Feature flags are often ridiculously over engineered.
Check a config, bdd value, env var to dynamically go one path or the other.
That’s all, you must either have a small feature or refactor the code to easily switch at a high level.
If you are not able to do so easily, then yes, complex feature flags implementations might help you, to coordinate feature activation between micro services.
Or if you have many features then a dashboard might be useful.
But I would argue that both are serious indicators that you should avoid feature flags, they are better for local and temporary changes, otherwise the complexity compounds and it become hard to manage and maintain.
There's an argument to be made for being able to turn on a feature for a certain segment (e.g low revenue users in Italy) so you can see what the business/performance impact is.
Ofcourse you don't want users to lose the feature once they exceeded your revenue threshold or cross the border so you'll need to implement some kind of tracking. Your analytics and error tracking also needs to communicate with the feature flag service.
Definitely not rocket science but more complex than a environment variable.
Enterprise software is full of this kind of stuff. Half our customers are on year old UI's because they don't want to re-up contracts yet.
That is, features are contractual and when you've only got 50 customers but they're all paying high 6 figures does anyone really care about feature flag complexity?
There's an argument to be made for being able to turn on a feature for a certain segment
Not just an argument, it's the entire point of feature flags for ui experiments which is an essential practice. Dynamic adjustment of the cohorts (or even just an immediate kill switch if it's a disaster) is required.
I’m always excited when Cloudflare starts offering things that I had to use other providers for because I know it will be solid.
We used Statsig at Function. It started out as 2 of us using it on one product and within 12 months, large amounts of our product copy and rollouts were driven off of it.
Statsig has client side evals so you can write rules and rollouts based on internal concepts without Statsig’s servers processing a piece of user data. Hoping Cloudflare can build a sophisticated product here so I don’t have use another product in the future!
i see @btown's comment below but also just for education about this space:
- anyone have comments/comparisons about launchdarkly vs posthog vs statsig (is it still alive after openai?) vs _____ vs cloudflare flagship?
like a "beginner/intermediate/advanced" progression of what to look out for/what you will want when it comes to feature flags would be highly helpful for me and many others here
A bit tangent but related: These things I'm never sure if I should be shipping on day one with mobile apps (Flutter in particular): Flagships, bug gathering, A/B testing ?
I feel strong inclination too but its also way too early before any real users can prove PMF. I've been using Google stuff but wonder if Flagship and perhaps other Cloudflare offerings can help.
The other side is that again it feels too early for this stuff and I just want to ship something quickly.
If anyone is interested, you can implement something like that with a few lines of code on the front end. We expose a function that generates a uniformly-distributed hash that you can use for A/B testing and other uses:
Essentially, this can support a huge number of "variants" and within each variant you can have N equal segments. That will help you do A/B testing and flipping features on or off.
I am a mere mortal when it comes to understanding the technicalities, but I know i find it relatively easy to use Cloudflare and all I want to say is keep up the good work.
More of this please: essential tools for building modern software must be oss; Im fine with paying for a hosted version but just the benefit of learning one tool and being able to use it everywhere (linux, k8s, python etc) is amazing.
Has anyone struggled to run their own feature flagging service? After root causing slow app starts to be caused by the equivalent offering from Firebase, I've been cautious to use any off the shelf solutions
It can get complicated quickly if you're actually using it in a production system. At my prev enterprise saas company we had feature flags that could be turned on per customer / per environment (dev, staging, prod) with permission + logging model such that our support team could also toggle flags with history of who turned on what. We also had "per user" feature flags for certain test users at companies and had DSL rules to evaluate the features
I really like the speed at which Cloudflare is executing toward becoming a critical infrastructure player with all of those new product offerings. That said, not everything needs to be serverless. Their Gen 13 hardware looks impressive, and it’s a pity you can’t rent it by the hour like AWS EC2 Metal instances.
never understood this. why follow over-engineered standard and depend on 3rd party API spec, and 3rd party vendor. if you cannot call home from your service, you having bigger problems. and once you can call home, it is just.. single json file.
Missing gradual rollout of feature flag changes themselves. Yes, you can do percentage based rollouts for individual features but still should have ability to canary all changes before they cause an insta-sev.
I don’t have experience with the tools Cloudflare has been shipping this year so I can’t speak about the quality, but they have really been pushing out a lot new products and services, no doubt due to agentic coding.
I love direction and features Claudflare is taking, they are really impressive. And since I use their service on several projects, I can say I am overall very happy with service.
Only thing, they are going strongly in AWS territory and not in any good way. Finding what I need and what I use has become harder as times go by. By contast, Azure (MS) even though it looks crazy complex, once you get used to it, you can find things.
Am I the only one worried about Cloudflare becoming too powerful?
We went through this with E-mail: we slept through the period when Google, Microsoft and AWS were growing, and we ended up with them dictating the terms. Today I get 90% of my spam from Google, Microsoft and AWS and they don't care: they can safely ignore spam reports, because at this point they are Too Big to Block.
I have a feeling we are moving towards the same problem with Cloudflare and the web. Tomorrow Cloudflare will start dictating what we can or cannot do and we will not be able to do anything about it. This has already begun: their arbitrary "bot-filtering" for example.
Cloudflare is already too powerful, their anti DDOS solution is just too good. But their serverless products/features don't really build on that, they are just another hosting company.
> Am I the only one worried about Cloudflare becoming too powerful?
No, it gets brought up in every single thread about cloud flare. And if this wasnt a feature release that people seem to like, the top comment would probably be talking about how cloudflare is terrible for the internet.
Never underestimate the power of a zero-network-hop abstraction over f(feature_name, context).
And context can be extremely tailored to your niche: specific inventory, from a specific supplier, for a specific user of a specific B2B client of a specific business model subtype, who should or shouldn’t see certain features on that specific inventory at certain times.
When you can write your own logic, and just run this in a tight loop as easily and performantly as you can use a constant, it makes your business incredibly agile. Think some text might change for some customers? Just write the code to make it configurable, and you get tests and flags for free.
Sadly, that zero-hop setup requires a sophisticated client execution engine, which it doesn’t appear Cloudflare has implemented here. Makes sense for their memory constrained workers, less sense for traditional infrastructure.
Statsig has an approach here that I quite like:
> To be able to do this, Server SDKs hold the entire ruleset of your project in memory - a representation of each gate or experiment in JSON. On client SDKs, we evaluate all of the gates/experiments when you call initialize - on our servers.
https://docs.statsig.com/sdks/how-evaluation-works
You can also roll your own - just sync your rulesets to a few data structures every few seconds in a background thread and atomically swap the reference to them. Then you just need a CRUD interface over the applicability ruleset dimensions.
Just be careful to have governance on who can play with which would-be constants. Great power and great responsibility and all that!
When reading your comment, it just reminds me on how feature flags can be misused as application configuration/customization. An antipattern i could observe at various organzations already.
For me feature flags go along with trunk based development to enable features in QA settings, but not on PROD yet, for PO/PM testing. Trunk based development allows for fast/easy devops, without complicated branching strategies.
Application configuration is, for me, part of the application and has the business context for customizing the application accordingly. Not sure if there are specific frameworks/tools out there. But one should clearly distinguish these two.
> it just reminds me on how feature flags can be misused as application configuration/customization. An antipattern i could observe at various organzations already.
feature flags are perfect for configuration and customization, why using them for this purpose is 'misuse' is beyond me and I've heard this claim from multiple people. they're literally configuration. feature with a flag to turn it on, off or give the flag a value. where's the misuse? is it a problem I'm not running experiments when switching over redis to valkey or whatever?
Feature flags need to be treated as short-lived and experimental otherwise they end up getting abused for everything and make it very difficult to reason about your application.
If it's config/customization, it should be in code. If it's experimental it can be a flag until it solidifies, and then it needs to get moved to code.
When I was at Shopify a couple of years ago they mandated that feature flags had to be short-lived (Like 2-4w lifetime tops, some had exceptions) because they would end up getting left in code and never cleaned up, or for extended periods of time like months. Hard to tell if it's genuinely a "feature flag" or actually just a normal part of the system at that point.
Feature flags being flipped in prod was also a major source of incidents, in part because people didn't treat them as experimental and with the associated risk profile of something experimental.
The only exception where having long-lived flags was useful and required was for operational killswitches (E.g. disable Apple Pay because it's having issues), but that is explicitly not application config.
Agreed.
This is the kind of design wisdom that’s both true and difficult to win an argument over.
It reminds me of arguments related to over-engineering and complexity. The principles are super important to having a codebase that scales and continues to be efficient to work in as the team grows, but they are hard to objectively measure.
Locally or in isolation something may sound like a great idea. Being able to step back and see the greater ripple effects require some experience and intuition that can’t always be used to convince people otherwise.
I disagree with just about everything you said being a problem except the process of cleaning up is absolutely required.
Notably feature flags triggering incidents is expected and desired vs the alternative of shipping the code and having to roll a release back because there is no other way to remove the feature from prod.
In a company the size of Shopify people flipping their feature flags would very often impact *other teams*, and like I said feature flags got abused with even seemingly innocuous changes being put behind them or being left long periods of time before being fully used.
When someone else flips a flag that impacts your team and they have no idea they even caused a problem, it becomes very difficult to resolve the issue. Usually you can check for recent deploys, instead you have to go and guess at which feature flag which was recently flipped could possibly be affecting your code. I experienced this several times.
Also, it was actually more desirable for most of these things to go straight to production. Test it properly before shipping, then when you ship it soaks on a 5% traffic canary at which point you can monitor and cancel the deploy if you see errors. That is generally safer than a feature flag rollout unless you are doing something very high impact/risk, in large part because it gives any other team affected by your rollout the ability to respond and be able to easily find the source of errors.
In my org it was a fairly common failure mode to ship something and accidentally cause an issue for another team. Usually it was other teams/orgs shipping things that impacted us.
Runtime evaluated feature flags can always be used for control plane levers and emergency handbrakes.
You just have to label them as such and prevent other teams from fiddling with them.
This is not an antipattern, it's just semantic hand-wringing.
My team managed critical systems in the online flow of billions of dollars of daily payment volume. We also wrote the feature flag system that the rest of the company used. Not only were we completely fine with feature flags as long-lived control plane levers, we heavily used the system that way ourselves.
You just have to clearly distinguish between ephemeral rollout flags (and clean them up or expire them) and the permanent control plane levers.
It's the exact same functionality for both sets of tools. Just different practices around the two usages.
I completely agree with your distinction and that is exactly what they mandated :)
I don't think that is what most people colloquially mean by "feature flags" though. Even most teams in Shopify abused "ephemeral" flags for long periods of time.
When they rolled out the mandate it was very annoying for my team because we had a lot of operational flags like you're describing that we needed to get exemptions for.
One well known issue is that when you have a lot of separate feature flags that can interact, you explode the number of test cases you have to cover. For example if you have three feature flags that can interact in a module that has 100 test cases, you actually have 900 test cases if you are going to test with each possible combination of flags. Many teams don't test them all because they "already know" that doesn't apply here, and find out in production which combination of feature flags is unworkable.
But you have this same issue if you store those 3 bits of state as "app config" instead of as "feature flags".
I think it's useful to distinguish between kinds of feature flags -- "traditional" feature flags for safe rollout of new features (these should be removed on a strict timeline, to preserve maintainability) vs. "config"-type flags that are designed to remain indefinitely and optionally be configurable by certain end users. But I don't yet see a reason why the actual mechanism for these two things (namely, a function with a descriptive name that can be called to quickly return a small datum that is periodically refreshed from somewhere in the background) can't be the same.
Yes people are speaking past each other to some extent here; but if we're going to talk about "Feature Flags" we aren't talking about using a flag service for "normal" configuration - whatever that means. But what, exactly - does that mean? I normally consider things like the following configuration:
API Host Names, client Ids, secrets, Database connection strings Other runtime settings like pool sizes, replica counts etc
Most of those things are secrets, or they are specific scalar values closely tied to the application runtime, that often need to be known at startup. Are people putting those in a "feature flag" service? If not, what is a good example?
My comment only applies to "configuration" that alters behavior, usually in binary off/on manner. Which is what I'd call a "Feature Flag".
Yes, feature flags are conflated with remote configs (or its more useful variety: "dynamic configs"). The difference is subtle, hence why people are talking past each other.
Feature flags are gates for whether a piece of code runs; basically, an if-condition. Remote configs are a mechanism for changing runtime values without redeploying[1].
For example:
In practice, feature flags are implemented on top of dynamic configs[2] to manage the temporary lifecycle of a feature — aka, ship a new block of code, ramp its execution up to 100%, then delete the flag. Whereas dynamic configs are a deeper primitive meant for semi-permanent/safer operations like tuning rate limits or changing text copy on a marketing website.As I've seen it: the forcing function that separates the concepts are experimentation platforms: when human-control of feature flags is shared (via dynamic configs) with automated & randomized assignments. That's how Statsig built their system and, in part, why they could sell for a billion. Whereas companies that ignored the difference, like LaunchDarkly, struggled outside of feature flags.
[1] https://engineering.atspotify.com/2020/10/spotifys-new-exper...
[2] https://docs.statsig.com/dynamic-config/overview https://blog.x.com/engineering/en_us/topics/infrastructure/2...
I think feature flags, remote configs, and experiments are all the same thing. Semantically they differ in how you're applying the config and interpreting the outcomes.
> it just reminds me on how feature flags can be misused as application configuration/customization
They literally are configuration.
Oh yeah lets make a web request per service invocation to figure out what to serve for the invocation!
Guys this is exactly the kind of banal crap that makes a simple app into a monsterous beast that won't work unless it's connected to the internet.
There's no web request per service invocation.
Feature flags are set once at startup (or specific events like hard refresh, or new login) and then simply included in the request headers.
It's not rocket science, but I'm sure people are free to overcomplicate it.
That's not a feature flagging service then (config as a service! not a thing really...)
I've done both client and server side implementations of the launch darkly sdk and that's how it's done to know client context.
If you're initialising the entire SDK only to load 1 set of configuration items, I'd argue you can host the config as a json file on a CDN and be done with it - feature flagging is overkill.
Then I'm lost at what the difference would be and why do you need a dedicated service.
Pardon my ignorance.
Which is not hard to do (it is a modulo over a mersenne twister or something similar), but in my recent gigs just Flipper with optional "state of the flags table as of now" endpoint was more than enough. That modulo+random combo required tools like LaunchDarkly to ship SDKs in several languages, and the ones I had to work with were just plain horrible fit for their language of choice. But because the evaluation was relegated to the edge, the whole system got way more complex than desirable. In actuality, I think a refetch of the current flags table "for this customer" every so often is just fine, and way less of a nuisance.
So glad Flipper exists and I don't have to deal with this stuff anymore.
which Flipper is this?
> Sadly, that zero-hop setup requires a sophisticated client execution engine, which it doesn’t appear Cloudflare has implemented here.
It doesn't have to be sophisticated and they don't need to implement it themselves. They piggy-back on OpenFeature where the client libraries have a simple targeting rule evaluation engine integrated.
But why would you wrap some proprietary solution around your neck instead of rolling your own custom solution or extending some open source?
The answer for most things pertaining to encloudification seems to be "because it's easy and we are already using cloud provider X". Death by a thousand clickops.
Good advice. I'll add a protip / reminder that feature flags, AB tests, and entitlements are three distinct concepts. This blog post (no affiliation) has framing I found helpful:
https://www.stigg.io/blog-posts/entitlements-untangled-the-m...
Amazing resource, thanks!
Statsig has worked great at my work, really polished and rich feature set. Their tooling to identify unused flags as candidates for removal is neat.
The per-seat billing we have in our agreement is a bit rough but it's workable.
Statsig is a half-baked product bought out by OpenAI for data harvesting. We already reported 2 documentation issues and 1 critical technical issue, and we're barely using it.
Well, OpenAI already sold it (but kept the team), so it’s in someone else’s hands now.
Could you be more specific?
> Sadly, that zero-hop setup requires a sophisticated client execution engine, which it doesn’t appear Cloudflare has implemented here. Makes sense for their memory constrained workers, less sense for traditional infrastructure.
wait what? what kind of logic do you need to do that CF Workers can't do?
[flagged]
Gold-plated booleans-as-a-service
I’ve seen whole teams at companies set up fail to provide these booleans-as-a-service well. There are whole companies like LaunchDarkly for them.
If you boil it down to this, you may as well boil down every service that exists to bits-as-a-service.
Turns out theres legitimate business value in these things, and complexity in delivering them.
It's like saying Dropbox is just rsync.
IIRC Dropbox was originally created using librsync
Dropbox has modified it
https://github.com/dropbox/librsync
This is why I prefer open source software. I can modify it
One person can use librsync to create a Dropbox company. Another person can use librsync for noncommercial purposes, e.g., to transfer and sync their own files
Either way, it's librsync
I mean... I, for my own needs, which are rather simple, can replace Dropbox with rsync. That's one thing. But yes, it's an entirely different thing to consider you don't need, or worse, could own, such business, on the simple premise you don't need it at your own level. That would be madness to mistake one for the other.
The data science is where the real value comes in. 10x flags changed this release - which one caused the improved CTR? Booleans as a service need to address this, and there are benefits to having your boolean service live next to your other services
I don't mind it. I don't want to keep track of thousands of feature flags in my DB, have to create an admin dash, etc.
You could call any SaaS tool "excel-as-a-service" and it would hold the same power as your comment.
It makes sense to not want to create an admin dash, but to avoid having to keep track of thousands of feature flags in your db, it seems all you're doing here is moving them to another db
or maybe just make single JSON and commit it to git? your http server + GitHub + JSON and text editor is your admin ui, audit, etc.
Git is typically fairly slow if you have to wait on a test suite and deployment pipeline. Usually at least 10 minutes but sometimes 30, 60, 90+ minutes. A lot of purprose-built feature flag platforms hot reload the config in seconds.
JSON in the repo also risks introducing customer data to git if you want to rollout based on specific customer attributes (sometimes, for us, it's a list of early opt-in customers we have meetings with to discuss/develop new features)
It's also less accessible for "business users" like product/project managers, sales, and marketing they want to coordinate feature rollout with other business initiatives (and don't want to bother engineers when they do)
how would a single JSON allow staged rollouts with sticky sessions?
you pick a frequency you want, represent that as a fraction, and modulo on user id, and your 80% of the way there
This gives you a distribution unrelated to active use, puts users in the same bucket (with the same number you’re going to have the same users in the first 10%) and links combinations together.
Often problems are more complex than they seem at first sight and I have found it’s a good approach to think “what am I missing” rather than “lots of people must be making very obviously bad decisions” and reach the latter conclusion only after more work. Usually I’ve missed something.
> This gives you a distribution unrelated to active use
Is that a problem?
> puts users in the same bucket (with the same number you’re going to have the same users in the first 10%) and links combinations together.
Are you trying to do a bunch of separate staged rollouts at the same time?
> Often problems are more complex than they seem at first sight and I have found it’s a good approach to think “what am I missing” rather than “lots of people must be making very obviously bad decisions” and reach the latter conclusion only after more work. Usually I’ve missed something.
They said it gets you 80% of the way there, and that seems fitting with the replies they got.
> Is that a problem?
Yes! Are you totally missing some countries, did you set it to try and hit 20% but it’s actually 60% of traffic, does it happen to include some VIP type users, how does it impact the thing you’re trying to measure while you do this?
Do you give qa user ids in the right ranges to get applied and non applied views?
Even then you’re not able to get specific combinations.
> Are you trying to do a bunch of separate staged rollouts at the same time?
That would be very common yes, otherwise a staged rollout can be a big blocker.
But more than that it means there’s one user who always gets the beta testing of everything for example.
I think it’s a lot below 80%, really.
Assuming you want a random distribution and don't want to take any other attributes into account.
We're a small company but new feature release for big features is typically targeted at low risk users/customers first. That usually means a few attributes are taken into account (age, customer value, customer sentiment, which features they use)
This just tells me you haven’t worked on a big/complex enough system.
If it were that easy people would not be paying for it.
Getting those booleans to the right place at the right time reliably isn't trivial.
MVP
yes, worth every penny
[dead]
Looking at the docs for their JS SDK, they have this warning:
> The client provider requires an API token to fetch flag values. This token is not scoped to a single app, so anyone with the token can evaluate flags across all apps in your account. Use the client provider with caution in public-facing applications.
https://developers.cloudflare.com/flagship/sdk/client-provid...
Can anyone clarify... why the client SDK, designed to be deployed to browsers, requires caution? Does this mean that any client could send requests with a new targetingKey and observe other users' flags?
While flags probably shouldn't be critical information, this seems like an interesting design choice.
Let's think about it. This is probably something used internally at CloudFlare and someone thought I'd be interesting to make it public.
There is no way 6 months ago someone at CloudFlare thought it was a good idea to build a competitor to say LaunchDarkly.
Hmm not sure I necessarily agree. Cloudflare's strategy has been looking like "the only platform you need" for a while now.
Their recent features / announcements have been equivalent to:
(LaunchDarkly)
Resend, Firecrawl, CrewAI, Helicone, Replicate, Pinecone
-
Which like… many companies have a painful procurement process. If all you need is Cloudflare, and prices are within reason- why not use them
Their quality of the products they ship have already became shitty for quite a while now.
they are quickly turning into a slop shop
instead of polishing their existing products (and most of them do require a lot of work) they jump into any other niche someone thought was a good idea. My guess is that with ai being able to prototype things quickly they just started doing everything that is even a bit relevant.
which won't end well
I think they were doing that before AI got big the last couple years.
Their core network stuff always seemed pretty robust but all the newer stuff was much more thrown together. Thinking specifically of Zero Trust/Argo Tunnels which has been around a few years (and I do like) but has some rough edges.
Don’t forget they now also have an OpenRouter alternative.
[dead]
Both Cloudflare and Vercel have feature parity. Flags is a feature already in Vercel. While customer-first is a thing, it is also a no-brainer to start with: we use it, Vercel has it, let us build it.
Now waiting for Cloudflare to allow me to use Rust for serverless, real native code, not WebAssembly.
https://vercel.com/docs/functions/runtimes/rust
They have containers, does that count?
If you’re specifically thinking of native ephemeral workers with very fast startup, it seems like those would have to be sandboxed somehow, and WebAssembly seems like a decent solution. Is there really a significant native code gap between WebAssembly workers and native containers?
Containers seem to only be "Available on Workers Paid plan", whereas Vercel supports it on the hobby account as well.
Kind of relevant on those cheapskate projects that only start paying licenses after the SOW is signed, but already expect some kind of prototyping in place.
WebAssembly is a solution looking for a problem outside the browser, with worse development experience.
If I want bytecode based runtimes, I already have them with first class development experience, and decades of deployment experience, between Erlang, JVM and CLR.
Haven't used Vercel but back in the Heroku/CloudFoundry days it was pretty easy to jam arbitrary binaries into the runtime containers and some of the build packs were flexible enough you could override most of the functionality.
Not sure if that's possible/how easy it is on Vercel
https://blog.cloudflare.com/flagship
Here's why we built it!
>Agentic coding tools like OpenCode and Claude Code are shipping entire features in minutes.
How many minutes do I need to wait until app-scoped tokens are live?
Sorry, just reached the weekly token limit.
Ah, no-look coding.
How can we possibly trust the AI to disable the 'CODE_IS_SKYNET' flag.
Care to share why
Hi! One of the engineers from the Flagship team here, app-scoped tokens are WIP.
That sounds like the product is not finished and should not be released?
"If you are not ashamed by what you are shipping, you are not shipping early enough" (Quoting from memory)
That’s really about creating an MVP for a startup, because too many founders stay in a cave trying to make it “perfect” before collecting valuable user feedback.
This does not apply to Cloudflare, especially not for an auth token that needs to be published on your website that cannot be restricted.
If your engineer tells you that, you're going to have a bad time.
I think you're thinking this:
> If you are not embarrassed by the first version of your product, you've launched too late. -Reid Hoffman
That's a terrible attitude for an infrastructure company. This is what private betas / close iteration with customers is for.
This has been the Cloudflare standard operating procedure for the last year or so. Non stop shipping alpha/beta products.
Otherwise known as vibe code snacking. Vibe out the easy 80% and say the hard 20% is “coming soon tm”
Is it perhaps available behind a flag somewhere?
Then it's not finished?
Jane Wong salivating reading this
This is nice, but I’m still waiting for this to be delivered (which ironically is probably using Flagship):
https://blog.cloudflare.com/enterprise-grade-features-for-al...
—-
I don’t believe a single enterprise only feature has made its way to lower tier (paid) account yet.
I’m most interested in:
https://developers.cloudflare.com/speed/optimization/content...
Yes, this! I am dying for need of zerotrust enterprise features and am about to have to actually talk to one of the enterprise sales folks, which will chew up a bunch of time and add stress I’d rather avoid.
Fwiw I didn't think Cloudflare sales was too bad when we dealt with them a year ago--at least compared to some companies.
Just sent a request, fingers crossed.
I don’t think zero trust will be anytime soon, based on this post:
https://community.cloudflare.com/t/making-enterprise-product...
Appreciate the gentle let down.
Cloudflare are winning these days, they’re just lacking good fine grained permissions. You still have to make an entirely separate account for prod, which messes up SSO since one domain can only be bound to one account.
Their products are cool and I've been happy with them over the years, but their blog right now has had some blunders recently. Also their reliability seems to have been having trouble but does seem better recently.
Will never use them without prepayment or spending limit options. Insane to be a bug, attack, or misclick away from 6-7 digit invoice
the CTO of Cloudflare (hn: dknecht) said:
> It is in the works. The billing team has been sprinting to fix a lot of debt in this area. I don’t have a date.
https://x.com/dok2001/status/2051220429973389622
Great thanks
Their pricing is not ridiculous like some providers. It would be very hard to rack up that kind of bill, especially considering their rate limiting rules are now free to use.
After years of AWS I gave Cloudflare a whirl and loved the UX but ultimately retreated back due to the same concern. They are so close though..
Yes! I just opened a support case today asking for more fine grained permissions.
Yep I made the switch a couple of years ago for all of my projects and never looked back. Workers, D1, R2, queues, containers, KV
Still using AWS for email sending so that will be great when it comes
E-mail sending is in beta afaik, you need the Workers paid plan to use it.
thank you!! missed the public launch
It already came if you use workers I believe, still in beta though. I would love to switch to it but I still need the SMTP interface though. https://developers.cloudflare.com/email-service/
wow thanks. I saw the initial announcement when it was still in private beta, but have been less online lately and missed the public launch. Awesome!!
This is exactly what stops me from using them for real work. I love their free tier for my hobby stuff.
Just let everyone have access to prod?
Poor access and change management governance.
hooboy that was a good one!
One account gets compromised and your doomed. A lot of companies even have prod access be a request based system. Most modern security models with zero trust don't let everyone have access to everything, quite the opposite.
Not sure what they are winning .. we kept them as a backup but they are so bad that they fail even there
OpenFeature was new to me, neat! Anyone have experience integrating this? https://openfeature.dev
It’s pretty useful. We used it at a previous company. We built a custom backend, but used the spec and SDKs.
It took like 2 weeks to build a full custom backend. SDKs across languages worked flawlessly (okay, we did find one bug, reported it, and it was fixed within the day)
I have had a lot of experience with OpenFeature, and have early commits in a few of the client libraries. It's definitely the future of feature flagging, and the ecosystem is really growing.
Full disclosure, I am the CTO of Flagsmith, and we have seen a clear curve in adoption of OpenFeature over the last few years. It used to be that we were pushing customers to try it out, now they come to us with OpenFeature as a requirement.
The vendor support is pretty mature now and there is coverage across almost all languages. If you're integrating feature flags into a new service, or looking to migrate from e.g. home-grown to a third party solution, OpenFeature is definitely the way I would recommend going.
I've never understood feature flags. How are they fundamentally different to a Boolean in a database?
The flags (whether they be booleans, strings, numbers, or anything else) are the trivial part. It's the targeting and rollout rules (i.e. who gets to see which flags), and the requirements for extremely fast and consistent evaluation of these rules, that can get surprisingly complicated fast, and folks who have rolled their own usually find that product management or marketing or sales wants to target using more complex rules, and the problem balloons.
I agree that problem is not particularly hard in the grand scheme of things, but it is actually quite big, meaning it requires a lot of features that aren't obvious at first glance.
Edit: Thought of another analogy that may help explain the complexity. At their heart, feature flags are really a permissioning system: only certain users get access to certain pieces of functionality. Anyone who has ever dealt with permission systems know how complex they can be: group membership, including hierarchical groups, roles, ACLs, etc. All of those things are really analogous (actually, a subset really) to the various types of targeting rules that can be used in a feature flags system.
Great reply. Thank you for taking the time
Feature flags and authorization abstract the same concept https://ntietz.com/blog/feature-flags-and-authorization/
Percentage rollouts, RBAC, audit history, A/B testing, multivariate - it gets complex quick. That boolean turns into a whole system you have to maintain and operate.
It's the tooling around them.
How do you set a boolean to only return true for queries to 5% of the fleet? And which 5% of the fleet? And then ramp up on a predefined cadence? Or how about returning true only for customers in the preview group for the feature? Does the database return false automatically if the 5% of the fleet where it's true start crashing or throwing exceptions? Does it hook into your observability stack?
Fundamentally, sure, you could just implement it as a boolean in the database. It's the integration and tooling that works with the rest of your stack that makes it worthy of the name "feature flag".
Thanks, good reply. I can see the argument for sure.
I guess I like boring software too much to reach for a dependency but I do see how the tooling matters here.
Here's one detailed blog about it: https://martinfowler.com/articles/feature-toggles.html
They're not always booleans - for example, we often see feature flags being used for A/B rollouts.
Cloudflare themselves even uses them internally as such, by shipping new features/builds to their free customers first, and then progressively larger customers after a settling period.
Feature flags can also be randomly turned on, for a sort of fuzz testing. Don't think of them just as 'new things' - it could be 'changed behavior'.
I guess you could think of them as a boolean on every client but they're generally not implemented that way.
Really any "constant". Failure thresholds, timeouts, API versions or endpoints, LLM model id
This is just an implementation detail, a feature flag can very well be implemented with a Boolean in a database.
To me the main appeal of feature flags is that they allow to work on large features that often require months and many commits to finish in a main branch. This, at least to me, results in a more lightweight and more iterative development process. This contrasts with maintaining a separate branch, with perhaps separate deployment target for a large in-development features.
These are booleans with a bit more context. They may only apply to a particular geographic area, and may have dependencies: if we turn off flag X, we automatically turn off flag Y.
efficient delivery of the single bit (and especially the flip event) to the desired audience is the use case. the actual payload almost doesn't matter as long as it's reasonably small.
That’s all it is. This only exists to lock you into cloudflare even more.
Then why did they deliberately make it compatible with Open Feature, explicitly making it easy to swap out a different Open Feature provider?
Oh, that's right, you just spouted a "big company bad" mantra without bothering to read the article. Look, I know saying RTFA goes against the HN guidelines, but the amount of increasingly lazy spew i see from folks (or bots) who haven't bothered to read the article is so tiresome and annoying.
Oh look. Found the guy who’s taken it hook line and sinker.
Feature flags are often ridiculously over engineered.
Check a config, bdd value, env var to dynamically go one path or the other.
That’s all, you must either have a small feature or refactor the code to easily switch at a high level.
If you are not able to do so easily, then yes, complex feature flags implementations might help you, to coordinate feature activation between micro services.
Or if you have many features then a dashboard might be useful.
But I would argue that both are serious indicators that you should avoid feature flags, they are better for local and temporary changes, otherwise the complexity compounds and it become hard to manage and maintain.
There's an argument to be made for being able to turn on a feature for a certain segment (e.g low revenue users in Italy) so you can see what the business/performance impact is.
Ofcourse you don't want users to lose the feature once they exceeded your revenue threshold or cross the border so you'll need to implement some kind of tracking. Your analytics and error tracking also needs to communicate with the feature flag service.
Definitely not rocket science but more complex than a environment variable.
Enterprise software is full of this kind of stuff. Half our customers are on year old UI's because they don't want to re-up contracts yet.
That is, features are contractual and when you've only got 50 customers but they're all paying high 6 figures does anyone really care about feature flag complexity?
It is like over-engineered if you have that as feature flag instead of just in the customer configuration...
"The customer would like the main page blue and another one the red". Would it be feature flag for you?
There's an argument to be made for being able to turn on a feature for a certain segment
Not just an argument, it's the entire point of feature flags for ui experiments which is an essential practice. Dynamic adjustment of the cohorts (or even just an immediate kill switch if it's a disaster) is required.
The main thing about feature flags is discipline: create them purposefully, remove them as soon as they don't add value any more. KISS applies.
I’m always excited when Cloudflare starts offering things that I had to use other providers for because I know it will be solid.
We used Statsig at Function. It started out as 2 of us using it on one product and within 12 months, large amounts of our product copy and rollouts were driven off of it.
Statsig has client side evals so you can write rules and rollouts based on internal concepts without Statsig’s servers processing a piece of user data. Hoping Cloudflare can build a sophisticated product here so I don’t have use another product in the future!
you use a 3rd party for feature flags? im not "roll my own" for everything but feature flags have not been an issue to roll
There's feature flags then there's staged rollouts gated by multiple variables with statistical analysis
i see @btown's comment below but also just for education about this space:
- anyone have comments/comparisons about launchdarkly vs posthog vs statsig (is it still alive after openai?) vs _____ vs cloudflare flagship?
like a "beginner/intermediate/advanced" progression of what to look out for/what you will want when it comes to feature flags would be highly helpful for me and many others here
A bit tangent but related: These things I'm never sure if I should be shipping on day one with mobile apps (Flutter in particular): Flagships, bug gathering, A/B testing ?
I feel strong inclination too but its also way too early before any real users can prove PMF. I've been using Google stuff but wonder if Flagship and perhaps other Cloudflare offerings can help.
The other side is that again it feels too early for this stuff and I just want to ship something quickly.
The work ivnvolved
Worth noticing a Vercel equivalent: https://github.com/vercel/flags
That is actually their SDK / provider agnostic library. The better parallel to this new Cloudflare offering is Vercel Flags[1] (confusing I know)
[1] https://vercel.com/docs/flags/vercel-flags
only 2 hard problems in computer science...
If anyone is interested, you can implement something like that with a few lines of code on the front end. We expose a function that generates a uniformly-distributed hash that you can use for A/B testing and other uses:
https://github.com/Qbix/Q.js/blob/main/src/js/Q.minimal.js#L...And on the back end, you'd use it like this:
https://github.com/Qbix/Platform/blob/main/platform/classes/...
Essentially, this can support a huge number of "variants" and within each variant you can have N equal segments. That will help you do A/B testing and flipping features on or off.
I am a mere mortal when it comes to understanding the technicalities, but I know i find it relatively easy to use Cloudflare and all I want to say is keep up the good work.
Indeed. Best DNS registrar I've ever used.
I really liked Google Domains, but alas…
More of this please: essential tools for building modern software must be oss; Im fine with paying for a hosted version but just the benefit of learning one tool and being able to use it everywhere (linux, k8s, python etc) is amazing.
Cloudflare oss?
Has anyone struggled to run their own feature flagging service? After root causing slow app starts to be caused by the equivalent offering from Firebase, I've been cautious to use any off the shelf solutions
It's literally a field in your database. I could never fathom why this needs to be an outsourced service never mind an entire company.
It can get complicated quickly if you're actually using it in a production system. At my prev enterprise saas company we had feature flags that could be turned on per customer / per environment (dev, staging, prod) with permission + logging model such that our support team could also toggle flags with history of who turned on what. We also had "per user" feature flags for certain test users at companies and had DSL rules to evaluate the features
when started, yes. but then you want segment (how you segment your user), rollout strategy, etc.. it will get complicated fast
Thank you! I've never understood why this needs to be an external dependency with network requests.
Unless you're on sqlite, the database is still an external dependency with network requests
Deploy to master ( microservices)
Booleans as a Service
I really like the speed at which Cloudflare is executing toward becoming a critical infrastructure player with all of those new product offerings. That said, not everything needs to be serverless. Their Gen 13 hardware looks impressive, and it’s a pity you can’t rent it by the hour like AWS EC2 Metal instances.
never understood this. why follow over-engineered standard and depend on 3rd party API spec, and 3rd party vendor. if you cannot call home from your service, you having bigger problems. and once you can call home, it is just.. single json file.
Missing gradual rollout of feature flag changes themselves. Yes, you can do percentage based rollouts for individual features but still should have ability to canary all changes before they cause an insta-sev.
I'm out of my league on this discussion, but it reminds me of the Configuration Database (CDB) used for most modern aircraft.
Funny that my app already uses custom feature flag solution built on... Cloudlfare Workers
this make perfect sense for cloudflare.
and im sure they can drive down the cost , compared to say launchdarkly
I would happily pay for safely-remove-old-feature-flags-from-the-code-as-a-service.
Someone at work made a Claude skill that seems to work, surprisingly
You can set up a job to pester owners of old flags.
Anybody and everybody could use a mature LaunchDarkly alternative.
According to their page, they are an AI company, so I don’t see why would anyone choose them for feature flags.
[flagged]
I don’t have experience with the tools Cloudflare has been shipping this year so I can’t speak about the quality, but they have really been pushing out a lot new products and services, no doubt due to agentic coding.
This is what "Building for the future" looks like post-layoffs, huh?
Can't even ship with app-scoped tokens...
a flagship with no pirates, all fired due to ai.
I love their free tier but for playful stuff
I like the name
Fix your stupid Turnstile that blocks humans first. You are gatekeeping the whole Internet. Even Anubis works better than the Clownflare garbage.
I love direction and features Claudflare is taking, they are really impressive. And since I use their service on several projects, I can say I am overall very happy with service.
Only thing, they are going strongly in AWS territory and not in any good way. Finding what I need and what I use has become harder as times go by. By contast, Azure (MS) even though it looks crazy complex, once you get used to it, you can find things.
is it similar to vercel flags?
Am I the only one worried about Cloudflare becoming too powerful?
We went through this with E-mail: we slept through the period when Google, Microsoft and AWS were growing, and we ended up with them dictating the terms. Today I get 90% of my spam from Google, Microsoft and AWS and they don't care: they can safely ignore spam reports, because at this point they are Too Big to Block.
I have a feeling we are moving towards the same problem with Cloudflare and the web. Tomorrow Cloudflare will start dictating what we can or cannot do and we will not be able to do anything about it. This has already begun: their arbitrary "bot-filtering" for example.
Cloudflare is already too powerful, their anti DDOS solution is just too good. But their serverless products/features don't really build on that, they are just another hosting company.
> Am I the only one worried about Cloudflare becoming too powerful?
No, it gets brought up in every single thread about cloud flare. And if this wasnt a feature release that people seem to like, the top comment would probably be talking about how cloudflare is terrible for the internet.
[dead]
[flagged]
[flagged]
Feature flags are so ridiculously simple I have never needed to outsource this to someone else.
Do your running services receive streaming updates when Flags are toggled? Is your rule-engine evaluated locally?
[dead]
[dead]