Flipt v2 Goes Git-Native: Feature Flags That Branch With Your Code

Every rollout has two halves: shipping code and releasing behavior. For years the second half lived in a vendor dashboard, one click away from a change nobody reviewed, nobody can diff, and nobody can revert except by clicking again and hoping. Flipt v2's answer is to delete that distinction: flags live in your own Git repositories, branch with the code, and release through the same pull-request pipeline as everything else.

Here is the verdict first, with the evidence below. If your team already ships through Git and wants rollout safety without operating another database, the 2026 answer is flags-as-code: Flipt v2 if you want a server with a UI on top of Git, GO Feature Flag if you want the lightest fully-open path. If you need enterprise governance with SSO and fine-grained RBAC today, budget for Unleash or Flagsmith plus their PostgreSQL deployment and paid tier. And whichever you pick, evaluate through OpenFeature, because vendor-neutral flag evaluation is now a first-class selection criterion, not a nice-to-have.

What "Git-native" actually means in Flipt v2​

Flipt v1 was database-centric: flags lived in MySQL, PostgreSQL, or SQLite, and Git was at best a read-only mirror. That made the flag store one more stateful dependency to back up, replicate, and fail over, and it kept the write path in the dashboard, outside code review. V2 inverts the model. The v2 introduction puts it plainly: flags and configuration are stored in your own Git repositories, with a local git-backed store (in memory or on disk) by default and sync to GitHub, GitLab, Bitbucket, Azure DevOps, or Gitea.

The mechanical differences that matter to an operator:

Two rows deserve emphasis. First, environments as branches means staging can literally be a branch of production's flag state, diffed and merged with Git semantics instead of a "copy environment" button. Second, the write path matters more than the storage: v1 could already read flags from Git, but every change still flowed through the dashboard. V2 lets the API and UI write back to the repository, so the Git history becomes the audit trail rather than a second system you reconcile against the real one.

Real-time delivery still works the way dashboard users expect: the server pushes updates to clients over Server-Sent Events, and authentication covers OIDC and token-based schemes. Git-native here does not mean "poll a repo on a cron and hope." It means the source of truth moved into version control while the serving path stayed live.

The honest price tags: license and Pro gates​

Before adopting anything as rollout infrastructure, read the license and the paywall map. Flipt v2 is self-hosted but it is not OSI open source: it ships under the Fair Core License, a Fair Source non-compete license that converts to open source after two years. For a team running flags for its own products, that is close to a non-issue; for anyone dreaming of wrapping Flipt into a competing commercial flag service, it is a hard no.

All SDKs and OpenFeature providers stay MIT licensed, so application code that evaluates flags carries no licensing baggage either way.

The free-vs-Pro table is refreshingly explicit. Free and open components include the evaluation engine, dashboard, multi-environment support, branch environments, Git-backed storage and sync, authentication, and real-time updates. Behind Pro sit the workflow features a platform team will notice first:

• Merge proposals with SCM integration, the automated PR and MR creation that turns a branch diff into a reviewable change request.
• GPG commit signing, the cryptographic verification that makes the Git audit trail compliance-grade.
• Integrated secrets management, the HashiCorp Vault, AWS, GCP, and Azure Key Vault references that keep sensitive values out of flag files.
• Air-gapped support and priority support, plus a Pro license covering up to 10 instances.

This is the familiar commercial-source shape, and the honest read is that the free tier covers the whole flags-as-code loop while Pro sells the governance around it. That matches the broader 2026 market exactly, as the next section shows. Just don't budget zero and then act surprised when the audit-grade signature on every flag commit needs a license key.

The 2026 self-hosted field in one table​

June 2026 produced the most useful buyer's guide this space has had: GO Feature Flag's Best Open-Source Feature Flagging Tools in 2026, updated in September, which weighs OpenFeature posture alongside the usual criteria. Its frame is right: with OpenFeature sitting at CNCF Incubating and the OFREP remote-evaluation protocol standardizing how any SDK talks to any backend, "can we leave without rewriting every call site" is now the question to ask before "does the UI look nice." A second comparison from FlagShark covering Unleash, GrowthBook, Flipt, and Flagsmith lands in the same place on hosting weight.

Three patterns jump out. First, the Postgres divide: the two governance-heavy platforms both require operating PostgreSQL, while every GitOps-shaped option runs databaseless. Second, the paywall divide: advanced RBAC, SSO, and governance consistently sit in paid tiers, which is worth knowing before the compliance review, not during it. Third, the exit-cost divide: OFREP-speaking backends let the same OpenFeature SDKs point at a different server later, which is why the roundup treats OpenFeature support as a 2026 must-have rather than a checkbox.

The production evidence for the GitOps end of the table is accumulating. GO Feature Flag's 2026 case studies include Solaris replacing a custom platform on GitOps, data-residency, and OpenFeature grounds, and DataGalaxy rebuilding inter-team trust around OpenFeature plus flags in version control. The theme in both is the same: flags stopped being one team's dashboard fiefdom and became reviewable config the whole org could see.

The deploy-dark golden path, worked end to end​

Here is the concrete workflow the title promises: a risky change ships to production safely because deploy and release are separate operations, both governed by Git. Walk through it once with a hypothetical checkout-v2 flag.

Step 1: the flag ships with the code. The developer adds the new checkout behind a flag check and commits the flag definition, defaulting to off, in the same branch as the code. The flag and the code it guards are reviewed together, in one pull request, by the same reviewers. No ticket to "create the flag in the dashboard" after merge, no flag whose rollout story lives only in someone's memory.

Step 2: CI validates, CD deploys dark. The pipeline lints the flag definition the way it lints anything else, schema, naming, default-off for new flags, and the deploy goes out with the flag off. Production runs the new code paths at zero traffic. Deploy is now a non-event from the user's perspective, which is exactly what you want from the highest-frequency operation in the system.

Step 3: release becomes a flag-status change. Turning the feature on is a second pull request that flips the flag's status or targeting, reviewed, approved, and merged like any config change. Flipt syncs the merged state and pushes it to evaluating clients over SSE. If the change needs staging first, that is a branch merge, not a separate console procedure.

Step 4: rollback stops meaning re-deploy. If checkout-v2 misbehaves at 2 AM, the fix is reverting the flag-status commit, not rebuilding, re-testing, and re-pushing the previous binary while the incident clock runs. The blast radius is bounded by the flag's targeting, and the revert itself is a reviewed, auditable Git operation instead of a panicked dashboard toggle whose previous value nobody recorded.

What the platform owes tenants​

That workflow is only a golden path if the platform builds the guardrails, because left as tenant DIY it degrades into everyone hand-rolling their own flag loader. Four things are non-negotiable. First, an evaluation SDK story: either a first-class SDK or an OpenFeature provider speaking OFREP, so tenants never hand-parse flag files and a future backend swap doesn't rewrite call sites. Second, an audit trail: Git history covers who changed what and when, and signed commits make it compliance-grade.

Third, per-environment scoping with teeth: environments must be genuinely isolated flag states, not naming conventions tenants can typo across. Fourth, CI validation of flag definitions, so a malformed targeting rule fails the build instead of failing open in production.

What flags don't replace: the traffic layer​

A flag decides who sees new code. It does not decide how traffic reaches new versions, and confusing the two is how teams end up hand-rolling canary analysis in application code. Percentage rollouts on a flag are user targeting, not traffic shaping: they say nothing about error budgets, latency regression, or automatic rollback when the new version starts failing.

That layer belongs to progressive-delivery operators, and this blog already ran the head-to-head: Flagger vs Argo Rollouts, where the verdict for a headless git-push PaaS was Flagger's reconciler-driven canaries over Argo Rollouts' human-in-the-loop model.

The pairing is clean. Flags handle release targeting and instant kill-switches at the application layer. The canary operator handles version traffic-splitting, metric-gated promotion, and automatic rollback at the platform layer. Adopt flags-as-code for the first job; don't ask it to do the second.

Gotchas before you commit​

Three failure modes show up in every flags-as-code adoption, and all three are process problems wearing technical costumes. Stale-flag debt is the big one: every shipped flag is a branch in your code that outlives its release, and flags committed next to code are retired nowhere unless retirement is part of the definition of done. Make flag removal a follow-up pull request on the same ticket, and track flag age the way you track TODO age.

Evaluation latency and consistency come next. Remote evaluation over OFREP adds a network hop to every flag check, which is why in-process evaluation, GO Feature Flag's embedded WebAssembly module is the notable 2026 example, exists for hot paths. Either way, know your propagation delay: SSE push is near-instant, but any polling fallback has a window where two instances disagree, and release plans that assume simultaneity will eventually be embarrassed.

Secrets don't belong in flag repos. Flags are config, and config repos get broad read access, which makes them exactly the wrong place for tokens and keys. Use secret references resolved from a real manager at evaluation time. Note this is one of Flipt's Pro-gated integrations, so teams on the free tier need their own answer, an external-secrets operator or equivalent, before the first flag that wants to smuggle a credential.

None of these is a reason to stay on dashboard flags. Each is a reason to adopt flags-as-code deliberately, with the retirement discipline, latency budget, and secrets story decided up front. The teams in the Solaris and DataGalaxy case studies didn't win because flags lived in Git. They won because flags living in Git forced every release decision through review, history, and revert, the three mechanisms software teams already trust for everything else.

Bex.co is the open-source, AI-native Render alternative, push a git repo, get a running HTTPS service on machines you own. If your rollout story starts with git push, your flags should live there too. Star the repo on GitHub or deploy your first app today.