mrvitej.in
Happy Dussehra! May good always win. Happy Diwali! Wishing you a bright year ahead. Merry Christmas! Warm wishes from Vizag. Happy New Year! Here’s to a great year ahead.

DevOps · CNCF daily

GO Feature Flag: Feature Flags as a File, with OpenFeature and No Database

NON CNCF, listed in the CNCF Landscape. A self-hosted, MIT-licensed feature flag solution where flags live in a file in Git, S3 or a ConfigMap and are evaluated in memory by a Go library or a relay proxy with OpenFeature providers.

8 min read

NON CNCF

  • GO Feature Flag
  • OpenFeature
  • Go
  • Git
  • Kubernetes
CNCF Landscape page

GO Feature Flag is a self-hosted, open source feature flag solution built on OpenFeature. Instead of a server with a database and an admin console, you keep your flags in a single file (YAML, JSON or TOML) in Git, an object store or a Kubernetes ConfigMap, and GO Feature Flag loads it into memory and evaluates it. Teams can use it as a Go module inside a Go service, or run a relay proxy that offers an HTTP API so services in any language ask for flag values through OpenFeature providers. It suits teams who want flags reviewed like code: a rollout change is a pull request. It is a NON CNCF tool: the CNCF Landscape lists it under Observability and Analysis › Feature Flagging, but it is not a CNCF project. It is maintained by Thomas Poignant, calls itself part of the OpenFeature ecosystem and uses the MIT licence.

CNCF daily · Sprint 3, post 21 of 21 · Feature Flagging · NON CNCF

At a glance
Category Observability and Analysis › Feature Flagging
CNCF status NON CNCF, listed in the CNCF Landscape
Written in Go
License MIT, with no paid enterprise tier
Flag format YAML, JSON or TOML with variations, targeting rules, percentage rollouts and a default rule
Retrievers File, HTTP, GitHub, GitLab, Bitbucket, S3, Google Cloud Storage, Azure Blob Storage, Kubernetes ConfigMap, MongoDB, PostgreSQL
Exporters S3, GCS, Azure, Kafka, Kinesis, Pub/Sub, SQS, BigQuery, OpenTelemetry, webhook, file and log
Notifiers Slack, Microsoft Teams, Discord and webhook
OpenFeature providers Go, Java/Kotlin, JavaScript/TypeScript, Python, .NET, Ruby, Swift, PHP and Rust (through OFREP)
Admin UI None at runtime; management is by file and Git, with a web editor to author and validate configuration
Latest release v1.55.2 (18 August 2026); v1.55.0 added runtime flag sets and a BigQuery exporter

Architecture

GO Feature Flag architecture: a developer pushes a flag file to Git; a retriever in the relay proxy and in an embedded Go library polls the file and keeps the flags in memory; applications using OpenFeature SDKs evaluate flags through the relay proxy; the proxy exports usage events to storage such as S3, BigQuery or Kafka and announces flag changes to Slack, Teams or a webhook

Blue is the developer, slate the applications and storage, purple GO Feature Flag. The flag file is the single source of truth; there is no database in the picture. Open the zoomable diagram, or download it as SVG or PNG.

Component Responsibility
Developer Edits the flag file and opens a pull request.
Flag file in Git Holds flags, variations, targeting rules and rollout percentages. Other retrievers read the same file from S3, GCS, HTTP or a ConfigMap.
Go service (library) A Go application that embeds the module, polls the file and evaluates flags in process.
Any application Uses an OpenFeature SDK and a GO Feature Flag provider to ask the relay proxy for a decision.
Relay proxy A hostable service that keeps the flags in memory and exposes an HTTP API, including OFREP, the OpenFeature remote evaluation protocol.
Exporter target Receives batched evaluation events for analysis.
Notifier Announces flag changes to Slack, Teams, Discord or a webhook.

Design principle. Treat flags as configuration under version control. Reviews, history and rollback come from Git, and the runtime stays stateless and simple to run.

Request flow

GO Feature Flag flow in five steps: a developer merges a flag change in Git, the relay proxy polls the file and reloads it, the notifier announces the change to Slack or a webhook, an application asks the relay proxy to evaluate a flag and gets a variation, and the proxy exports batched usage events to storage

  1. Merge a change. A developer changes a rollout percentage in the flag file and merges the pull request.
  2. Poll and reload. The relay proxy polls the retriever at its interval, notices the new file and reloads the flags in memory.
  3. Announce the change. The notifier posts a summary of what changed to Slack, Teams or a webhook.
  4. Evaluate. An application sends a flag key and an evaluation context (a targeting key and attributes) to the proxy and gets back a variation, or its default value if evaluation fails.
  5. Export events. The proxy batches evaluation events and sends them to the exporter target, for example S3, Kafka or BigQuery.

Open the zoomable flow diagram, or download it as SVG or PNG.

Production reference design

This Sprint 3 design runs the relay proxy in the cloud cluster on Google Compute Engine (self-managed Kubernetes with Calico) with one flag repository for the whole multi-cluster platform. Edge clusters either run their own proxy or call the central one.

  1. Create the flag repository with a pull request review rule and a CI check that validates the file.
  2. Write the flag file: 
    new-checkout:
  variations:
    on: true
    off: false
  targeting:
    - query: email co "@example.com"
      percentage:
        on: 100
        off: 0
  defaultRule:
    percentage:
      on: 20
      off: 80
    Internal users always get on; for everyone else, 20% of users do.
  3. Deploy the relay proxy (the gofeatureflag/go-feature-flag image, port 1031) as a Deployment with a proxy configuration file and the flag file mounted. In Kubernetes you can mount the flags in a ConfigMap and use the configmap retriever, or read from Git or (GCP) Google Cloud Storage.
  4. Set a polling interval that suits you, and put two or more replicas behind a Service.
  5. Use the OpenFeature SDK in each application with the GO Feature Flag provider, and set sensible default values in code.
  6. Add an exporter and a notifier, for example BigQuery (GCP) or Kafka for events and a Slack channel for changes.
  7. Protect the proxy. Keep it inside the cluster, use its authorised keys, and restrict who can merge to the flag repository.

Typical uses include gradual rollouts, internal-first releases, kill switches, A/B tests with exported events and the same flag logic for services in several languages.

Operational considerations

  • No admin UI. Non-developers cannot flip a flag from a console. If product managers need that, consider Unleash or a hosted service, or provide a simple pull request workflow.
  • Polling delay. Changes reach the proxy at the polling interval, not instantly. Choose the interval to match how fast you must disable a bad flag, and test the kill-switch path.
  • File size and structure. One large file becomes hard to review. The project supports flag sets, which v1.55.0 can add and remove at runtime without a restart.
  • Consistency across replicas. Each proxy replica polls independently, so a change can briefly differ between replicas.
  • Defaults matter. If evaluation fails, applications get the default value in code, so choose safe defaults.
  • Single maintainer. The project is led by one maintainer and funded by sponsors. Check the repository’s release cadence and your support needs.
  • Security fixes. Recent releases updated Go and dependencies to address CVEs. Pin and upgrade deliberately.

Adoption

  • The repository’s README does not name adopters; it links to an ADOPTERS.md file and invites organisations to add themselves. Check that file for current users before you rely on it.
  • The README shows sponsors including Swisscom, Cybozu and AltaModa Technologies. Sponsorship is not the same as production use, so these are not claimed as adopters.
  • The project positions itself as part of the OpenFeature ecosystem; see the OpenFeature brief for the CNCF project it builds on.

Alternatives

Solution Model Best suited to
OpenFeature (CNCF Incubating) Vendor-neutral flag evaluation API The API layer in front of any flag backend; see the OpenFeature brief
Unleash Server with database and admin UI Teams that want a console for non-developers; see the Unleash brief
flagd OpenFeature-native evaluation daemon Kubernetes setups using the OpenFeature operator
Flipt Self-hosted flag service with UI A simple server with a UI and Git sync
LaunchDarkly Commercial hosted platform Enterprises that want managed targeting and experimentation

Strengths and limitations

Strengths Limitations
Flags are reviewed, versioned files with no database to run No runtime admin UI
MIT licence with no paid tier NON CNCF, with a single lead maintainer
OpenFeature providers for many languages Changes arrive at the polling interval
Many retrievers, exporters and notifiers No named adopters listed in the README
Works as a Go library or a stateless relay proxy Large single files need discipline to keep reviewable

Recommendation

Trial for engineering-led teams that already work in Git and want simple, self-hosted flags with OpenFeature, particularly on Kubernetes where a ConfigMap or Git retriever fits. Start with one service and one percentage rollout, test the kill-switch delay, and use OpenFeature SDKs in the application so you can change backends later. Teams that need a console for non-engineers should look at Unleash.

References: GO Feature Flag website · GO Feature Flag repository · Releases · Go package documentation · CNCF Landscape entry

Spotted something wrong or out of date?Suggest a correction. I review every suggestion before changing the page.