I've done some follow-up searching here: gitlab-org/quality/quality-engineering/team-tasks#4330 (comment 3167240821)

It looks like https://www.flipt.io/ might be a better alternative in the short term - I'll start pulling on this thread now and see about getting something deployed to Runway for testing.

We'll need Runway setup regardless of what path we walk down, so this at least allows us to make some progress. If Flipt proves to be a bad decision, we can hopefully swap out to Flagd or something similar quite easily.

This is a nuanced licensing situation — worth knowing the full picture. Here's what's going on:

Flipt v1 vs v2 have different licenses. This is the key wrinkle.

In v1, there were two license types: the server code was under GPL 3.0, while all client code (gRPC clients, Go SDK) was under MIT. GitHub GPL 3.0 on the server is generally acceptable for internal self-hosted use, but some organisations have blanket policies against it, and it can create complications if the server code is ever modified and redistributed.

Flipt v2 has moved to the Fair Core License (FCL). The Fair Core License is a Fair Source license specifically designed for self-hosted software that balances developer sustainability with user freedom — it's a mostly-permissive non-compete license that eventually transitions to open source after 2 years. For most users and organisations, Flipt v2 can be used freely in commercial environments. The restrictions primarily apply to companies wanting to compete directly with Flipt's business model. Flipt

Critically, all Flipt SDKs and client libraries remain MIT licensed, ensuring your application code using Flipt SDKs has no licensing restrictions and you can integrate Flipt into commercial applications freely. Flipt

What this means for GitLab specifically:

The FCL's non-compete clause is the thing to flag. GitLab doesn't sell a feature flag product, so there's no meaningful conflict there. But it's worth a quick legal check given GitLab's scale and open-source commitments — some organisations prefer Apache 2.0 or MIT for all dependencies, and FCL is a newer, less battle-tested license.

If that's a concern, GO Feature Flag is fully Apache 2.0 licensed and might be a safer pick from a licensing hygiene standpoint, even if it lacks the UI.

Want me to check GoFF's license and see how it compares end to end?

Feature Flag "Research":

FlagD is the reference implementation for OpenFeature — it was initially conceived as a reference implementation for an OpenFeature backend, but has since become a powerful tool in its own right. Flagd Its key strengths are that it's extremely flexible — you can leverage it as a sidecar alongside your application, an engine running in your application process, or as a central service evaluating thousands of flags per second. Flagd It also has a powerful and flexible rule targeting engine, deterministic percentage-based rollouts, and flag evaluation traces and metrics compatible with OpenTelemetry. GitHub

The critical caveat for your use case: it doesn't include a UI, management console, or a persistence layer — it's configurable entirely via a POSIX-style CLI. Flagd That's fine for platform engineers, but if the goal is to unblock another team and give them self-service flag toggling, flagd alone won't cut it without you building a workflow around it.

The three strongest alternatives are below, and I've put them side by side in a comparison widget.

Flipt is a self-hosted, Git-native platform written in Go. It delivers feature flags through a single binary that fits naturally into containerized environments, with a stateless architecture and database-agnostic design. Statsig It has an official OpenFeature provider, and is one of the early adopters of the OFREP protocol. Flipt Crucially, it ships with a full UI — giving another team genuine self-service. It supports both HTTP(s) and gRPC transports and includes hooks for custom actions. Platform Engineers

GO Feature Flag (GoFF) is the most minimal option. Its core feature is to centralise all your feature flags in a single file and avoid hosting and maintaining a backend server to manage them. GitHub It exposes a relay proxy for multi-language use, and has 82% official OpenFeature SDK coverage — leveraging OpenFeature exclusively rather than proprietary SDKs. DevCycle Blog Ideal if you want file-based flags with minimal infra, but again lacks a UI.

Flagsmith is heavier but production-battle-tested. It's a founding member of OpenFeature with native SDK support, and lets you write your feature flag code once and switch providers without code changes. Flagsmith It has a proper UI, self-hosted or cloud options, and supports remote config and multivariate flags — but it's meaningfully more infrastructure than the others.

Bottom line for your specific need

If the goal is to unblock another team with self-service flag toggling quickly, Flagd alone isn't sufficient — its lack of a UI means someone (you or your team) becomes the operator, which defeats the purpose.

Flipt is the strongest match here. It's lightweight like flagd, written in Go, ships as a single binary, is fully OpenFeature compliant (and an OFREP early adopter), has a proper web UI for the other team to self-manage flags, and integrates cleanly with GitOps workflows which aligns well with how GitLab operates. A team could be unblocked within an afternoon.

GO Feature Flag is worth considering if you're comfortable with flags being managed as files (YAML) via MRs — it has the broadest OpenFeature SDK coverage and lowest operational overhead, but it's really a platform engineering tool, not a self-service one.

Flagsmith is the right answer if requirements grow (A/B testing, segments, remote config) but is overkill for a simple "let us toggle flags on our services" ask.

Want me to dig deeper into Flipt's deployment model and how it would integrate with Runway or existing GitLab infra?

What does this MR do?

Remove all logrus/labkit v1 log references, migrate to slog/labkit v2

Replaces all remaining uses of labkit v1 (logrus-based) logging with slog via labkit v2/log, using typed helper functions (logv2.Error, logv2.CorrelationID, logv2.HTTPHost, etc.) for structured attributes.

Co-Authored-By: Claude Sonnet 4.6 [email protected]

TODO

• Feature flag
  • Added feature flag:
  • This feature does not require a feature flag
• I added the Changelog trailer to the commits that need to be included in the changelog (e.g. Changelog: added)
• I added unit tests or they are not required
• I added acceptance tests or they are not required
• I added documentation (or it's not required)
• I followed code review guidelines
• I followed Go Style guidelines

Elliot Forbes (3da22cda) at 17 Mar 14:34

... and 11 more commits

What does this MR do?

Remove all logrus/labkit v1 log references, migrate to slog/labkit v2

Replaces all remaining uses of labkit v1 (logrus-based) logging with slog via labkit v2/log, using typed helper functions (logv2.Error, logv2.CorrelationID, logv2.HTTPHost, etc.) for structured attributes.

Co-Authored-By: Claude Sonnet 4.6 [email protected]

TODO

• Feature flag
  • Added feature flag:
  • This feature does not require a feature flag
• I added the Changelog trailer to the commits that need to be included in the changelog (e.g. Changelog: added)
• I added unit tests or they are not required
• I added acceptance tests or they are not required
• I added documentation (or it's not required)
• I followed code review guidelines
• I followed Go Style guidelines

Elliot Forbes (3b2289bb) at 17 Mar 14:31

Elliot Forbes (71639d4b) at 17 Mar 14:27

Just an update on this: I've talked to João and collated some of the discussions here: gitlab-org/quality/quality-engineering/team-tasks#4330

Given that it's also OpenFeature compliant, I'm happy to walk down this path, given that it does lend itself better to local testing.

@chsanders / @amyphillips - Would you be happy to give us the go-ahead to walk down the Flagd path for now, given that this does give us the flexibility to switch it out at some point in the future?

What does this MR do?

Revert "Merge branch 'malvarez-consolidate-http-status-code-field' into 'main'"

This reverts merge request !6492

Why was this MR needed?

The previous changes changed the type of the logging field status from String to Integer. This was pointed out to have the risk of causing type conflicts: Slack (internal) & https://opster.com/guides/elasticsearch/glossary/elasticsearch-conflicting-field/

We are reverting the changes to first figure out the necessary type mappings.

What's the best way to test this MR?

What are the relevant issue numbers?

Summary

Migrates GitLab Workhorse's logging stack from labkit v1 (logrus-backed) to labkit v2 (slog-backed), replacing the logrus dependency with Go's standard `log/slog` throughout the service.

What changed:

• `internal/log/logging.go` — rewritten: `Builder` now wraps `*slog.Logger` instead of `*logrus.Entry`; `Fields` is `map[string]any`; `WithError` guards against nil; `Fatal` calls `os.Exit(1)` explicitly; new `WriterFromContext` helper
• `cmd/gitlab-workhorse/logging.go` — rewritten: `startLogging` / `getAccessLogger` now return `(*slog.Logger, io.Closer, error)` and call `slog.SetDefault()` to set the process-wide logger
• `internal/upstream/upstream.go` — `accessLogger` field changed to `*slog.Logger`; added `correlationBridge` middleware that reads the labkit v1 correlation ID and stores it as a labkit v2 context field so slog's `ContextHandler` includes it in every log record
• `internal/loadshedding`, `internal/healthcheck` — `*logrus.Logger` → `*slog.Logger` throughout
• All files using `labkit/log` directly (artifacts, channel, sendfile, upload, dependencyproxy, listener, upstream routes, etc.) — replaced with `log/slog` calls
• `internal/helper/exception` — `Track()` signature updated from `log.Fields` to `map[string]any`
• Tests updated to match slog text format (uppercase levels, `msg` field always present, unquoted simple-value URIs, `error_message` key)

What stays on labkit v1:

• `correlation`, `fips`, `mask`, `metrics`, `monitoring` packages — labkit v2 has no equivalents; retained as-is
• `gitaly.InitializeSidechannelRegistry` — requires `*logrus.Logger` (external Gitaly API); `logrus.StandardLogger()` is still passed there

Test plan

• `go build ./...` — clean
• `go test ./internal/log/...` — all pass
• `go test ./internal/transformers/...` — all pass
• `go test ./internal/loadshedding/...` — all pass
• `go test ./internal/healthcheck/...` — all pass
• `go test ./internal/upstream/...` — all pass
• `go test ./cmd/gitlab-workhorse/...` — all pass
• All 33 non-infrastructure-dependent packages pass; only `circuitbreaker` (requires Redis socket) and `ai_assist/duoworkflow` (requires external service) fail — both are pre-existing and unrelated to this change

🤖 Generated with Claude Code

Elliot Forbes (13f9c2a0) at 17 Mar 10:50

... and 1 more commit

@vyaklushin - pipeline's back to green, let me know if there is anything further needing done 🏓

Summary

Add additional CODEOWNERS to reduce bus-factor risk.

Proposed reviewers: @reprazent @ayeung @fforster @e_forbes @pguinoiseau @amknight

Related: mstaff#529