Config as code

Git-based feature flags

A git-based feature flag system stores each flag as a file in a git repository instead of a row in a vendor's database. Turning a flag on is a commit. The audit trail is git log. Rolling back is git revert. And because the flags are files, the same tools you already use on code — diffs, pull requests, blame, branches, grep — work on your configuration too.

The catch has always been delivery. A repo is a great place to store flags and a terrible place to read them from at request time. So teams end up choosing between config-as-code they own and a hosted service that actually delivers. Quonfig is both: your flags live in a real git repo you can clone, and a hosted delivery network pushes changes to your SDKs in milliseconds.

The mechanics

What “git-based” actually means

Not “we have a changelog” and not “we sync to GitHub.” The flag itself is the file, and the file is the source of truth.

feature-flags/checkout-v2.json
{
  "key": "checkout-v2",
  "type": "feature_flag",
  "valueType": "bool",
  "default": {
    "rules": [
      { "criteria": [{ "operator": "ALWAYS_TRUE" }],
        "value": { "type": "bool", "value": false } }
    ]
  },
  "environments": [
    { "id": "production",
      "rules": [
        { "criteria": [
            { "operator": "IN_SEG",
              "valueToMatch": {
                "type": "string",
                "value": "internal-team" } } ],
          "value": { "type": "bool", "value": true } },
        { "criteria": [{ "operator": "ALWAYS_TRUE" }],
          "value": {
            "type": "weighted_values",
            "value": { "weightedValues": [
              { "weight": 25000, "value":
                { "type": "bool", "value": true } },
              { "weight": 75000, "value":
                { "type": "bool", "value": false } }
            ] } } }
      ] }
  ]
}

One file per flag, not a row per flag

The JSON on the left is the flag — its default, its per-environment targeting rules, and the weighted split that makes it a 25% rollout (weights are out of 100,000). There is no other copy of it in a database that could disagree. Grep your config the same way you grep your code.

Every change is a commit

Turning a flag on writes a commit with an author, a timestamp, and a diff. That's not an audit log the vendor generates alongside the change — it is the change. Nothing can mutate a flag without leaving one.

Review before it ships, revert after

Because it's a diff, a risky targeting change can go through a pull request like any other. And if a rollout goes badly, git revert is a real rollback to a known state, not a best-effort re-entry of what you think the old values were.

The repo is yours

Clone it, mirror it, keep it after you leave. Disaster recovery isn't a support ticket — it's a directory you already have on disk. No export fees, no lock-in.

the audit trail is just git
$ git log --oneline feature-flags/checkout-v2.json
a4f19c2  Roll checkout-v2 to 25% in production   ada@   3 days ago
7b02e41  Roll checkout-v2 to 10% in production   ada@   8 days ago
c9e8d13  Add internal-team to checkout-v2 prod   jeff@  2 weeks ago
1f4a7b8  Create checkout-v2 feature flag         jeff@  3 weeks ago
$ git revert a4f19c2      # back to 10%, exactly as it was
$ git blame feature-flags/checkout-v2.json   # who set this rule, and when

The landscape

Three ways teams do this today

Each one is a real answer with a real cost. The third exists because the first two make you give something up.

Approach 1

Database-backed SaaS

LaunchDarkly, Flagsmith, ConfigCat

  • Nothing to run. Mature UI and delivery.
  • Your flags are rows in someone else's database. You get an export, not the source of truth.
  • The audit trail is a feature the vendor renders for you, with whatever retention your plan buys.
  • No diff to review before a targeting change lands, and no real revert after.
Approach 2

Self-hosted GitOps

Flipt, Featurevisor, homegrown YAML

  • Genuinely git-based. The files are yours and the workflow is clean.
  • Open source, no per-seat bill.
  • You operate it: the server, the availability, the upgrades, the on-call page at 3am.
  • Non-engineers need a UI, and a git repo isn't one. Build it or do without.
Approach 3

Managed git-native

Quonfig

  • Every workspace is a real git repo — one JSON file per key, cloneable any time with qfg pull or plain git clone.
  • We run the git server, the UI, and the delivery. Nothing for you to operate.
  • Backend SDKs evaluate in-process, so a flag check is a local function call — the flag service is never in your request hot path.
  • Changes reach your SDKs over SSE in milliseconds, from two independent delivery stacks on different clouds.

When Flipt Cloud shut down in August 2025, the managed git-native category effectively emptied out. That gap is the reason Quonfig exists — read the honest side-by-side with Flipt.

Why now

Agents made the file format the API

A coding agent can already read and write JSON in your repo. It cannot reason about a row in a database it can't see.

Agents already speak files

An agent working in your repo can open feature-flags/checkout-v2.json, read the targeting rules, and edit them — with no API, no key, and no integration to learn. The storage format is the interface.

You can review what the agent did

When an agent changes a flag, you get a diff. That is a meaningfully different safety posture from an agent calling a mutation endpoint and reporting back that it worked.

AI-written code needs more flags, faster

When features land faster than they can be manually verified, more of them ship behind a flag. Flag volume goes up, so flag hygiene — who changed what, what's stale, what's safe to delete — stops being optional.

Attribution survives the bot

Git commits carry an author. A change made by a service account reads as that service account forever, which is the only way a mixed human-and-agent change history stays legible.

More on the agent surfaces — MCP server, REST API, CLI, and the files themselves.

Straight answers

Common questions

Does an SDK read flags from git at request time?
No — and it shouldn't. Git is the storage and audit layer, not the read path. Quonfig's backend SDKs download the full config once and evaluate in-process, so a flag check is a local function call that can't time out or add latency. Updates arrive over SSE when something changes. The repo is what makes the history real; the delivery network is what makes reads fast.
Is this the same as putting a YAML file in my application repo?
It's the same idea, with the two hard parts solved. Config in your app repo means a deploy to change a flag, which defeats the point of having flags — and it gives non-engineers no way to flip a kill switch. Quonfig keeps the flags in a separate git repo that changes without a deploy, and puts a UI in front of it for everyone who isn't going to open a pull request.
Can non-engineers still use it?
Yes. The UI is the primary surface for most people — toggles, targeting rules, rollout sliders, history. It writes commits underneath. Nobody has to touch git unless they want to, and the people who do want to can clone the repo and work in JSON.
What happens if Quonfig goes away?
You keep the repo. It's a standard git repository full of plain JSON, so you can clone it and point the SDKs at the directory on disk — that datadir mode is a supported, documented way to run, not a fire drill. That's the practical difference between owning your config and being able to export it.
How do I move off a database-backed tool?
One command. qfg migrate --from launchdarkly pulls your flags, segments, and targeting rules into a git repo you own and writes a report of anything that needed judgment. Add --push to sync that same repo to Quonfig Cloud, or don't, and just run it free off the files.

Git-based flags, without running the infrastructure

Your flags in a real git repo you can clone. A hosted UI, real-time SSE delivery, and nine native SDKs on top. Migrate an existing tool in one command.

Migrate your flagsWhy git-native