Flipt v2 review: Git-native feature flags stored in your own repositories

What Flipt v2 solves, and who it is for

Feature flag tools usually introduce a second source of truth. Flags live in a vendor database or a self-hosted Postgres instance, while the code that reads them lives in Git. The two drift, and the audit trail for a flag change sits somewhere other than the audit trail for the code change. Flipt v2 attacks that split directly: the README describes it as "the first truly Git-native feature management platform that treats your feature flags as code", and the v1 versus v2 table makes the shift explicit, moving storage from MySQL, PostgreSQL or SQLite to Git repositories with optional SCM sync against GitHub, GitLab, BitBucket, Azure DevOps and Gitea.

The intended reader is an engineering team that already runs trunk-based development and GitOps. The README lists those use cases by name: merge incomplete features behind flags, treat infrastructure and feature flags as code, keep flag data inside your own infrastructure. If your organisation has no Git review process, or the people who toggle flags are not the people who open pull requests, the model fights you rather than helping. The repository is written in Go and ships as a single binary, which matters for the deployment story below.

How the Git-native model actually works

The mechanism is that a Flipt environment is bound to a Git location rather than to a database schema. The README describes three shapes for that binding: environment per branch, so an environment tracks a branch; environment per directory, so flags are organised by microservice or team inside one repository; and environment per repository, so separate products or security domains get separate repos. Each environment keeps its own namespaces, flags and configurations, which the README calls complete isolation.

Because the Git integration is read and write, the flow runs in both directions. Flag definitions are committed to the repository, the server reads them from there, and changes made through the UI or API become commits. That is what makes blame and history meaningful: a flag change is a commit with an author and a diff, not a row update. The README also states that the server pushes updates to client SDKs over Server-Sent Events, which it contrasts with the polling required in v1. For client-side flags that is a real architectural difference, since the client holds a stream instead of a timer.

The cost of this design is that Git becomes a runtime dependency of the flag evaluation path in a way a database would be. The README does not document what happens to in-flight evaluations when the configured remote is unreachable, and it does not describe a rollback procedure for a bad flag commit. Those are the questions to ask before putting the server in front of production traffic.

Installing Flipt v2 and running a first flag

The README's Quick Start points at the hosted quickstart guide and gives two local paths. The install script fetches the binary, and the quickstart subcommand runs a wizard. Both commands come from the README verbatim.

# Install Flipt
curl -fsSL https://get.flipt.io/v2 | sh

# Wizard-driven setup to get you started quickly
flipt quickstart

# Run Flipt server
flipt server

The wizard is the part worth using first, because a Git-native server needs to know which repository to read before it has anything to serve. Expect the wizard to ask for that configuration rather than for database credentials, which is the main practical difference from v1.

If you would rather not install anything locally, the README gives a single Docker command. It publishes the UI port and the gRPC port, and the image tag is pinned to the v2 major line.

docker run --rm -p 8080:8080 -p 9000:9000 -t docker.flipt.io/flipt/flipt:v2

After either path, the README states the UI is available at http://127.0.0.1:8080/. Port 9000 is the second published port and is the one to point gRPC clients at. The README also documents a nightly image at docker.flipt.io/flipt/flipt:v2-nightly and warns in a callout that nightly builds are generated from the latest v2 branch and "should not be considered stable for production use". Treat that warning literally: the nightly tag is for verifying a fix before the next stable release, not for a shared environment.

Configuration is YAML. The README's example opens with a secrets block and shows a file-based provider, which the comparison table lists as OSS, with HashiCorp Vault and the cloud secret managers listed as Pro.

# config.yml - Git-native setup with secrets management
secrets:
  providers:
    # File-based secrets (OSS)
    file:

The README truncates the example at that point, so the full set of keys under the file provider is not visible in the repository's front page. Check the configuration reference in the docs before writing your own file, rather than guessing key names.

Where the Git-native approach breaks down

The clearest limitation is that Flipt v2 makes Git a hard requirement for the workflow, not an integration. A team that wants a flag flipped by a support engineer at 2am, without a commit, is using the wrong tool. The README's own framing supports this: merge proposals with code review and GPG commit signing are listed as Pro features, which means the review-heavy path is the paid one, while the OSS binary gives you the Git storage model itself.

A second constraint is the environment model. Environments are isolated to the point that each has its own namespaces and flags, so a flag that must behave identically across dev, staging and production has to exist in each environment's Git location. The README does not describe a promotion mechanism that copies a flag definition from one environment to another. If your team expects to define a flag once and roll it out, plan for how those definitions stay in sync, because the README is silent on it.

Third, the licence is recorded as NOASSERTION in the repository metadata. The repository has a LICENSE file at the top level, but the automated detection did not resolve an SPDX identifier. Anyone distributing Flipt, embedding it in a product, or running it as a managed service should read that file directly. This article cannot tell you what it permits.

Finally, the project is moving quickly. Releases v2.11.0, v2.12.0 and v2.13.0 landed between 2026-07-18 and 2026-09-20, and the last push to the v2 branch was on 2026-09-22. A fast cadence is good for fixes and bad for anyone who pins nothing; read the changelog and the deprecations file before each upgrade.

Flipt v2 compared with Unleash and database-backed flag servers

The obvious comparison, and the one search data keeps returning, is Flipt versus Unleash. The difference that matters is where the flag definitions live. Unleash is a server with its own datastore, so the flag catalogue is a database you back up and migrate; Flipt v2 stores the catalogue in your repositories, so backup is whatever you already do for Git and migration is a merge. That is a genuine architectural fork, not a feature-list difference.

It cuts both ways. With a database-backed server you get transactional writes, a query language over flag history, and a single place to point a reporting tool. With Flipt v2 you get diffs, blame and branch-based testing, and you inherit Git's failure modes: merge conflicts on flag files, large repositories, and a remote that can be down. The README leans into the first set and says nothing about the second.

If your team already treats every other piece of configuration as code and reviews it in pull requests, Flipt v2 removes a category of tooling you would otherwise maintain. If your flag changes are made by people outside the code review loop, a database-backed server will fit your organisation with less friction, and Flipt v1 remains available: the README notes that v1 code lives on the main branch with its own documentation site.

Licence, upgrade cost and what to check before adopting

The repository metadata reports the licence as NOASSERTION, and the top-level LICENSE file is the authoritative text. Read it before you plan distribution. Nothing here is legal advice, but the practical question is whether your intended use, self-hosting internally, embedding in a product you ship, or offering it to third parties, is covered by that file. If you cannot answer that from the file, that is the blocker, not a detail.

Upgrade cost is shaped by two things visible in the repository. First, the release cadence: three minor releases in roughly two months, with the v2 branch taking pushes as recently as 2026-09-22. Second, the presence of a DEPRECATIONS.md file at the top level alongside CHANGELOG.md, which suggests the project tracks removals explicitly. The upgrade procedure itself is not described in the README, so check RELEASE.md and the changelog for the version you are moving to.

Because configuration is YAML and secrets can come from a file provider, a self-hosted deployment has few moving parts: the binary or the container, a config file, and a Git remote. That is the selling point. The corresponding operational duty is that the Git remote is now on the critical path, so monitoring it is part of running Flipt v2, not a separate concern.

Editorial conclusion

Adopt Flipt v2 if your team already reviews code in Git and wants flag changes to arrive through the same pull requests, with the server self-hosted and no database required by default. Do not adopt it if you need a hosted service with no repository to manage, or if your flag workflow cannot live in Git. Before rolling it out, verify that the licence file's terms match your distribution plans, and confirm which capabilities you need are Pro rather than OSS, since GPG commit signing and merge proposals are listed as Pro features.

Frequently asked questions

Official sources

1. flipt-io/flipt on GitHub
2. Issues
3. Project website
4. README
5. Releases