Why Quonfig: A Developer Diary

I built Prefab — a feature flag and config management platform — and ran it for several years. It was a great product. Real customers. Real scale. But the whole time, something nagged at me.

Feature flag platforms store your configuration in a database you can't access. Every config change disappears into a proprietary system. I love me some configruation management, but at the end of the day it's just a bunch of JSON. Locked away in a proprietary system your AI agents can't easily read it or maniuplate it. It always feels worrisome that it's in a 3rd party.

At the end of the day, configuration is too important to live solely in someone else's system.

So I decided to rebuild the whole thing on top of git. That's Quonfig.

The Core Bet

The central idea is simple: every workspace gets its own git repository. Feature flags, dynamic configs, log levels, secrets — they're all JSON files in that repo. When you change a config through the UI or CLI, Quonfig makes a git commit on your behalf. When you want to see what changed, you can use the nice UI or you can git log. When you want to see who changed it, you get git blame.

This sounds obvious in hindsight, but it's a genuinely different architecture from other feature flag platforms. They all use a database with a changelog UI bolted on. We use git as the source of truth, with a UI bolted on top of that.

What's Been Built

The system is working end-to-end. Here's what exists today:

The app. A Next.js application where you create and manage feature flags, configs, segments, log levels, and secrets. Every edit is a git commit. There's an activity feed that's literally git log --all with pagination. There's a debugger where you can paste a context and see how every flag evaluates.

The delivery service. A Go server that serves config to SDKs over SSE. When you push a config change, Git fires a webhook, the delivery service pulls the latest, and every connected SDK gets the update in real time. Git is not in the hot read path — the delivery service keeps everything in memory. This is how we handle scale without making git a bottleneck.

The SDKs. Node, Go, and browser SDKs are published and working. A few lines of code to evaluate a flag. SSE for real-time updates. Telemetry reporting baked in.

Telemetry. A service that ingests evaluation data and writes to ClickHouse. We can see which flags are being evaluated, how often, with what contexts, and by which SDK clients.

The CLI. A CLI tool (qfg) with structured JSON output on every command. List flags, create configs. Built for both humans and AI agents.

Architecture in a Nutshell

The flow is:

1. User edits a flag in the UI (or an agent uses the CLI).
2. The app writes JSON to the workspace's git repo and commits.
3. Git receives the push and fires a webhook.
4. The Go delivery service pulls the update and refreshes its cache.
5. Connected SDKs receive the new config over SSE within seconds.

Dogfooding

Quonfig uses Quonfig. But we're very careful about it. Our own services boot from a QUONFIG_DIR that gets packaged at deploy time. We manage our own feature flags through the platform, but we can also edit them locally (because it's just a git repo). This makes sure that we won't end up in a situation where we can't ship Quonfig because of a bug in Quonfig.

First Staging Consumers

We have our first external app — running on staging with the Node SDK. Quonfigs resolve. Telemetry flowing. SSE connections stay open. It's the first proof that this architecture works.

What's Next

The system is roughly 85% feature-complete. The core create/read/update/delete loop works. Telemetry works. SDKs work. What's left:

• Filling UI gaps. Restore deleted items, environment settings, code samples for SDK integration.
• End-to-end confidence testing. Making sure the full path — from UI edit to SDK evaluation — is rock solid under real conditions.
• Build out secondary delivery We aim for ultimate uptime, so will have a second delivery network on a fully separate cloud.
• Authorization Updates for more complete authorization level support.
• OpenFeature Clients Will update our clients to have open feature adapters.

What Migration Will Look Like

I'm building a qfg migrate tool from day 1. Make it easy to migrate from a Prefab or Launch account into a git repo. From there we'll move on to migrating from other services. qfg migrate pulls data from the existing FF service and creates a git repo. You can move clients from existing SDK to the Quonfig ones and point them at the migrated repo to verify. Then we can push the repo up to quonfig and start doing it live.

Why Write This

Building in public is a cliche, but I genuinely think git-native config is a better architecture and I want to document the process of proving that out. If you're running feature flags and you've ever been frustrated by not owning your own data that's the problem we're solving. More updates to come.

— Jeff