Thomas Poignant, creator of GO Feature Flag, has been elected to the OpenFeature Governance Committee for the 2026-2028 term. This is a milestone to be genuinely proud of — and one that feels like a natural continuation of the work done at the intersection of GO Feature Flag and the OpenFeature ecosystem.
KubeCon + CloudNativeCon Europe 2026 in Amsterdam is behind us, and what a week it was. For GO Feature Flag, it was both an opportunity to represent the project on a big stage and to connect directly with the community in person.
We are excited to introduce in-process evaluation for the GO Feature Flag OpenFeature server providers: Go, Java, .NET, Python, JavaScript, and TypeScript.
This capability is designed to improve evaluation performance and drastically reduce network traffic between your applications and the relay-proxy.
Previously, when you used the OpenFeature providers we ship, evaluation used remote evaluation: each flag evaluation triggered a network call to the relay-proxy.
That model fits many setups, but it is not always the most performant or resilient way to evaluate feature flags on hot paths.
That is why we are launching in-process evaluation mode for our most widely used providers.
We're excited to announce a new feature in GO Feature Flag that makes API key management easier and more secure: Runtime API Key Updates! 🎉
We've heard from the community that having to restart the relay proxy for every API key update or rotation was a real pain point. Managing API keys is crucial for security, but needing a restart for each change led to unnecessary downtime and interruptions.
With this new feature, you can now update, rotate, and manage API keys on the fly—your relay proxy keeps running, and requests are served continuously, with no need for restarts.
We’re proud to announce that Grafana, one of the world’s most popular observability platforms, is now using GO Feature Flag as a dependency in their project! 🚀
(Screenshot from Grafana’s go.mod file showing GO Feature Flag)
This is a huge milestone for us. Grafana is one of the most widely used observability platforms in the world, relied upon by countless developers and organizations to monitor and visualize their systems. Seeing such a respected open-source project adopt GO Feature Flag is a strong validation of the reliability, performance, and simplicity of our solution.
A big thank you to our community and contributors for making this possible — and to the Grafana team for trusting our solution. ❤️
Here’s to safer rollouts, faster innovation, and more great open-source collaborations ahead! 🚀
We’re incredibly proud of this milestone, but it’s only the beginning. GO Feature Flag continues to evolve, and we’re committed to making it even easier for teams of all sizes to roll out new features with confidence.
If you’re curious about how GO Feature Flag can fit into your projects, check out our documentation or join our community. We’d love to hear from you!
We're excited to announce that we have released one of the most requested feature for GO Feature Flag.
It will revolutionize how you organize and manage your feature flags: Flag Sets! 🎉
As your applications grow and teams expand, managing feature flags can become increasingly complex. Different teams need their own flags, environments require separate configurations, and multi-tenant applications demand isolated flag management. That's exactly what Flag Sets are designed to solve.
We're excited to share that Thomas Poignant, creator of GO Feature Flag, presented an insightful talk at PlatformCon 2025 about decoupling deployments from feature releases using OpenFeature.
In this presentation, Thomas explores how traditional deployment strategies often directly couple feature releases with code deployments, increasing risks and slowing time-to-market. He demonstrates how OpenFeature, a vendor-agnostic API for feature flagging, enables developers to separate feature releases from code deployments, providing precise control over feature visibility and experimentation.
This blog post dives into a new functionality introduced in the GO Feature Flag provider for OpenFeature: exporter metadata. We'll explore how it works and how you can leverage it to enrich your evaluation events with valuable static information.
Exporter metadata is an object you can configure when initializing your GO Feature Flag provider for OpenFeature.
It allows you to specify a set of static information that you want to consistently include with all your evaluation events. A good example of information you might include in exporter metadata is the environment in which your application is running, the version of the application or anything that helps you when you analyze your evaluation data.
This data is then forwarded to the exporter and incorporated into your feature events as a new field called metadata.
Until Today the java provider, used the guava cache to store the flags and the segments. Using the guava cache is now discouraged by the guava team.
In order to follow the guidance of the guava team, we have decided to migrate the internal cache of the Java provider from guava to caffeine.
This may create a breaking change for you if you were using a custom cache configuration with the guava cache in your provider.
Because of this, the cache configuration on GoFeatureFlagProviderOptions that used Guava's CacheBuilder is now handled by Caffeine.
We're excited to announce significant improvements to the integration between GO Feature Flag and OpenFeature.
To better serve our users' diverse needs, we've decided to split the previous Go provider into two distinct providers:
go-feature-flag: For use with the GO Feature Flag relay proxy.go-feature-flag-in-process: For direct integration of GO Feature Flag into your application.