Voxxed Days Luxembourg is proud to welcome Alexei Bratuhin for the talk: "OpenFeature -- one flag to rule them all"!
Be sure to check the details on the schedule app:
m.devoxx.com/events/voxxedlu…
and favourite if you‘d like to see it! ⭐
26
Jun 12
🚀 Wir sind JETZT LIVE!
Feature Flags ohne Chaos: Heute geht’s um OpenFeature, typische Stolperfallen und wie Feature Flagging wieder Spaß macht.
Mit Star-Gast Simon Schrottner – und am Ende wartet unser Quiz mit Buch-Gutschein! 📚
Jetzt einschalten 👉 twitch.tv/GregorBiswanger
1
67
Feature Flags sind genial.
Bis sie keiner mehr aufräumt. 😅
Am Freitagabend schauen wir live mit Simon Schrottner auf OpenFeature:
✅ weniger Flag-Chaos
✅ weniger Vendor Lock-in
✅ sauberere Software Delivery
Wie entfernt ihr alte Feature Flags?
#OpenFeature #DevOps
2
54
May 29
couldn’t have explained it better myself. @jamesqquick nailed the full Flagship flow here.
the part I’m happiest we got right in Flagship: flag evaluation never throws. that one’s really thanks to @openfeature, whose spec bakes safe fallback to a default right into evaluation.
at @dyte_io we took down prod more than once because a flag check failed and there was no safe fallback. learned the hard way that the flag system should never be able to break your app.
May 29
Cloudflare just launched Flagship in public beta, so here's a workflow for safely shipping a new AI transcription feature behind a flag in 7 steps.
The twist, though, is that we’ll use a JSON object as the flag value instead of a plain boolean. 🧵
3
14
1,187
May 27
missed this but nice to see Google supporting and using @OpenFeature "ALM FF is built on the OpenFeature standard, utilizing industry-standard SDKs and the flagd evaluation engine. This ensures your feature management patterns are portable and follow best practices without adding Google-specific dependencies to your core application code" cloud.google.com/blog/produc…
1
3
345
Simon Schrottner is now discussing feature flags and OpenFeature at #JNation.
#Java #DevOps #Architecture #Coimbra
2
4
225
May 26
The wait is over. Flagship is in open beta ⛳️🚢
Feature flags, built on Cloudflare’s network, with OpenFeature support.
This is the first product I’ve worked on end-to-end after joining @CloudflareDev, so I’m extra excited for people to finally try it.
If you’re building with flags, try it out. would love your feedback!
May 26
cloudflare now has a built-in feature flag service 🏁
flagship enters public beta today, and you can integrate it into your workers apps already deployed on @CloudflareDev, or deploy a worker in front of your app to do feature flipping and more w/o any additional config (read on!)
there's a simple binding api (env.FLAGS w/ <10 methods, easy for your agents to pick up):
env.FLAGS.getBooleanValue - return basic boolean values, like "is this flag set or not?"
but you can also do some funky stuff like storing objects
env.FLAGS.getObjectValue - return a full JSON object. you can store full configurations and flip per-user or org. neat!
flagship is also openfeature-compatible. the cloudflare/flagship npm package has full support and interoperability with openfeature's sdk. so you can easily swap in flagship from your other providers and trial it
on the setting of flags side - support for booleans, strings, numbers, and json
and for targeting, you can use operators (things like "user_id is equal to xyz") or you can do percentage rollouts. all available in the dashboard.
the dashboard is also quite powerful - you can create flags from the beautiful ui, see where your app is bound (across multiple workers, even!) and there's full analytics. knocked it out of the park
the last thing i'll mention that i think is quite compelling and unique about workers and flagship is something we've talked a lot about in workers/cf land - i don't have a great name for it so i'll call it "originless" behavior.
you can do a "v2-enabled" feature flag and make a fetch request to a totally different host, do URL rewrites etc without any changes to your actual application. eg `isflagEnabled ? fetch(newUrl) : fetch(origin)` - since the worker runs _in front_ of your app, you can do all sorts of behavior w/o ever needing to talk to your origin
quite excited about this release and looking forward to playing w/ it. more on flagship in our changelog: developers.cloudflare.com/ch…
8
6
97
19,039
May 26
cloudflare now has a built-in feature flag service 🏁
flagship enters public beta today, and you can integrate it into your workers apps already deployed on @CloudflareDev, or deploy a worker in front of your app to do feature flipping and more w/o any additional config (read on!)
there's a simple binding api (env.FLAGS w/ <10 methods, easy for your agents to pick up):
env.FLAGS.getBooleanValue - return basic boolean values, like "is this flag set or not?"
but you can also do some funky stuff like storing objects
env.FLAGS.getObjectValue - return a full JSON object. you can store full configurations and flip per-user or org. neat!
flagship is also openfeature-compatible. the cloudflare/flagship npm package has full support and interoperability with openfeature's sdk. so you can easily swap in flagship from your other providers and trial it
on the setting of flags side - support for booleans, strings, numbers, and json
and for targeting, you can use operators (things like "user_id is equal to xyz") or you can do percentage rollouts. all available in the dashboard.
the dashboard is also quite powerful - you can create flags from the beautiful ui, see where your app is bound (across multiple workers, even!) and there's full analytics. knocked it out of the park
the last thing i'll mention that i think is quite compelling and unique about workers and flagship is something we've talked a lot about in workers/cf land - i don't have a great name for it so i'll call it "originless" behavior.
you can do a "v2-enabled" feature flag and make a fetch request to a totally different host, do URL rewrites etc without any changes to your actual application. eg `isflagEnabled ? fetch(newUrl) : fetch(origin)` - since the worker runs _in front_ of your app, you can do all sorts of behavior w/o ever needing to talk to your origin
quite excited about this release and looking forward to playing w/ it. more on flagship in our changelog: developers.cloudflare.com/ch…
15
24
369
72,857
May 17
Ever shipped code that was “done” but impossible to safely activate in production? #OpenFeature helps #Java teams decouple deployments from releases.
Alexei Bratuhin explores rollout strategies, flagd & runtime control patterns: javapro.io/2026/05/14/openfe…
#DevOps @OpenFeature
4
94
May 14
Still redeploying apps just to change runtime behavior? Enterprise pipelines & maintenance windows make that painfully slow. #OpenFeature gives #Java teams cleaner rollouts & runtime control.
Alexei Bratuhin shares patterns you can reuse: javapro.io/2026/05/14/openfe…
@OpenFeature
2
3
138
Apr 30
Un bon système de feature flags, c'est moins de stress au moment des déploiements et plus d'autonomie pour les équipes.
Léopold Jacquot, Principal Engineer, vous explique les 6 raisons qui nous ont convaincus, et pourquoi on a choisi OpenFeature comme moteur dans cet article : engineering.infomaniak.com/w…
1
4
554
『AIエージェント時代の安全装置』
CloudflareのFlagshipは、AIが本番コードに触れる時代の「ブレーキ」です。専門用語でいうとfeature flagですが、考え方はシンプルです。
新しい機能をコードとして本番環境に置いても、最初から全員には見せない。まず自分たちだけ、次に社内だけ、その次に5%のユーザーだけへ出す。問題が起きたら、コードを戻す前にスイッチをoffにする。これがfeature flagの基本です。
なぜ今これが重要なのか。
これまでのAI開発は、AIがコードを書き、人間がレビューし、人間がマージし、人間がデプロイする流れでした。ところが次は、AIエージェントが実装、テスト、デプロイ、動作確認までかなり自律的に進めるようになります。そのとき本当に怖いのは、AIがコードを書くことではありません。未検証の変更が、いきなり全ユーザーへ届くことです。
Cloudflare公式ブログが指摘している問題は、既存のfeature flagサービスがWorkersと噛み合いにくい点です。Workersはユーザーに近いedgeで高速に動く仕組みです。なのにflag判定のたびに外部APIへ問い合わせると、せっかくedgeで処理しているのに、判定のためだけに遠くのサーバーへ往復することになります。
FlagshipはここをCloudflare側に寄せています。設定の正本はDurable Objectsに置き、Workers KVで世界中のedgeへ配り、実際の判定はedgeのisolate内で行う。かなり乱暴に言えば、「機能を出すかどうかの判断そのものを、ユーザーの近くに置く」設計です。
OpenFeatureに対応している点も重要です。OpenFeatureは、feature flagの書き方を特定ベンダー専用にしすぎないための標準インターフェースです。つまり、Flagshipを使っても、コード全体がCloudflare独自の書き方に閉じにくい。入るときも、将来出るときも、痛みを減らしやすい設計です。
できることも実務寄りです。true/falseだけでなく、文字列、数値、JSONをflagの値として扱える。enterpriseプランだけに新機能を出す、特定地域の5%だけで試す、5%から10%、50%、100%へ段階的に広げる、といった運用ができます。同じuserIdなら同じ判定に寄せるので、利用者が新旧画面を行ったり来たりしにくい点も現場では大事です。
医療AIでも、この考え方はかなり効きます。問診導線、説明文、予約フロー、院内業務の自動化。AIが改善案を出す領域が増えるほど、「全部止める」か「全部出す」かの二択では危険です。必要なのは、狭く試し、観察し、問題があればすぐ戻す設計です。
AI開発の本丸は、コード生成の速さから、本番影響をどこまで制御できるかへ移っています。
#AI開発 #クラウド運用 #ガバナンス
1
7
435
めちゃ良い。AIによって機能リリースが加速する中で限定リリースできるように、OpenFeature準拠のフィーチャーフラグ運用を可能にする機能。
Introducing Flagship: feature flags built for the age of AI blog.cloudflare.com/flagship…
2
19
2,011
Apr 19
Cloudflare が出した「Flagship」 というのは、コード自体は本番に置いておきながら、その機能を実際に使わせるかどうかを後から切り替えるための仕組み。
たとえば新しい画面や新しい決済フローを作っても、最初は全員に見せず、自分たちだけ、社内だけ、あるいは 5% の利用者だけに有効化できる。何か壊れたらすぐに off に戻せるので、新機能を安全に試しながら広げていける。
これまでは AI がコードを書いても、人間がレビューしてマージしてデプロイする流れが普通だったけれど、これからは AI エージェントがその一連の流れをかなり自律的に進める未来が来る。そのときに必要なのは、「AI に本番を触らせても、いきなり全員へ影響を出さない安全装置」であり、その役割を果たすのが feature flag だという考え方になる。
記事の中心は、既存の feature flag サービスが Cloudflare Workers とあまり相性が良くなかった、という問題提起にある。外部の feature flag サービスを使うと、ユーザーからのリクエストを処理するたびに別の API へ問い合わせることがある。すると、本来は edge で高速に返せるはずの Workers が、判定のためだけに遠くのサーバーへ行って戻ってくることになり、遅くなってしまう。また、ローカル評価型の SDK も、長時間動き続けるサーバーを前提にしていることが多く、起動と終了が細かく発生する Workers の実行モデルとは噛み合いにくい。
そこで Flagship は、Cloudflare 自身の基盤の上で動くように作られている。設定の正本は Durable Objects に置き、それを Workers KV に世界配布し、実際の flag 判定は edge の isolate でそのまま行う。つまり、外部 API を毎回叩かずに、その場で高速に判定できる仕組みになっている。Cloudflare の説明をかなり乱暴に一言で縮めるなら、「feature flag 判定そのものを edge に住まわせた」ということになる。
もう一つ大きいのは、OpenFeature に対応しているところ。これは CNCF 系の標準インターフェースで、feature flag の評価コードを特定ベンダー専用の書き方に縛られにくくするためのもの。Flagship を使うとしても、コード全体を Cloudflare 独自の API に強く依存させずに済みやすい。入るときも出るときも痛みを減らしやすい、というのが利点になる。
機能面では、真偽値だけでなく文字列、数値、JSON などを flag の値として扱えたり、条件に応じたターゲティングや、ユーザーの一部だけに段階的に公開する percentage rollout に対応していたりする。たとえば enterprise プランのユーザーだけに新機能を出すとか、特定地域の一部だけで試すとか、5% から 10%、50%、100% へと徐々に広げるような運用がしやすい。しかも同じ userId なら毎回同じ判定になるようにして、利用者が新旧画面を行ったり来たりしないようにもしている。
要するにこれは、「AI がどんどんコードを書いて本番へ入れていく時代に向けて、Cloudflare が Workers 向けにかなり相性の良い native な feature flag 基盤を出した」という発表になる。単なる便利機能というより、AI エージェントに安全に本番運用を任せていくための土台を作りに来た、という意味合いが強い。特に Workers を中心に使っていて、今まで flag をコードへ直書きしていたり、外部 flag API の遅さが気になっていた人には、かなり刺さる内容になっておるの🧐✨
Apr 17
Today, we're announcing Flagship - Cloudflare's native feature flag service, built for the AI first world. Read more about it here
blog.cloudflare.com/flagship…
1
8
37
5,294
Apr 17
Flagship fixes this!
Built natively on Workers Durable Objects KV. No outbound HTTP, evaluation in the same isolate serving the request.
OpenFeature-native, so you can swap providers with one line of config. No lock-in!
Read more → blog.cloudflare.com/flagship
Private beta → cloudflare.com/lp/flagship-p…
1
19
3,096
Apr 17
Flagship is Openfeature standard compliant, so you can use it any kind of project actually
1
8
3,430