What is the difference between GitLab and Unleash feature flags?

There’s a decent chance you shipped your first feature flag without ever deciding to adopt a feature flag system. If your team used GitLab somewhere around 2019, you may have opened Operations > Feature Flags, typed a name, flipped a toggle, and pointed an SDK at a URL that ended in /api/v4/feature_flags/unleash/<project-id>. It worked. No new vendor, no new bill, no new thing to run.

And here’s the part a lot of people have not realized: that flag was powered by Unleash. GitLab’s feature flags have been built to be compatible with the open-source Unleash engine since the start. So if you’ve been using them, you’ve quietly been an Unleash user for years, you just may never have looked at Unleash on its own.

We would like to invite you to catch up by providing a bit of history for context, because the platform that integration was modeled on has come a long way since.

Where this started

GitLab added Feature Flags in 11.4, back in October 2018. The framing at the time was purely around continuous delivery: incremental rollouts, separating feature delivery from customer launch, shipping in smaller batches. Classic, correct, and exactly the pitch you’d expect from a platform whose whole identity is “the entire DevOps lifecycle in one place“.

The detail that matters for this story: GitLab didn’t build a flag engine from scratch. They built on Unleash, the open-source feature toggle service. As their own docs put it plainly: GitLab uses an Unleash-compatible API for feature flags, that is compatible with Unleash clients. Your application talks to GitLab using a standard Unleash SDK. GitLab plays the role of the Unleash-compatible server, and the official Unleash clients do the evaluating.

From there the capability grew, release by release:

• In 11.7 feature flags became environment-aware, so a flag could behave differently in staging than in production.
• In 11.9 flag changes started landing in the GitLab audit log: who changed what, and when.
• In 12.2 the strategy set expanded: percentage rollout by authenticated user, plus target-user lists.
• In 12.6 target users could be scoped per environment.
• In 13.1 the reusable user lists arrived.
• In 13.5 the flexibleRollout strategy landed, and the whole feature became available in GitLab Free.

That last line is the one to sit with. In 13.5 (October 2020, 6 years ago), feature flags stopped being a paid-tier perk and became available to every GitLab user, all the way down to the Free tier.

It’s a generous move that encourages customers to actively benefit from feature flagging practices. A very large population of teams suddenly had access to a working, audited, environment-aware feature flag system, built on top of open source Unleash standard, integrated into a tool they already use every day. However, depending on the tier, you may face limits around your usage patterns. Customers report that rate limiting and an upper limit on the actual number of flags are the most pressing issues.

This is the beauty of open source

We want to be clear about how we feel about this, because it’s genuinely one of our favorite things about building on an open-source foundation.

GitLab chose an open standard instead of inventing a proprietary one. Because GitLab spoke the Unleash client protocol, developers didn’t have to learn a bespoke API or adopt a one-off SDK. You reached for the same unleash-client-go, the Ruby unleash gem, or any other Unleash SDK you’d use anywhere else, and pointed it at GitLab. Flag definitions were fetched once, cached in memory, and evaluated locally on every isEnabled() call. No network round-trip per check, graceful fallback to cached rules if the network hiccuped, and no end-user data leaving your infrastructure to make a decision. That’s the Unleash SDK architecture, working exactly as intended.

GitLab didn’t have to ask for permission, negotiate a partnership, or wait for a roadmap. The engine was open, the protocol was documented, and the SDKs were battle-tested. So they built on all of it. That’s the deal open source offers, and it’s a deal we’re happy to have made good on.

Every team that flipped a GitLab flag was running on the same foundation that today powers production at Lloyds Banking Group, Prudential, Wayfair, and VISA. Over 45M downloads and 13k+ GitHub stars didn’t come from marketing. They came from a foundation solid and generous enough for platforms and providers like GitLab to stand on.

So this isn’t a story about a wrong turn. That integration gave a lot of engineers their first hands-on feature flag experience – often on Unleash, before they’d heard the name – and that’s worth acknowledging.

What the last several years added

Here’s the thing about a snapshot: the subject keeps moving after the shutter clicks.

GitLab’s feature flags capture what feature flagging looked like around 2018-2020. They implement an early generation of the Unleash strategy model: default, gradualRolloutUserId, flexibleRollout, or userWithId. That model has stayed essentially stable in GitLab ever since.

Meanwhile the Unleash project kept evolving. Two major versions and years of steady, customer-driven innovation later, the open-source platform has moved well past the generation GitLab modelled and now sits at Unleash 8.0.

None of that is a criticism of GitLab. It reflects a difference in the approach: GitLab’s flags are a tactical feature flagging tool – one capability inside a DevOps platform, there to help you decouple deploy from release and move on.

What Unleash became is a strategic investment in a FeatureOps control plane: feature management as a discipline in its own right, not a checkbox in a pipeline. Both are legitimate. They’re just aimed at different things, and a lot of value has accrued to the second aim since the snapshot was taken.

We believe it’s worth knowing what’s new. Let’s start with the things developers bump into almost immediately:

• Variants: GitLab’s flags are on/off. Unleash variants let one flag serve multiple versions, supporting A/B/n experimentation. With configurable weights and payloads, which is what turns a flag from a switch into an experiment.
• Advanced targeting constraints: Beyond the handful of built-in GitLab strategies, Unleash lets you target any attribute you define (driven by custom context fields). Not “the four strategies shipped by the vendor“, but “whatever your business actually segments on“.
• Reusable segments: In GitLab, targeting rules mostly live per flag – with one exception: user lists, which are used to define reusable lists of targeted users by their identifiers. Unleash segments are a more flexible version of that. They are driven by advanced targeting constraints and custom context fields, allowing you to define targeting by any attribute or combination of them: geography, paid plan, tenant, or arbitrary telemetry. After that, you can reuse segments across all flags and projects (since both can be defined at the instance level and scoped to a specific project), so your targeting stays consistent rather than copy-pasted.

The 3 points above would be immediately visible to the teams using GitLab’s version. Then there’s the newer layer of capability – the stuff that arrived as Unleash grew from a toggle service into an enterprise-ready FeatureOps platform. FeatureOps is the discipline of controlling how software behaves in production rather than just flipping it on and off.

Here’s what’s new:

• Release templates: Define a reusable, multi-stage rollout blueprint once – internal users, then 10%, then 50%, then 100% – and apply it as an executable plan, consistently across features and teams. No more hand-driving every rollout.
• Automatic progression with safeguards: You define a business or technical metric, set thresholds e.g., on error rate or latency – and Unleash advances the rollout when production signals stay healthy and disables a specific feature in a given environment or pauses progression instantly when a metric drifts. No one has to babysit a dashboard at 3 AM.
• Impact metrics: Even though GitLab’s Unleash-compatible endpoint could receive evaluation metrics from the SDKs, those metrics were never displayed on any dashboard or in any API response. Seeing how many times your flag got evaluated is genuinely useful telemetry, and Unleash has that – but it’s just a starting point. Our proposal goes further by allowing you to tie a flag to any metric (business or technical) e.g., request rates, error counts, and latency percentiles. These are collected from your application, then visualised in the feature flag context and fed back into the release plan and safeguards. It’s the difference between “the flag fired” and “firing it made an impact on your business“.
• Flag types and lifecycle: Organize flags by intent: Release, Experiment, Operational, Kill Switch, Permission – with searchable tags and a project health dashboard that surfaces flags in a specific lifecycle. For example, accumulated unreleased features, or released but not removed flags that became technical debt. In Unleash 8.0 we have added one more that’s easy to underrate: Sunset, a flag type built specifically for retiring a feature safely. Instead of ripping code out and hoping, you wrap the feature you plan to remove, then gradually disable it for selected segments while watching the impact – and pause or re-enable if something downstream breaks. It’s the same targeting and gradual-rollout machinery you’d use to launch a feature, pointed at the far end of the lifecycle. Offboarding a feature is finally as controlled as shipping one.
• Enterprise-grade governance: Change requests for the four-eyes principle, granular role-based access, and audit logs built to answer “who released what, when, and to whom” for frameworks like SOC2 and ISO27001.
• Enterprise Edge: Low-latency evaluation across many cloud regions with real-time streaming and multi-region redundancy. Unleash Enterprise Edge supports a different scale story than GitLab’s rate-limited, unauthenticated flag endpoint. GitLab’s own docs steer real workloads toward an Unleash proxy in front of it – which is an earlier work that evolved into the current Enterprise Edge offering.

That’s not a list of GitLab’s shortcomings. It’s the result of many years of product vision and execution, treating feature management as a strategic engineering practice that creates the competitive edge for our customers.

We’d love to show you around

The point of this post is simple: you may already be an Unleash user thanks to GitLab. However, Unleash in 2026 is a much bigger platform than the one your GitLab flags were modeled on. The heritage is real, the open-source foundation is the same, and that shared lineage is exactly why exploring it further is a short trip rather than a leap.

If any of the capabilities above made you think “I’ve actually wanted that” we’d genuinely love to show you what the platform grew into: variants for a real experiment, segments so you stop copy-pasting targeting, no more hand-driving releases, safeguards so nobody babysits a rollout.

This is an open invitation to come take a look, as you already know the foundation. Sign-up for a free trial. Evaluate it by yourself – and read the follow-up post. It highlights what stays the same, what changes, and how to make the jump without a rewrite.