The feature-flags service is ready for production use

The feature-flags service is now available for production use by any team building services outside the monolith. If your service has ever needed flag state passed down from Rails — coupling your rollout to the monolith’s deploy cycle — this is the replacement: flags as plain YAML in git, live within ~30 seconds of merging, evaluated over an OpenFeature-compatible API and consumed through the LabKit v2 featureflag client.

The service has been validated in production by gitlab-shell, and the paved path is documented end to end:

• Feature flag strategy — when to reach for a flag, the flags-vs-configuration boundary, the cell-based architecture, and the fail-closed rule that keeps services correct when the flag service is absent.
• Use feature flags in your service — the full lifecycle: define the flag in your namespace, wire the client, evaluate with a safe default, toggle with a one-line merge request, delete it when the rollout is done.
• The feature-flags repository — flag definitions, the consuming-flags and managing-flags references, and instructions for running the service locally.
• The go-service-template exemplar — the client initialised, injected, and evaluated as reviewed, working code; read the how-to guide against it.

One rule to carry with you: design for absence. Most environments — including virtually all self-managed installations — will not have the flag service, and your service must behave correctly regardless. Default every evaluation to false and a degraded or missing flag service has zero impact on your users.