Quonfig vs Flipt

Flipt details verified against its public repositories in August 2026 — evaluation-over-HTTP from the flipt-server-sdks README and source, the 120-second default poll and Fail error strategy from the flipt-client-sdks READMEs — plus the August 2025 Flipt Cloud sunset. Flipt is a project of its maintainers; comparison is for evaluation purposes and reflects our reading of their published docs.

Flipt's “server-side” SDKs call the server on every flag check

This is the difference that matters most in production, and it's easy to miss because the naming is inverted from the rest of the industry. Everywhere else — LaunchDarkly, Unleash, Quonfig — a “server SDK” is the one that downloads the full ruleset and evaluates in-process. At Flipt, the SDKs named server-side are the remote ones. Their own repository README is explicit about it:

“These server-side SDKs are responsible for evaluating context and returning the results of the evaluation. Each client interacts directly with an upstream Flipt server and can perform any of the three of the following evaluation operations via HTTP: Variant, Boolean, Batch.”— flipt-io/flipt-server-sdks, README

In the source, an evaluation is exactly what it sounds like: an HTTP POST, awaited inline. There is no cached ruleset and no snapshot to fall back on — the answer only exists on the server.

1// flipt-node/src/evaluation/index.ts
2public async variant(request) {
3  const response = await fetch(
4    `${this.url}/evaluate/v1/variant`,
5    { method: "POST", headers: this.headers,
6      body: JSON.stringify(request) }
7  );
8  // every flag check crosses the network
9}

1// config already in memory, kept fresh over SSE
2const enabled = quonfig.isEnabled("new-checkout");
3
4// no await, no socket, no timeout,
5// no dependency on us being reachable
6// right now. sub-millisecond.

Why that matters once you're in production

Putting the flag service in the request hot path couples your application's availability to it. If Flipt is slow, your endpoints are slow. If Flipt is unreachable, every flag check fails at once — and flag checks tend to sit on exactly the code paths you reach for during an incident, like the kill switch you were planning to use. Latency compounds too: a request that checks six flags pays six round-trips unless you restructure your code around the batch endpoint, and a hot loop can't check a flag at all. This is also the failure mode a feature flag is supposed to protect you from, which is what makes it worth being careful about.

With local evaluation the question doesn't arise. Quonfig backend SDKs pull the full config once at startup, evaluate every check in-process against in-memory rules, and receive updates over SSE in about a second. If we disappeared entirely mid-request, your flag checks would keep returning the right answers from cache.

To be fair: Flipt does have local evaluation

It lives in a separate SDK family Flipt calls client-side — a Rust engine shipped over FFI or WASM that fetches a snapshot and evaluates in-process. It works, and if you're running Flipt you should strongly prefer it over the server-side SDKs for backend services. Three things to know before you rely on it: it polls on a 120-second default interval, so a flag flip can take two minutes to reach your fleet; streaming requires Flipt v2, and Flipt Cloud was sunset in August 2025; and its default error strategy is Fail, so a Flipt server that's unreachable at boot fails client construction unless you opt into fallback and hand-manage a base64 snapshot yourself. The capability is real. It is not the default, and it is not what the SDK named “server” does.

Two independent delivery stacks, not one

Local evaluation removes us from your hot path. Redundant delivery is what makes sure you can still receive a change when you need one — because the moment you actually need to flip a kill switch is precisely the moment you can least afford your flag vendor to be having an outage.

Quonfig runs config delivery on two fully independent stacks: the same Go binary deployed on two different cloud providers, each serving from its own git clone, each warmed independently from GitHub. This is not a CDN cache sitting in front of a single origin — a cache in front of one origin still fails when that origin fails. These are two separate origins that can each answer on their own. Every SDK knows about both: on a network error or a 5xx from the primary it retries the secondary automatically, no configuration required. If somehow both were unreachable, backend SDKs keep serving from their locally-cached config, and fall back to your code's safe defaults rather than throwing.

With self-hosted Flipt, all of that is yours to design, build, deploy, and keep warm. That's a fair trade if operating infrastructure is something your team wants to own — but it is real work, and a single Flipt server is a single point of failure for every evaluation made through a server-side SDK.

Loved Flipt Cloud? Here's the managed git-native option that's still standing

When Flipt sunset Flipt Cloud in August 2025 and pointed customers back to self-hosting, the managed git-native category effectively emptied out. Quonfig fills exactly that gap. You get config-as-code stored in a real git repo — one JSON file per key, full history as git log — but you never stand up a server, a database, or a delivery tier. We host the git server (self-hosted Gitea), the UI, and the edge delivery. You keep the ownership: clone your workspace anytime with qfg pull or plain git, with no export fees and no lock-in. It's the git-native workflow Flipt users already trust, without the on-call rotation.

Hosted delivery and nine native SDKs you don't have to operate

There are nine native Quonfig SDKs — Node, Go, Ruby, Python, Java, and .NET on the backend, plus Browser JavaScript, React, and React Native — all at 1.0, alongside seven official OpenFeature providers. Every backend SDK evaluates locally by default; there is no remote-evaluation mode to pick by mistake. Changes reach them over SSE in about a second, with ETag caching and a 60-second safety-net poll behind it.

Self-hosting Flipt is a legitimate choice, and its single-binary deployment story is genuinely good. Just be clear about what you're taking on: the streaming tier, the redundant delivery path, the warm standby, and the on-call rotation behind all of it are infrastructure you own and operate. With Quonfig they're the product.

Built for the age of AI-written code

When AI agents write most of your code, flags get created far faster than humans retire them — flag explosion. Quonfig is built for the full flag lifecycle in that world, and both products share the foundation that makes it sane: git. Because every workspace is a real git repo, each change an agent makes is a reviewable commit with an author, a diff, and a timestamp — auditable by default. The scriptable qfg CLI and OpenFeature let you assemble a lifecycle loop today: create a flag when an agent ships work, retire it when the rollout completes. The same git-native principle that makes Flipt trustworthy to self-host is what makes Quonfig safe to let agents write against — now delivered as a managed platform.