# Quonfig > Quonfig is a feature-flag and configuration platform that stores config as JSON files in real git repositories instead of a database. Backend SDKs evaluate flags locally in-process (sub-millisecond, no network call), every change is a reviewable git commit with author/diff/timestamp, and you can clone your workspace anytime. Built for the age of AI-written code, where agents create flags far faster than humans retire them. This file is the full text of the Quonfig marketing site, in markdown, following the llms.txt convention (https://llmstxt.org). The short link index is at https://quonfig.com/llms.txt. Blog posts are not included here — see https://quonfig.com/blog. Product documentation lives at https://docs.quonfig.com. ## Contents - Home — https://quonfig.com - Feature flags — https://quonfig.com/features/feature-flags - Dynamic config — https://quonfig.com/features/config - Dynamic log levels — https://quonfig.com/features/log-levels - Secret management — https://quonfig.com/features/secrets - AI prompts as config — https://quonfig.com/ai-prompts - For AI agents — https://quonfig.com/agents - For developers — https://quonfig.com/developers - Pricing — https://quonfig.com/pricing - Why Quonfig — https://quonfig.com/why - Git-based feature flags — https://quonfig.com/git-feature-flags - Migrate — https://quonfig.com/migrate - Quonfig vs LaunchDarkly — https://quonfig.com/vs/launchdarkly - Quonfig vs Flagsmith — https://quonfig.com/vs/flagsmith - Quonfig vs Unleash — https://quonfig.com/vs/unleash - Quonfig vs ConfigCat — https://quonfig.com/vs/configcat - Quonfig vs Flipt — https://quonfig.com/vs/flipt - About — https://quonfig.com/about - Contact — https://quonfig.com/contact - API & agents (REST, OpenAPI, MCP, CLI) --- ## Home URL: https://quonfig.com ### The feature flag platform built for the age of AI-written code Everything your factory ships, behind a flag — auto-created when the agent commits, auto-retired when the rollout completes. Every step a git commit. Trusted by teams shipping to production: CheddarUp, Lizzie Sleep, Form Health, Shift Security, ForceRank. ### The flag lifecycle **When agents write the code, flags pile up faster than humans retire them.** Quonfig is built for the full lifecycle of a flag in that world — created when the agent ships work, retired when the rollout completes. Because config is git-native, every step is a reviewable commit. A feature-flag lifecycle is the path a flag travels from creation to removal: a flag is created when work ships behind it, rolled out gradually with targeting rules, then retired once it reaches 100% and the code path is permanent. In Quonfig each step is a real git commit — a JSON file change with an author, a diff, and a timestamp — so the trail is auditable by default. 1. **Agent ships work, flag is created.** When an agent commits a feature, it lands behind a flag. In Quonfig that flag is a JSON file added to your workspace repo — so its creation is a commit you can review, not a row in someone else's database. (`+ configs/checkout-v2.json`) 2. **Roll out gradually with targeting.** Move from 0% to 100% with percentage rollouts and targeting rules — by environment, cohort, or attribute. Every bump is another commit, evaluated locally and in-process by the SDK. (`rollout: 25 -> 100`) 3. **Rollout hits 100%, flag is retired.** Once the rollout is complete and the code path is permanent, the flag comes out. Deleting it is one more commit — a clean diff that closes the loop instead of leaving dead config behind. (`- configs/checkout-v2.json`) You can run this loop today: each stage is a git-native JSON file you change with the scriptable `qfg` CLI or plain git, evaluated through any of the nine SDKs or OpenFeature. A fully hands-off "auto-create on commit, auto-retire at 100%" pipeline is the direction we're building toward — assembled from these real primitives, not a one-click button. ### Four reasons it holds up when agents are writing the config Git-native by default, prompts you can ship without a deploy, local evaluation that survives an outage, and data you actually own. - **It's just git.** Every workspace is a real git repo, so every AI-generated config change is auditable by default — a JSON diff with a real author and timestamp. Clone it anytime. No lock-in, no export fees. - **Prompts are config.** Store LLM prompts in Quonfig, version them in git, change them without a deploy, and target by cohort. `qfg generate` turns Mustache prompts into type-safe render functions. - **Never goes down.** Backend SDKs evaluate locally, in-process, sub-millisecond — every flag check is a local function call. If our delivery service is unreachable, your app keeps serving on cached config. - **Own your data, lowest TCO.** Clone your repo anytime with `qfg pull` or plain git. Transparent, public pricing with a live calculator — roughly 10x cheaper than the major platforms at scale. ### One platform. Six capabilities. Same targeting engine, same SDKs, same audit trail for everything. - **Feature Flags** — Boolean and multivariate flags, percentage rollouts, kill switches, segments, targeting rules. - **Dynamic Config** — Type-safe config values (strings, numbers, JSON) — change without deploying. Same targeting engine as flags. - **Dynamic Log Levels** — Change log verbosity at runtime. Debug a specific user in production without redeploying. - **Secret Management** — Manage secrets alongside your config. Same SDKs, same targeting, same audit trail. - **Typesafe generated code** — Run `qfg generate` and get type-safe accessors for every flag and config — node-ts, react-ts, and more. No more stringly-typed lookups. - **Schema-validated JSON** — Attach a JSON Schema to any config. The CLI, the UI, and `qfg push` all enforce it — invalid values never make it into your workspace. Every feature uses the same JSON format, the same targeting rules, the same CLI, and the same local evaluation. Learn once, use everywhere. ### Reliability: your app doesn't go down if Quonfig goes down - **Local evaluation, always.** Backend SDKs (Node, Go, Ruby, Python, Java, .NET) download the full config and evaluate in-process. Every flag check is a local function call — sub-millisecond, zero network latency. Not a paid add-on. Every backend SDK. Every tier. Browser and React SDKs evaluate against our delivery service instead — you can't ship rule data to the browser without leaking targeting logic to end users. - **Graceful degradation.** If the SDK can't reach our delivery service, it keeps using cached config. Background retry. Your application is completely unaffected. The worst case is stale config, never unavailable config. - **Multi-cloud failover.** The primary delivery service runs on Fly.io; a warm standby runs on completely separate infrastructure. Every SDK fails over to it automatically — on by default, zero config. Slow fetches are hedged against both legs, and an ordering guard means a client never regresses to older config. - **Real-time delivery.** Config changes stream to backend SDKs over SSE within seconds of the commit — across 100,000 concurrent connections in production. Browser SDKs poll with ETag conditional requests, so unchanged config costs almost no bandwidth. ### Your feature flag platform was built for a different era Quonfig is built for teams that ship with agents, not just dashboards. | Your current setup | Quonfig | | --- | --- | | Feature flags only | Flags + config + log levels + secrets | | Dashboard -> Feature Flags -> Select -> Edit -> Save -> Deploy | UI, CLI, or git — your choice | | Export: "Contact sales" | Export: clone your git repo anytime | | Audit log: "Paid add-on" | Audit log: built-in, powered by git history | | Redeploy to change log levels | Change log levels at runtime, per user or environment | | Agent integration: Build a custom API wrapper | Agent integration: CLI with JSON output, or plain git | | Vendor SDKs only | Our SDKs or OpenFeature adapters | | Per-seat pricing | Granular usage-based pricing for lowest TCO | ### Your config, your repo, your data Every workspace is a real git repository you can clone. Use the UI, the CLI (`qfg pull` / `qfg push`), or plain git — you stay in control of where your config lives and how it changes. - **You own your data.** Your config lives in a git repo you can clone anytime. No vendor lock-in. No export fees. Your data, your terms. - **Real audit trail.** Every change has an author, timestamp, and diff — automatically. Not a proprietary changelog, a real version history. - **Disaster recovery.** If Quonfig disappears tomorrow, your config doesn't. Clone the repo and you have everything — full history included. ### Already using LaunchDarkly? An agent reads your flags, translates them to Quonfig format, and migrates everything — flags, segments, environments. You review the changes and you're done. ### Choose how you want to use Quonfig Start with the open-source SDK, or get the full platform with UI, delivery, and telemetry. - **Open Source — free forever.** SDK reads JSON from a local directory; sub-millisecond local evaluation; edit files directly or with agents; no account needed. - **Platform — free 30-day trial, then $5/mo + usage.** Full UI for flags, config, log levels; git-backed storage you own; environments, targeting, segments; global real-time delivery (usage pricing); telemetry & insights (usage pricing); SSO & enterprise support (add-on). - **Self-Hosted — custom.** Run Quonfig on your own infrastructure; full data sovereignty; SSO & enterprise support. Start managing feature flags in 5 minutes. Full UI. Real-time delivery. Agent-ready from day one. --- ## Feature flags URL: https://quonfig.com/features/feature-flags ### Ship with confidence Boolean and multivariate flags, percentage rollouts, kill switches, segments, and targeting rules. Manage everything from the UI or the CLI. Every change is tracked with a full audit trail. Rollback any change instantly. See rollout status, evaluation trends, and per-environment overrides at a glance. Every flag, every environment, on one screen — with a 14-day evaluation sparkline and an automatic Pre-rollout / Rollout / Live status for each one. ### Every flag type you need From simple on/off toggles to multivariate experiments with weighted rollouts. One consistent model for all of them. - **Boolean** — The classic on/off flag. Gate a feature, run a kill switch, or set up a percentage rollout with consistent user bucketing. - **String / StringList** — Serve different string values per environment or user segment. Perfect for multivariate A/B/C tests, theme selection, and allow-lists. - **Integer / Double** — Numeric flags for rate limits, batch sizes, thresholds, and scoring weights. Integer or floating-point. Tune per environment without redeploying. - **Duration** — Time-based values for timeouts, retry delays, cache TTLs, and polling intervals. Human-readable units, machine-precise evaluation. - **JSON** — Arbitrary structured data for complex configuration. Feature payloads, layout definitions, and A/B test metadata. - **Weighted Values** — Split traffic across multiple variants with precise percentage control. Consistent hashing ensures users see the same variant. ### Powerful targeting without complexity Layer rules to reach the right users at the right time. Target by property, combine with a segment, fall through to a percentage rollout — and scope the whole stack to one environment. - **Property-based targeting** — Target users by any property: email, plan, country, device, or custom attributes. Operators include is one of, starts with, ends with, contains, regex match, and more. - **Segments** — Define reusable user segments and reference them across multiple flags. Update the segment once, all flags update automatically. - **Percentage rollouts** — Roll out to a percentage of users with consistent hashing. Ramp from 1% to 100% without reassigning existing users. - **Per-environment rules** — Different rules for development, staging, and production. Override any environment independently while keeping a shared default. ### Watch the rollout land Real evaluation telemetry from your production SDKs, charted by variant. Know that a flag is actually serving what you think it is — before you ramp it further. - **Charted by variant** — See exactly which value your SDKs served, stacked over time. Absolute counts or percentages, over the last day, week, or month. - **Group by rule** — Switch from variants to rules to see which targeting rule actually matched. Find the rule that's serving more traffic than you expected. - **Sparklines in the list** — Every flag in the list carries a 14-day sparkline and a Pre-rollout / Rollout / Live badge, so stale flags are obvious without clicking in. ### Gradual rollouts built in Ship to 1% of users, then 10%, then 50%, then everyone. Consistent hashing ensures users see the same variant every time. If something goes wrong, kill it instantly. - **Percentage Rollouts** — Split traffic precisely with weights that sum to 100%. Ramp up gradually from 1% to full rollout. - **Consistent Hashing** — Hash by `user.key` or any property. Users always see the same variant, even as percentages change. - **Kill Switches** — Every boolean flag is a kill switch. One CLI command or one click to disable a feature globally. - **Instant Rollback** — Roll back any change in seconds from the UI or CLI. Every rollback is tracked in the audit trail. The sticky property decides who gets bucketed together — and keeps them there as you ramp. ### Built-in audit trail Every flag change is tracked with an author, timestamp, and a diff you can read. Powered by git history under the hood. - **Full history** — Every flag change ever made, with who changed it, when, and why. No 90-day retention limits. No paid add-ons. - **Exact diffs** — See exactly what changed between any two points in time. "What was this flag before the incident?" is one click away. - **Instant rollback** — Undo any flag change with one click from the UI or one command from the CLI. The rollback itself is tracked in the audit trail. Changes made through the CLI record the human as author and `qfg-cli` as committer. None of this is a feature we bolted on — it falls out of storing flags as files. --- ## Dynamic config URL: https://quonfig.com/features/config ### Change values without deploying Type-safe config values — strings, numbers, JSON objects — that update at runtime. Rate limits, API endpoints, theme settings, ML model versions. Same targeting engine as feature flags. Same SDKs. Same built-in audit trail. ### Every value type you need - **Strings** — API endpoints, CDN hostnames, template names, model versions. Change a URL without a deploy. - **Numbers** — Rate limits, timeouts, cache TTLs, thresholds. Tune performance in real time. - **JSON objects** — Complex configs like theme settings, notification rules, or ML pipeline parameters. Validated by schema. - **Lists** — Allowed origins, enabled integrations, notification channels. Manage arrays without code changes. - **Targeted values** — Different rate limits for free vs. pro users. Different API endpoints per region. Same config key, targeted values. - **Schema-validated** — JSON Schema ensures your config values are valid before they reach production. No more typos in critical settings. ### Same targeting engine as feature flags Configs aren't just static key-value pairs. Target config values by user, plan, segment, or any custom property — a rate limit of 10,000 for enterprise and 100 for everyone else, in a single config key. - **Property-based targeting** — Target by plan, region, team, device, or any custom attribute you send to the SDK. The same operators you use for feature flags. - **Segments** — Reference a reusable segment instead of repeating a rule. Update the segment once and every config that references it follows. - **Per-environment rules** — Production, staging, and development each get their own rule stack — or inherit the shared default when there's nothing special to say. - **Ordered evaluation** — Rules resolve top to bottom, so the specific case wins and the last rule is your fallback. Drag to reorder. ### Type-safe with JSON Schema Bind a JSON Schema to any config and Quonfig generates a real typed form — with the enums, minimums, and required fields enforced as you edit. Values are validated before they reach production. - **Validated on every save** — A value that violates the schema never lands. Catch the typo in the editor instead of in an incident channel. - **Generated typed clients** — `qfg generate` turns your schemas into typed accessors, so a config rename is a compile error rather than a runtime undefined. - **Schemas live in git** — Schema files sit alongside your configs in the same repo, versioned by the same history and reviewable in the same diff. ### Copy-paste integration for every SDK Every config carries a Code Samples tab with a ready-to-paste snippet in your language, using your actual config key. Tabs cover React Typesafe, React, Node Typesafe, Node, Python, Go, Ruby, Java, and JavaScript — nine languages, one click to copy. The typesafe variants use the client that `qfg generate` writes for you. ### See how your configs are being used - **Evaluation charts** — Time-series data showing how each config value is being resolved. Filter by environment and time range (1d, 7d, 30d). - **Per-value breakdown** — Stacked area charts show the distribution across different resolved values. See a rollout ramping up in real time. - **Grouped by rule** — Switch from values to rules to see which targeting rule actually matched — and catch the one serving more traffic than you expected. ### Every change is tracked Built-in audit trail powered by git history. Every config change has an author, timestamp, and diff. No paid add-ons, no 90-day retention limits. - **Full history** — Every config change ever made. Who changed what, when, and why. No retention limits. - **Authorization controls** — Role-based access levels control who can change what. Protected configs require higher access in production. - **Instant rollback** — Roll back any config change instantly from the UI or CLI. No support tickets. No dashboard hunting. --- ## Dynamic log levels URL: https://quonfig.com/features/log-levels ### Debug production without redeploying Change log verbosity at runtime. Turn on DEBUG for a single user, a specific team, or 1% of traffic — then turn it off when you're done. Same targeting engine as feature flags. No redeployment, no restart, no risk. DEBUG in development, INFO in staging, WARN or ERROR in production — every logger's level in every environment, and the shared default it falls back to. ### Debug any user in production A customer reports something you can't reproduce. Turn on DEBUG for just their account, leave everyone else at ERROR, and read the logs — no redeployment, no log-volume blowout, no risk to anyone else. - **Down to one account** — Match on `user.email`, `user.id`, or whatever identifier you already send. The blast radius of a DEBUG rule is exactly the users it matches. - **Per-environment rules** — A rule stack is scoped to Production. Staging and Development keep their own — or inherit the shared default. - **Or 1% of traffic** — For something intermittent, roll DEBUG out to a percentage instead of a person. Enough signal to diagnose, not enough to flood the pipeline. - **From the UI or the CLI** — `qfg set` from a terminal or an agent, or two clicks in the app. Either way the change is live in seconds and recorded the same way. ### Same targeting engine as feature flags A log level is just a config with a log-level value type. Every operator, segment, and percentage rollout you use for flags works here unchanged — including turning DEBUG on for 1% of traffic to catch something intermittent. - **Property targeting** — Target by user ID, email, plan, team, region, or any custom property you send to the SDK. Turn on verbose logging for just one customer. - **Segments and groups** — Define reusable segments like "enterprise customers" or "beta testers" and apply log levels to the whole group at once. - **Percentage rollouts** — Ramp up DEBUG logging from 1% to 5% to 25% of traffic. Diagnose intermittent issues without overwhelming your log pipeline. ### No more "who turned on debug logging in prod?" Every log level change is tracked with an author, a timestamp, and a description you can read. Including the one you made from the CLI at 3am — and the revert. ### No SDK changes needed The same SDK that serves your feature flags serves your log levels. One integration, one connection, all capabilities. If you've already set up Quonfig for flags, log levels work out of the box. - **One SDK, everything** — Feature flags, config, log levels, and secrets all come through the same SDK. No separate integrations to maintain. - **Real-time updates** — Log level changes propagate to your application in seconds via server-sent events. No polling, no restarts, no cache invalidation. - **Language-native** — SDKs for Node.js, Python, Ruby, Go, Java, .NET, and the browser. Each one feels native to the language and integrates with its logging framework. --- ## Secret management URL: https://quonfig.com/features/secrets ### Zero-knowledge secrets, alongside your config You hold the encryption key. We hold the ciphertext. Encrypt a value with one CLI command, distribute it to every environment through the same delivery path as your flags, and decrypt it in your app with `Quonfig.get("stripe.api.key")`. Quonfig never sees the plaintext — not at rest, not in transit, not in the audit log. ### You own the key. We own the pipes. Quonfig has zero knowledge of your encryption key. We just store and distribute the ciphertext alongside the rest of your config. **Quonfig owns:** - The CLI that encrypts locally before it ever hits the network - Distributing the encrypted blob to every environment, just like any other config - SDKs that decrypt in-process when your app calls `Quonfig.get()` **You own:** - The encryption key itself — a single hex string per trust group - Sharing the key with the right developers and services (a password manager or one-time link works fine) - Setting `QUONFIG_SECRET_KEY_*` env vars in dev and production ### Three commands, two configs, one shared secret Quonfig secrets are built on the same `provided` and `decryptWith` config primitives you already use. Nothing magic. Nothing custom. 1. **Generate a hex key.** `qfg generate-new-hex-key` produces a random hex string. Drop it into your local `.env` as `QUONFIG_SECRET_KEY_DEFAULT` and share it with your team via a password manager. 2. **Declare the key config.** `qfg create quonfig.secrets.encryption.key --env-var=QUONFIG_SECRET_KEY_DEFAULT --type string --confidential` — an empty vessel that resolves from your env, never stored on our side. 3. **Encrypt and ship.** `qfg create stripe.api.key --type string --value=sk_live_abc --secret` encrypts locally with the hex key and pushes only the ciphertext. Your app gets the plaintext back via `Quonfig.get(...)`. ### Different keys for production, staging, and dev Because the encryption key itself is just a `provided` config, you can resolve it to a different env var per environment. Production secrets stay isolated from your dev box. - **Isolate production** — `qfg set-default quonfig.secrets.encryption.key --environment=production --env-var=QUONFIG_SECRET_KEY_PRODUCTION --confidential`. Now production decrypts with a key your laptop never sees. - **Rotate without an outage** — Issue a new hex key, set it in the env, re-encrypt with `qfg create --secret` against the new key, then retire the old one. Each step is a config change with a real audit trail. - **As many keys as you need** — One key per trust group, two for prod-vs-everywhere-else, or many for fine-grained access — the model is the same. `quonfig.secrets.encryption.key` is just a default name, not a hard limit. ### Same delivery path. Same SDKs. Same audit trail. Secrets aren't a separate product. They use the same `Quonfig.get()` call, the same local-evaluation cache, the same git-backed history, and the same per-environment targeting as every other config. - **One SDK call** — `Quonfig.get("stripe.api.key")` returns the decrypted string. Your app code doesn't know or care that it was encrypted at rest. - **Survives our outage** — Encrypted secrets ride the same local-evaluation cache as every other backend SDK config. If we go down, your app keeps resolving the cached ciphertext. - **Real audit trail** — Every secret rotation is a git commit with author, timestamp, and diff. The audit log shows the ciphertext changed — no plaintext leaks into the history. - **Works in CI offline** — Make `QUONFIG_SECRET_KEY_DEFAULT` available to your CI process and tests resolve the same secrets, no network required. Deep-dive docs: https://docs.quonfig.com/docs/explanations/features/secret-management --- ## AI prompts as config URL: https://quonfig.com/ai-prompts ### Manage LLM prompts like feature flags Your LLM prompts are the highest-churn, most-experimented artifact in an AI app — so they belong in the same system as your flags and config. Store every prompt in Quonfig: version-controlled in git, changeable without a deploy, targetable by cohort, and type-safe. One targeting engine, one set of SDKs, one git-powered audit trail. ### Store prompts as config A string or JSON config holds the prompt. Edit it in the UI, the CLI, or git — whichever fits your workflow. Every change is a real git commit with an author, a timestamp, and a diff, and the prompt changes without redeploying your app. - Change the prompt at runtime — no deploy, no release train - Every edit is a reviewable git commit (diff + author + timestamp) - Roll back to any prior prompt the way you roll back any commit A prompt config is an ordinary config file, for example `configs/support.triage-prompt.json` with `"type": "config"`, `"valueType": "string"`, and the prompt text as the default rule's value. Editing it from the CLI looks like: qfg set-default support.triage-prompt \ --value "You are a support triage assistant. Classify the ticket..." \ --environment production ### Mustache templating, fully typed Prompts are rarely static strings — they interpolate user, plan, and request data. Quonfig string configs support Mustache `{{variables}}`, and `qfg generate` turns each one into a checked function parameter. - A render function per templated prompt, with every `{{variable}}` typed as a parameter - Miss a variable and the build fails — not the model call - TypeScript targets: `node-ts` and `react-ts` Accurate by design: typed generation is TypeScript-only (Node and React targets), Mustache variables are typed as `string`, and `mustache` is a peer dependency the generator reminds you to install (`npm install mustache @types/mustache`). ### A/B test prompts with the same targeting engine A new prompt is just a config change. Roll it out to 10% of users, target it to a cohort or environment, and roll it back instantly — driven by the exact same targeting engine that powers your feature flags. - **Target by cohort** — Serve a new prompt to enterprise users, one region, or a single environment. Same rule engine, same context, as your flags. - **Percentage rollout** — Ramp a prompt from 10% to 100% as confidence grows. Every step is a config change in git — reviewable and reversible. - **Instant rollback** — If a prompt underperforms, revert to the previous version from the UI or CLI. No deploy, no support ticket. ### We dogfood this Quonfig's own "infer a JSON Schema from examples" feature is powered by an Anthropic Claude prompt — and that prompt lives in a Quonfig config, not in our source code. When we tune the rubric, we edit a config and commit; no app redeploy. The config is `our-config/configs/llm.infer-json-schema.json`. - **A prompt change is a commit.** We sharpen the schema-inference prompt by editing one config. The change ships through git history like everything else — author, timestamp, diff. - **No redeploy to iterate.** The app reads the prompt from config at runtime, so prompt iterations don't wait on a release. The same loop is available to you on day one. --- ## For AI agents URL: https://quonfig.com/agents ### Your agent's new favorite tool A hosted MCP server. A REST API. A CLI that speaks JSON. And flag files your agent can edit like any other file in the repo. Take whichever path fits — they all write the same git history. ### Wherever your agent already runs Agents don't all live in the same place, and they don't all have the same reach. Pick the surface that matches where the work is happening. - **In the terminal — Claude Code, Cursor, Codex** (via MCP, git, `qfg`). The agent writing the feature can read the flag that guards it — and check what production is actually serving before it touches a rollout. Sign in through the browser; no key to hand it. Docs: https://docs.quonfig.com/docs/api/claude-code - **In Slack — Claude Tag** (via MCP with a `qf_sa_` key). Your team asks about rollouts where they already discuss them. A shared service account means every answer — and every flip — is attributed to the bot, not to a person. Docs: https://docs.quonfig.com/docs/api/claude-tag - **In CI — pipelines and scripts** (via REST API v1). Gate a deploy on a flag's state, flip a kill switch from a runbook, or reconcile config as part of a release job. Plain HTTPS with a Bearer key and an OpenAPI 3.1 spec to generate against. Docs: https://docs.quonfig.com/docs/api/rest-api - **Anywhere else — any MCP client** (`mcp.quonfig.com/mcp`). The server is streamable HTTP at a public URL, and the tools are the same REST surface underneath: same permissions, same validation, same audit trail. Nothing is special-cased for one vendor. Docs: https://docs.quonfig.com/docs/api/mcp-server ### Four ways in, one git history The CLI, the MCP server, and the flag files on disk aren't competing integrations — they're different hands on the same repo. Whichever one an agent uses, the result is a commit. ### MCP server: point Claude at your flags One command, then sign in through your browser. No API key to paste, rotate, or leak — the session acts with your own Quonfig permissions. claude mcp add --transport http quonfig https://mcp.quonfig.com/mcp - **15 tools — 13 reads, 2 writes.** List and inspect flags, configs, and segments; read the git history behind any of them; and when it's time to change something, write it. - **Your permissions, not a shared god key.** Over Claude Code you sign in as yourself, so the agent can only do what you can. Protected environments stay protected. - **Same audit trail — a flip from Slack looks like any other.** Writes land as commits in your workspace repo with an author and a diff. History responses mark bot changes with `isServiceAccount`. Any MCP client works the same way — point it at the URL and pick an auth method. ### Claude Tag: flags where your team already talks about them Give Claude in Slack a Quonfig service account and the channel can ask what production is serving — or change it — without anyone opening a dashboard. Claude Tag acts as one shared identity for the channel, so it authenticates with a `qf_sa_` service-account key. Every change it makes is attributed to that bot in your git history — not to whoever happened to mint the key. ### Or skip the network entirely An agent already sitting in your repo doesn't need an API to change a flag. The config is a file next to the code it guards. - **The open source path (JSON files).** Your agent already knows how to edit files. That's enough. Edit a JSON config, commit the change. Validation hooks ensure the structure is correct. No CLI, no key, no account. Pre-receive hooks validate the JSON structure on push. - **The `qfg` CLI — structured, validated, scriptable.** Every command returns JSON when piped, and `qfg pull` / `qfg push` keeps the local checkout and the hosted workspace in sync. For example, `qfg create checkout-v2 --type boolean-flag --value=false` and `qfg set-rollout checkout-v2 --environment production --true-percent 20`. ### JSON your agent can actually parse No more regex. No more table-scraping. Every response — CLI, REST, or MCP — is a typed envelope with `data` and `meta`. Where another tool prints an aligned text table, `qfg list --json` returns something like: { "data": [ { "key": "checkout-v2", "valueType": "bool", "value": true }, { "key": "new-pricing", "valueType": "string", "value": "$39" } ], "meta": { "count": 5, "environment": "production" } } ### Preview every change before it ships Because config is just JSON files in git, every change the agent makes is a diff you can read before it lands. The agent edits the config, opens a pull request, and the exact before/after is right there in the review — no opaque mutation, no guessing what changed. And when an agent writes through MCP or the API instead, you still get the commit: same author trail, same diff, same revert. An agent can't make a change that isn't reviewable after the fact. ### Your agent never has to guess MCP tools carry their own schemas, the REST surface publishes an OpenAPI 3.1 spec, and every CLI command describes itself. Discovery happens at runtime. `qfg schema operators` lists the available targeting operators (`ALWAYS_TRUE`, `PROP_IS_ONE_OF`, `IN_SEG`, `IN_INT_RANGE`, `PROP_ENDS_WITH_ONE_OF`, `HIERARCHICAL_MATCH`, and more). The published contract can be turned into a client rather than hand-rolled: curl https://api.quonfig.com/v1/openapi.json -o quonfig.json npx @hey-api/openapi-ts -i quonfig.json -o src/quonfig # Check which identity a key acts as before you script against it curl https://api.quonfig.com/v1/whoami -H "Authorization: Bearer $QUONFIG_API_KEY" ### Agent context file Ship a `.qf/agent-context.md` in your repo. Your agent auto-discovers it and follows the invariants, workflows, and guardrails you define. Encode your team's policies as instructions your agent actually reads. No dashboards to configure. No RBAC policies to maintain. Just a markdown file in version control — for example, invariants like "open a PR on the JSON diff before changing a production flag" and guardrails like "retire finished flags: `qfg cleanup list`". ### Give your agents real tools Everything an agent can do, a human can do in the UI — and every change lands in the same git history either way. Agent-first doesn't mean agent-only. --- ## For developers URL: https://quonfig.com/developers ### Everything you need to ship with confidence CLI, SDKs, a full UI, and the config format that finally makes sense. ### One tool for flags, config, and agents Structured JSON output on every command. Built for scripts, agents, and humans alike. | Command | Description | | --- | --- | | `qfg flag list` | List all feature flags | | `qfg flag create` | Create a new flag | | `qfg flag set` | Update a flag value | | `qfg eval` | Evaluate a flag locally | | `qfg schema flag` | Show flag JSON schema | | `qfg import` | Import from another platform | ### Evaluate flags in three lines Initialize the client, evaluate a flag, get a value. Type-safe and straightforward. Quick-start snippets are published for TypeScript, .NET, Go, Python, Java, and Ruby. For example, TypeScript: import { Quonfig } from "@quonfig/node"; const quonfig = new Quonfig({ sdkKey: "qf_sk_production_..." }); await quonfig.init(); const enabled = quonfig.isEnabled("checkout-v2", { user: { email: "alice@acme.com", plan: "enterprise" }, }); const price = quonfig.get("pricing.monthly", { user: { plan: "enterprise" }, }); Go uses `quonfig.NewSdk(...)` with `sdk.FeatureIsOn` / `sdk.GetStringValue`; Python uses `QuonfigSDK(Options(...))` with `sdk.enabled(...)` / `sdk.get(...)`; Ruby uses `Quonfig.enabled?` / `Quonfig.get`; Java uses `quonfig.featureIsOn(...)` / `quonfig.getString(...)`; .NET uses `client.IsFeatureEnabled(...)` / `client.GetString(...)`. ### JSON you can actually read Every feature flag is a file. Every field has a purpose. No proprietary schema to learn. - `key` — Human-readable, also the filename - `default.rules` — Fallback when no environment matches - `environments` — Per-env overrides with targeting rules - `criteria` — 26+ operators for flexible targeting A flag file such as `feature-flags/checkout-v2.json` carries `key`, `type`, `valueType`, `sendToClientSdk`, a `default` rule set, and an `environments` array whose entries hold per-environment rules with criteria like `{ "propertyName": "user.plan", "operator": "PROP_IS_ONE_OF", "valueToMatch": { "type": "string_list", "value": ["enterprise"] } }`. ### From edit to production in seconds Make a change in the UI or via CLI. Validation runs automatically. SDKs pick up the new config in real time. The flow is: edit via UI or CLI -> validation -> git commit (automatic) -> cache updates -> SDKs get new config. --- ## Pricing URL: https://quonfig.com/pricing ### Roughly 10x cheaper than every major flag platform Feature flags are a commodity, like electricity. We price them like one — based on what it costs us to deliver, not what we guess your business is worth. 30 days free. - **Commodity pricing.** We love feature flags — but they're a commodity, like electricity. Nobody wants to negotiate with an electricity salesman to keep the lights on. We charge based on what it costs us to deliver, not on guessing what an MTU or seat is worth to your business. - **Fair.** Free seats, forever. SSO without a "call us" enterprise tier. Audit logs, segments, schemas — included at every usage level. - **Predictable.** Just use the calculator to estimate yourself. Don't worry about sales negotiations. ### Or use Quonfig fully free and open source Store your flags as JSON files in your own git repo, read them straight from disk with the SDK. No account, no connection, no bill. The paid pricing is for the hosted service that adds the UI, change-review, and SSE delivery on top. See https://docs.quonfig.com/docs/how-tos/open-source-local ### Cheaper at every scale, with the gap growing as you grow Apples-to-apples persona pricing, from the same calculator we use internally. All Quonfig prices exclude SSO; most competitors don't offer SSO without a higher tier — add $250/mo for Quonfig SSO at any scale. | Profile | Quonfig | LaunchDarkly | Flagsmith | ConfigCat | | --- | --- | --- | --- | --- | | Hobbyist (1 server, 200 MAU, 1 seat) | $6 | $14 | $0 | $0 | | Early SaaS (6 servers, 5K MAU, 5 seats) | $11 | $122 | $45 | $55 | | Scaled SaaS (40 servers, 50K MAU, 15 seats) | $122 | $980 | $675 | $225 | | Mid-market (200 servers, 300K MAU, 40 seats) | $686 | $5,400 | $1,800 | $1,693 | | Enterprise (1K servers, 2M MAU, 100 seats) | $4,351 | $32,060 | Call sales | Call sales | ### What we charge for, exactly Eight line items. Seats are unlimited. The first 30 days are free — no credit card required. | What we charge for | Price | | --- | --- | | Platform — UI, git storage, auth, basic support | $5 / month | | Server connections — long-lived SSE streams from backend SDKs | $0.50 / connection / mo | | Frontend evals and API requests — HTTP requests against /configs and OFREP endpoints | $5 / 1M requests | | Tracked contexts — distinct context keys observed in telemetry per month | $2 / 10K contexts | | Telemetry events — frontend evals (1 each) + backend SDKs' batched aggregates (~1/min/process) | $2 / 1M events | | Config updates — commits to your workspace; abuse rule, not COGS-based | $0.01 / commit | | SSO — SAML or OIDC, on or off, available at any usage level | $250 / month flat | | Seats — team members: engineering, product, ops, support | $0 — unlimited | The published estimator computes a bill as: the $5 platform fee, plus servers x $0.50, plus frontend evals x $0.000005, plus tracked contexts x $0.0002, plus telemetry events x $0.000002, plus config updates x $0.01, plus $250 if SSO is enabled. Those unit prices are a uniform 10x markup over the marginal infrastructure cost of each meter. ### What you don't pay for Pricing pages get crowded with what's included. We think the more interesting list is what we refuse to charge for. - Per-seat fees. Add your whole team — engineering, product, ops, support. - Per-flag fees. Flags, variants, and environments are free. - API calls from our own UI. That is our cost, not yours. - Bandwidth surcharges. Bundled in request pricing. - Pro-tier feature gating. Audit logs, change history, segments, schemas — all included at every usage level. - Sales calls to get a number. Every meter is published. Run the calculator. Things we do charge for separately: - **SSO ($250/mo flat).** WorkOS bills us $125/mo per SAML connection plus audit-log streaming and setup overhead. One flat fee, on or off, available at any usage tier — no Enterprise upgrade required. - **Heavy telemetry volume.** Cardinality and write throughput are real ClickHouse costs. We charge $2 per 1M events from event one — most teams stay under the 5M/mo free threshold. - **Self-hosted edition.** Custom pricing because the cost model is different — no infrastructure for us, but support and engineering scale with deployment count. ### Frequently asked questions **What's the trial?** 30 days, full platform, no credit card required. Add a payment method whenever you're ready — billing starts the day you do, not the day you sign up. **Why a $5 platform fee if you're "usage-based"?** It covers the fixed cost of running the app, your git workspace, and customer auth — costs that don't scale with your usage. The fee stays $5 even if your usage is zero, and it filters out tire-kicker workspaces that we'd otherwise carry indefinitely. **How do you stay so much cheaper than the alternatives?** Most flag platforms price to extract — what's the most we can charge before this customer leaves? We picked a fixed multiple over our infrastructure cost and stuck with it. The result is the same answer for hobby projects and Series D companies: roughly 10x cheaper than the major alternatives, with the gap growing as you grow because we don't tax MAU or gate features behind a Pro tier. **What stops you from quietly raising prices later?** Nothing legally. Practically: predictable, low pricing is our wedge — raising prices quietly would cost us the trust that's the whole reason teams pick us. We review pricing annually and announce any changes 30 days in advance. **Do you charge per MAU?** Not directly. We charge for distinct context keys we store in telemetry — that scales with users somewhat, but it's a real cost driver (ClickHouse cardinality), not a markup designed to grow with your business. A customer going from 50K to 500K MAU sees their stored-context bill grow by far less than 10x because most users repeat across months. **What about self-hosted?** We offer a self-hosted edition for organizations with strict data-sovereignty requirements. Pricing is custom because the cost model is different (no infrastructure costs for us). Email hello@quonfig.com. --- ## Why Quonfig URL: https://quonfig.com/why ### Your config, your data, your rules You pay for a feature flag platform to store JSON in a database you'll never access. Every config change disappears into a proprietary system with no real audit trail. Your AI agents can't touch it. If you want to leave, good luck exporting. It doesn't have to be this way. ### What's broken about feature flag platforms - **No real version history.** There's a changelog UI. You can scroll through it. You can't diff two states. You can't revert to last Tuesday. You can't see who changed the pricing flag at 2am. - **You don't own your data.** Your config lives in their database. Want to export? Contact sales. Want to migrate? Good luck. Want a backup? Hope they have one. - **No real audit trail.** Your application code has git history with diffs, authors, and timestamps. Your feature flags — the things that control what users see — have a changelog you can't diff or revert. - **Agents can't work with it.** There's no CLI that speaks JSON, no structured output, no git repo to read. The best your AI agent can do is fumble with a REST API that returns paginated, unstructured responses. ### The old way vs. the Quonfig way Four areas where Quonfig is architecturally superior to a proprietary database. **Config storage.** LaunchDarkly: proprietary database, config locked behind their API; export requires enterprise plan; no standard format. Quonfig: JSON files in a git repo you own; export anytime, your data, your terms; open format, standard JSON. **Change history.** LaunchDarkly: dashboard changelog UI; no diffing between versions; no blame, no bisect. Quonfig: built-in audit trail powered by git history; see the exact diff between any two states; every change has an author, timestamp, and reason. **Agent integration.** LaunchDarkly: REST API with pagination and rate limits; unstructured responses; no git diff to review, no schema introspection. Quonfig: CLI with structured JSON output; it's just git — clone the repo and edit JSON directly; schema introspection and reviewable, git-diff previews built in. **Disaster recovery.** LaunchDarkly: call support; hope they have backups; no self-service recovery. Quonfig: clone your repo, you have the full history; migrate to any git host anytime; your data, your backup strategy; delivery fails over automatically to a warm standby on completely separate infrastructure. ### Three things other platforms can't offer Because your config is stored in a real git repo, you get guarantees no proprietary platform can match. - **You own your data.** Your config lives in a git repo you can clone anytime. No vendor lock-in, no export fees, no enterprise plan required to access your own data. If you want to leave, take your repo and go. - **A real audit trail.** Every config change has an author, a timestamp, and an exact diff of what changed. Not a proprietary changelog — a real version history you can query, diff, and revert with tools you already know. - **True disaster recovery.** If Quonfig disappears tomorrow, your config doesn't. Your SDKs keep working from cached config. Clone your repo and you have everything — full history included. --- ## Git-based feature flags URL: https://quonfig.com/git-feature-flags ### What git-based feature flags are 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. ### 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. - **One file per flag, not a row per flag.** The JSON 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` shows the ramp; `git revert ` takes it back to exactly where it was; and `git blame` says who set a rule and when. ### 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. But 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. But you operate it — the server, the availability, the upgrades, the on-call page at 3am. And non-engineers need a UI; 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. ### 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. ### 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. --- ## Migrate URL: https://quonfig.com/migrate ### Switch in minutes An agent does the work. You review the changes. Supported migration paths: - **LaunchDarkly** (https://quonfig.com/migrate/launchdarkly) — the big one. Full flag, segment, and environment migration. - **Flagsmith** (https://quonfig.com/migrate/flagsmith) — feature flags, segments, and identities. ### Free and local, or cloud and live One command either way, and the git repo is yours in both. Read it straight from disk for free — or sync it to Quonfig Cloud and every SDK gets the update the moment a flag flips. ### Five steps. Five minutes. 1. **Install the CLI.** One global install. Works on macOS, Linux, and WSL: `npm install -g @quonfig/cli` 2. **Run the migration.** Point the importer at your current account and let it run: `qfg migrate --from launchdarkly --source-api-key $YOUR_KEY --dir ./my-workspace` 3. **Agent translates your config.** Every flag, segment, and environment becomes a readable JSON file in a git repo. 4. **Review the pull request.** The agent opens a PR with your entire config. You review the diff. 5. **Merge. You're done.** Swap your SDK key and your apps connect to Quonfig. ### What gets migrated Feature flags, config values, segments, targeting rules, environment configs, and change history (as git commits). ### Before and after Migrating from LaunchDarkly: flags stored in a proprietary database becomes flags as JSON files in a git repo you own; a changelog UI with no diffing becomes full git history (log, diff, blame, revert); agent access via a paginated REST API becomes agent access via the CLI or just git. Migrating from Flagsmith: flags stored in Postgres or SQLite becomes flags as JSON files in a git repo you own; an audit log in the dashboard only becomes full git history; agent access via a paginated REST API becomes agent access via the CLI or just git. Full migration docs: https://docs.quonfig.com/docs/migrating/from-launchdarkly and https://docs.quonfig.com/docs/migrating/from-flagsmith --- ## Quonfig vs LaunchDarkly URL: https://quonfig.com/vs/launchdarkly Quonfig and LaunchDarkly are both feature-flag platforms, built for different priorities. LaunchDarkly is the mature enterprise default — the deepest feature set, a six-stage flag lifecycle, and a huge ecosystem, all cloud-only with config in a proprietary database. Quonfig stores every flag as a JSON file in a git repo you own and can clone, with 9 native SDKs and roughly 10x lower cost at scale. Bottom line: pick LaunchDarkly for the broadest enterprise suite; pick Quonfig if you want git-native, ownable config — built for the flag explosion of AI-written code. ### Feature comparison | Capability | Quonfig | LaunchDarkly | | --- | --- | --- | | Storage model | Every workspace is a real git repo. One JSON file per flag. | Proprietary cloud database. Flags accessed through the dashboard and REST API. | | Config-as-code / clone your data | Clone the whole workspace anytime with `qfg pull` or plain git. No export fees. | No clone-your-repo. Config lives in LaunchDarkly's cloud; export via API. | | Audit trail | `git log` — real author, exact diff, timestamp on every change. Full history, no retention cap. | Mature audit log and change history in the dashboard (retention varies by plan). | | Real-time delivery | Changes propagate via SSE / global edge in about a second. ETag caching, 60s safety-net poll. | Streaming flag updates over its global delivery network. | | Local in-process evaluation | Backend SDKs download full config and evaluate in-process — every check is a local, sub-millisecond function call. | Server SDKs also evaluate locally against streamed rule data. | | SDK breadth | 9 native SDKs (Node, Go, Ruby, Python, .NET, Java, Browser JS, React, React Native) at 1.0, plus 7 official OpenFeature providers. | Large, mature SDK ecosystem across most languages and platforms, plus OpenFeature support. | | Flag lifecycle / stale-flag detection | Lifecycle status (Pre-rollout / Rollout / Live) from production rules; cleanup is a reviewable git commit. | Deep six-stage flag lifecycle plus Code References that scan your repos for stale flags. | | Beyond flags | One platform: flags + dynamic config + runtime log levels + zero-knowledge secrets + prompts-as-config. | Flags, experimentation, and a broad enterprise feature set; positioned as a runtime control layer for AI. | | Pricing model | Fully public, usage-based on what delivery costs. Free seats. Live calculator. Roughly 10x cheaper at scale. | Usage-based: ~$8.33 per 1,000 MAU plus ~$10 per server connection. Gets expensive as you grow. | | Self-host / open-source mode | Own the git repo. Free + open-source mode reads JSON from a local dir with no account. | Cloud-only SaaS. No self-hosted or local file-based mode. | | Independent secondary delivery | Two fully independent delivery stacks on two different cloud providers, each serving its own git clone. SDKs fail over automatically on a network error or 5xx, then fall back to cached config and safe defaults. | One vendor-operated global delivery network, well run and mature. The redundant path is the Relay Proxy — a component you deploy, host, and operate yourself. | LaunchDarkly facts reflect its public rate card and documented product as of mid-2026. Quonfig SDKs and OpenFeature providers are at 1.0; the `qfg` CLI is pre-1.0. ### Which one should you pick? **Quonfig is best for:** teams who want flags stored as git files they own and can clone; AI-heavy codebases where flag churn needs a reviewable diff per change; anyone who wants the lowest TCO and fully transparent, public pricing; backend services that need sub-millisecond, in-process evaluation. **LaunchDarkly is best for:** large enterprises wanting the deepest, most mature feature set; teams that need the six-stage lifecycle plus Code References out of the box; buyers who prioritize the safe, established category default; orgs fine with cloud-only storage and per-MAU pricing. Quonfig in one line: git-native flags and config you own and can clone, 9 SDKs, sub-ms local evaluation, roughly 10x cheaper at scale. LaunchDarkly in one line: the most mature, deepest enterprise feature-management suite — the safe category default if config-as-code and cost aren't your top constraints. ### The core difference: who owns your config LaunchDarkly stores flags in its own cloud database; you read and edit them through the dashboard and REST API, which is excellent for governance but means there is no repo to clone and no config-as-code source of truth that lives with your code. That ownership difference compounds on auditing: LaunchDarkly offers a mature, well-built change log and audit features in its dashboard, but it's a product feature on top of a proprietary store, not a git log you can grep, blame, and revert with the tools you already use. ### Both pitch AI — but they mean different things LaunchDarkly has repositioned as a "runtime control layer for AI development" — governing what AI agents and applications are allowed to do at runtime. That's a real, valuable problem. Quonfig targets a different one: when AI agents write most of your code, you get flag explosion — flags created far faster than humans clean them up. LaunchDarkly's six-stage lifecycle and Code References are a more turnkey, mature take on stale-flag hygiene; Quonfig's bet is that the audit trail of the flags themselves should be git, not a dashboard. ### Pricing: roughly 10x cheaper at scale At a growing-SaaS tier our live calculator puts Quonfig near $122/month against roughly $980/month on LaunchDarkly's rate card. The reason is the pricing model: LaunchDarkly charges about $8.33 per 1,000 monthly active users plus roughly $10 per server connection, so your bill climbs with every user you add. LaunchDarkly's pricing buys a genuinely deeper enterprise platform; if your priority is the lowest total cost of ownership and transparent, predictable spend, Quonfig wins decisively. --- ## Quonfig vs Flagsmith URL: https://quonfig.com/vs/flagsmith Flagsmith is a solid open-source feature-flag and remote-config platform — self-hostable, with broad SDK coverage and OpenFeature support — and a good fit if running your own database is what you want. Quonfig is the better fit if you want config stored as JSON in a git repo you own, in-process flag evaluation that isn't billed per request, and typed code generation. Bottom line: both are open; Quonfig adds git ownership and predictable pricing at scale. ### Feature comparison | Capability | Quonfig | Flagsmith | | --- | --- | --- | | Storage model | JSON files in a real git repo (one file per key) | Relational database (Postgres or SQLite) | | Config-as-code / clone your data | Clone the repo anytime with `qfg pull` or plain git | Export via REST API; no repo to clone | | Audit trail | Git history — author, diff, and timestamp on every change | Audit log in the dashboard | | Real-time delivery | SSE + global edge in ~1s, ETag caching, 60s safety-net poll | Real-time updates and remote config | | Local in-process evaluation | Backend SDKs evaluate locally, sub-millisecond, no network per check | Local evaluation supported; default flow bills per request | | SDK breadth | 9 native SDKs at 1.0 + 7 official OpenFeature providers | Broad SDK coverage + OpenFeature support | | Typed code generation | `qfg generate` emits type-safe TypeScript render functions | Not offered | | Pricing model | Public flat pricing + free seats; not billed per flag check | Per-request + per-seat tiers (~$40 / ~$250) | | Self-host | Free + open-source mode: read JSON from a local dir, no account | Fully open-source and self-hostable | | Independent secondary delivery | Two independent origins on two cloud providers, each with its own git clone warmed from GitHub; SDKs fail over automatically | Single delivery path | Quonfig's 9 native SDKs (Node, Go, Ruby, Python, .NET, Java, browser JavaScript, React, React Native) are at 1.0, plus 7 official OpenFeature providers. The `qfg` CLI is pre-1.0. Typed code generation targets TypeScript. ### Which one should you pick? **Choose Quonfig** if you want your config in a git repo you own — with a built-in audit trail, in-process evaluation that isn't billed per request, typed TypeScript code generation, and transparent pricing that stays predictable as you scale. **Choose Flagsmith** if you want a mature, fully open-source platform you run on your own database, with combined flags and remote config, broad SDK coverage, and OpenFeature support — and a relational store fits how your team already operates. ### A git repo you own vs a database you query Flagsmith is open-source and self-hostable, which means you can run and back up the system yourself — a genuine strength. But the config itself lives in a relational database (Postgres or SQLite), and its history is a dashboard audit log rather than a repo you can clone, diff with familiar tools, and hand to an AI agent as plain files. When agents are writing most of your config changes, having every change land as a reviewable git commit is the difference that compounds. ### Per-request billing vs local in-process evaluation Because Quonfig flag checks never hit a metered endpoint, your bill does not grow with how often your code reads a flag. Flagsmith's paid tiers are built around per-request and per-seat pricing (roughly $40 and $250), and its free tier is a relatively stingy ~50k requests/month. Flagsmith does support local evaluation, but the default and free-tier flow is request-metered, so a chatty service or a sudden traffic spike can move your bill in ways that are hard to predict. Quonfig's flat, usage-tiered model is designed to give the same answer for a hobby project and a Series D company. ### Typed generation Both platforms cover the common stacks well on SDK breadth and OpenFeature. The difference is typed code generation: `qfg generate` parses your string configs and emits type-safe TypeScript render functions with each Mustache variable checked as a parameter. Flagsmith does not offer an equivalent. --- ## Quonfig vs Unleash URL: https://quonfig.com/vs/unleash Quonfig and Unleash are both self-hostable feature flag platforms with local, in-process SDK evaluation. The core difference is where your config lives. Unleash is a mature open-source FeatureOps control plane backed by an admin Postgres database. Quonfig stores every flag as a JSON file in a real git repo, so each change is a reviewable commit you can diff, blame, and clone. Choose Unleash for its proven self-host story and 25+ SDKs; choose Quonfig when you want git-native config, free seats, and a built-in audit trail that is just `git log`. ### Feature comparison | Capability | Quonfig | Unleash | | --- | --- | --- | | Storage model | Git repo — one JSON file per flag, self-hosted on Gitea | Admin Postgres database | | Config-as-code / clone your data | `qfg pull` or plain `git clone` — full history, no export step | Config lives in the DB schema; export via API or DB dump | | Audit trail | `git log` — real author, exact diff, timestamp per change | Event log in the admin UI / API | | Real-time delivery | SSE + global edge, ~1s propagation, ETag caching, 60s safety poll | SDK polling (default ~15s); streaming on newer setups | | Local in-process evaluation | Backend SDKs evaluate locally, sub-millisecond, zero network hop | Yes — SDKs evaluate locally against a polled snapshot | | SDK breadth | 9 native SDKs + 7 official OpenFeature providers | 25+ SDKs (community + official), broad language coverage | | Self-host | Open-source local mode — read JSON from a directory, no account | Mature, first-class self-host story (their core strength) | | Pricing model | Usage-based, free seats, public live calculator | Per-seat (~$75/seat/mo, 5-seat minimum on paid) | | Unified platform | Flags + dynamic config + runtime log levels + secrets, one engine | Flags + config (constraints, strategies, variants) | | Independent secondary delivery | Two independent origins on two cloud providers, each with its own git clone; SDKs fail over automatically, then fall back to cached config | Single delivery path; Unleash Edge/Proxy adds a tier you deploy and operate yourself | Where Unleash's column reads as "different in shape" rather than missing, that is deliberate — Unleash is a serious, credible tool. ### Best for… **Choose Quonfig** if you want your flag config to live in a git repo you own — every change a reviewable diff with an author and timestamp — plus free seats, usage-based pricing, and a unified platform that also covers dynamic config, runtime log levels, and secrets. **Choose Unleash** if you want a mature, battle-tested open-source FeatureOps platform with the broadest possible SDK coverage (25+) and a first-class self-host story, and you're comfortable with a Postgres-backed control plane and per-seat pricing. ### A git repo, not an admin database The single biggest difference is where your flags live. Unleash stores its config in an admin Postgres database — a solid, proven design, but your flag state lives inside their schema. To audit a change you read an event log; to leave you export through the API or dump the database. With Quonfig the storage format is just files in git, so your history is `git log`, your rollback is `git revert`, your backup is `git clone`, and there is no proprietary export format and no export fee. ### Both evaluate locally — Quonfig pushes changes faster Both platforms keep flag evaluation in-process, so there is no per-evaluation network hop. That is a genuine Unleash strength and Quonfig matches it. The delivery layer differs: Unleash SDKs poll for updates on an interval (commonly ~15 seconds by default), while Quonfig pushes changes over SSE in about a second, with ETag caching and a 60-second poll as a safety net. ### One targeting engine for more than flags, with free seats Quonfig spans feature flags, dynamic configuration, runtime log levels, and zero-knowledge secrets on one targeting engine and one audit trail. Unleash prices per seat (about $75/seat/month with a 5-seat minimum on paid plans), which is a common and predictable model but adds cost as your team grows. If you want product, ops, and support to all have access without per-head fees — and you want one tool instead of separate flag, config, and secret systems — Quonfig is the tighter fit. --- ## Quonfig vs ConfigCat URL: https://quonfig.com/vs/configcat ConfigCat is a solid, no-surprises feature flag service: simple flat pricing, unlimited team members on most plans, and one of the broadest SDK lineups around (30+). Quonfig is the git-native choice — every flag is a JSON file in a repo you can clone, changes stream over SSE in about a second, and self-hosting is open from day one. Bottom line: pick ConfigCat for flat-rate simplicity; pick Quonfig when you want to own your config and ship in real time. ### Feature comparison | Capability | Quonfig | ConfigCat | | --- | --- | --- | | Storage model | Git repo you own — one JSON file per flag | Closed, hosted config store (no repo to clone) | | Config-as-code / clone your data | `qfg pull` or plain `git clone`; no export fees | REST API + dashboard export; not git-native | | Real-time delivery | SSE push in ~1s, ETag caching, 60s safety-net poll | SDKs poll on an interval (auto/lazy/manual) | | Local in-process evaluation | Backend SDKs evaluate locally, sub-millisecond | SDKs cache config and evaluate locally too | | SDK breadth | 9 native SDKs + 7 OpenFeature providers | 30+ SDKs — one of the broadest in the market | | Pricing model | Usage-based, public live calculator, free seats | Simple flat per-plan ($110 / $325 / $900) | | Self-host | Open-source / self-hostable from the start | Dedicated tier only (~$4,500/mo) | | Audit trail | Git history — real author, diff, timestamp | Dashboard audit log + ConfigCat REST API | | Independent secondary delivery | Two separate origins on two cloud providers, each with its own git clone; SDKs fail over automatically | Single delivery path — config JSON served over one global CDN | Quonfig SDKs and the seven OpenFeature providers are at 1.0; the `qfg` CLI is pre-1.0. ConfigCat plan prices reflect their public pricing page and may change — check both vendors for current figures. ### Best for… **Quonfig** is best for teams who want to own their config and ship changes in real time. Git-native storage, SSE delivery in about a second, nine native SDKs plus OpenFeature, and open self-hosting from the start — ideal when an AI-heavy codebase is creating flags faster than humans retire them. **ConfigCat** is best for teams who want dead-simple flat pricing and the widest possible SDK coverage. With 30+ SDKs, unlimited team members on most plans, and predictable per-plan billing, ConfigCat is a reliable, low-overhead choice if config-as-code isn't a requirement. ### Git-native storage vs a hosted config store ConfigCat keeps your flags in its own hosted store. It exposes a dashboard audit log and a Public Management REST API, which is plenty for most teams — but there's no repo to clone and no config-as-code workflow. When AI agents are generating flag changes, a git-backed trail means every change is already a reviewable commit you can diff, bisect, and revert with tools you know. ### Real-time SSE delivery vs interval polling ConfigCat's SDKs poll on a configurable interval (auto-, lazy-, or manual-polling). That model is simple and reliable, and it caches config for fast local evaluation — but propagation speed is bounded by your poll interval, so a change can take as long as that interval to reach every client. Quonfig pushes over SSE in about a second, so flipping a kill switch reaches your fleet almost immediately without every process hammering the service on a tight interval. ### Self-hosting and pricing ConfigCat's strength here is predictability: flat per-plan pricing ($110 / $325 / $900) with unlimited team members on most plans makes the bill easy to reason about. The trade-off is that self-hosting is gated behind its Dedicated tier at roughly $4,500/mo, so on-prem or air-gapped deployments carry a much higher floor than Quonfig's open self-host path, which runs against a local directory of JSON with no account at all. --- ## Quonfig vs Flipt URL: https://quonfig.com/vs/flipt Flipt is a genuinely good open-source, self-hosted feature flag tool — single binary, config-as-code, a clean GitOps workflow. But two things should shape your decision. Flipt Cloud, its managed product, was shut down in August 2025. And the SDKs Flipt names "server-side" don't evaluate locally at all — they're REST clients that call the Flipt server over HTTP on every single flag check, putting your flag service directly in the request hot path. Quonfig takes the opposite approach. Backend SDKs download the full config once and evaluate in-process, so a flag check is a local function call that cannot time out. And config delivery runs on two fully independent stacks on different cloud providers, so a bad day for one of them isn't a bad day for your app. ### Feature comparison | Feature | Quonfig | Flipt | | --- | --- | --- | | Storage model | Git-native — every workspace is a real git repo, one JSON file per key. We host the git server (Gitea) for you. | Git-native config-as-code (or a relational DB). You host and operate the storage yourself. | | Config-as-code / clone your data | `qfg pull` or plain `git clone`, anytime. No export fees, no lock-in — the repo is yours. | Yes — flags live in files in your own repo. Strong GitOps story. | | Hosted / managed option | Yes — fully hosted UI and delivery. Nothing to deploy or operate. | No longer offered. Flipt Cloud was sunset in August 2025; OSS is self-host only. | | Real-time delivery | Changes propagate via SSE / global edge in about a second, with ETag caching and a 60s safety-net poll. | Client-side SDKs poll on a 120-second default interval. Streaming exists, but needs Flipt v2 — and delivery is yours to run and scale. | | How a backend flag check works | Local function call. Backend SDKs download the full config once and evaluate in-process — sub-millisecond, zero network round-trip in the hot path. | Flipt's server-side SDKs POST to /evaluate/v1/variant on the Flipt server for every evaluation. | | Local in-process evaluation | Standard on every backend SDK (Node, Go, Ruby, Python, Java, .NET). There is no remote-evaluation mode to accidentally pick. | Available — but only in a separate SDK family Flipt calls "client-side." The SDKs named server-side are the remote-evaluation ones. | | If the flag service is unreachable | SDKs fail over to the secondary automatically on a network error or 5xx, keep serving from locally-cached config, and fall back to safe defaults rather than crashing. | With a server-side SDK, every flag check fails — evaluation lives on the server. Client-side SDKs survive after boot, but default to an error strategy of Fail if Flipt is unreachable at startup. | | SDK breadth | Nine native SDKs (Node, Go, Ruby, Python, .NET, Java, Browser JavaScript, React, React Native), all at 1.0, plus seven official OpenFeature providers. | Native SDKs in several languages plus an official OpenFeature provider. | | Pricing model | Fully public usage-based pricing with a live calculator and free seats — roughly 10x cheaper than the major platforms at scale. Free open-source mode for local use. | OSS is free. Flipt Pro is $200/mo flat; Enterprise is custom. | | Self-host | Free + open-source mode: read JSON config from a local directory with no account or server. | Yes — single binary, zero-dependency self-host. This is its core strength. | | Audit trail | Built-in and git-powered: every change is a commit with real author, diff, and timestamp. Full history, no retention limits. | Git history of your config files — as complete as your own repo and review process. | | Independent secondary delivery | A second, fully independent delivery stack — the same Go binary on a different cloud provider, serving its own git clone warmed from GitHub. SDKs fail over to it automatically. It is not a cache in front of one origin; it is a separate origin. | Up to you — availability is whatever you build, host, and operate. A single Flipt server is a single point of failure for every evaluation made through a server-side SDK. | 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; this comparison is for evaluation purposes and reflects our reading of their published docs. ### Which one fits your team? **Quonfig is best for** production backends that cannot afford a network call — or a network failure — on every flag check. Two fully independent delivery stacks on different cloud providers, with automatic SDK failover and safe defaults. Git-native config ownership without running the infrastructure: hosted UI, SSE delivery, nine native SDKs, seven OpenFeature providers. Built for the age of AI-written code: every flag change an agent makes is a reviewable git commit. **Flipt is best for** teams that want to self-host and operate their own feature-flag infrastructure — an excellent open-source, single-binary, zero-dependency choice with a clean GitOps workflow. Caveats: the SDKs named "server-side" evaluate remotely (one HTTP call per flag check, with the Flipt server in your hot path), and there is no longer a managed/hosted product. ### 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 an HTTP POST awaited inline: no cached ruleset, no snapshot to fall back on — the answer only exists on the server. A Quonfig backend check is `quonfig.isEnabled("new-checkout")` — no await, no socket, no timeout, no dependency on us being reachable right now. That couples your application's availability to the flag service. If Flipt is slow, your endpoints are slow. If Flipt is unreachable, every flag check fails at once — and flag checks 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 the failure mode a feature flag is supposed to protect you from. To be fair, Flipt does have local evaluation — in a separate SDK family it 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 caveats 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 when you can least afford your flag vendor to be having an outage. Quonfig runs delivery on two fully independent stacks: the same Go binary on two different cloud providers, each serving its own git clone, each warmed independently from GitHub. That is not a CDN cache in front of a single origin — a cache still fails when its origin fails. These are two separate origins, and every SDK fails over between them automatically. 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. ### The managed git-native gap 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: config-as-code in a real git repo — one JSON file per key, full history as `git log` — without standing 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 and clone 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. 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. --- ## About URL: https://quonfig.com/about ### We think your feature flags belong in git Quonfig is a feature flag and configuration platform with one unusual property: your config is stored as JSON files in a real git repository, not as rows in a database you have no access to. Every change is a commit with an author, a diff, and a timestamp — and you can clone the whole thing whenever you want. ### A flag platform that keeps its data in the open Creating a flag writes a file. Flipping it in production writes a commit. Asking who changed the pricing flag at 2am is `git log`, not a support ticket. That is the whole trick, and everything else about Quonfig follows from it. The rest is a normal, modern platform: a UI for people who would rather not hand-edit JSON, environment-scoped targeting rules, percentage rollouts, reusable segments, dynamic config values and log levels alongside the flags, and real-time delivery to processes that are already running. We simply refused to make the storage layer proprietary. Your workspace is a git repo we host for you, and you can walk away with all of it at any time. Quonfig is built by Jeff Dwyer, who started it in 2026 after several years building Prefab, an earlier feature-flag and dynamic-config platform. Prefab taught us what teams actually do with flags at scale, and where a database-backed design runs out of road once agents start creating them. Quonfig is the second attempt, with the storage decision made the other way, and Prefab's customers moved across with it. ### Why git-native, and why it matters more now Feature flags are code-adjacent state. A flag decides what your users see, which makes it exactly as load-bearing as the code around it. Yet on most platforms that state lives somewhere your code review never reaches: no diff, no blame, no revert, no way to bisect a bad Tuesday. You would not accept that for a config file in your repo, and you should not accept it for a flag either. The second half of the argument is newer. When agents write the code, flags get created far faster than humans retire them. A model can open a flag, ship behind it, and move on inside a single afternoon; nobody is going to remember to clean that up six weeks later. In that world the interesting problem stops being "can I toggle a boolean" and becomes lifecycle and auditability — what exists, who made it, why, and whether it is safe to delete. Git already answers those questions well for code. Keeping config in git means it answers them for config too. So the storage is deliberately boring: one JSON file per key, in a repository you can clone with `qfg pull` or with plain git. If Quonfig disappeared tomorrow you would still hold every flag, every value, and every change ever made to them. ### Four decisions that shape the product - **Backend SDKs evaluate locally.** Backend SDKs download your whole config and evaluate every check in-process — sub-millisecond, with no network call on the hot path. An evaluation does not depend on our servers being reachable at that instant. - **Changes stream, they don't poll.** Updates propagate to running processes over SSE in about a second, so a flag flip reaches production without a deploy and without a polling interval to tune. Delivery also fails over automatically to a warm standby on separate infrastructure. - **The surface is open, not just the storage.** Nine native SDKs, seven OpenFeature providers, the `qfg` CLI, a REST API at https://api.quonfig.com/v1 with a published OpenAPI spec, and an MCP server at https://mcp.quonfig.com/mcp. Nothing about your config is reachable only through our UI — which is what makes it usable by an agent as well as a person. - **We run on it.** Quonfig's own services read their flags and config from a Quonfig workspace. The prompt behind our schema-inference feature lives in a config file rather than in our source code, so tuning it is a commit and not a redeploy. ### Get in touch If you are evaluating Quonfig, migrating off something else, or you have hit an edge the docs do not cover, tell us. Email goes to the people who build the product, not to a queue: hello@quonfig.com. Bugs and feature requests are welcome as issues at https://github.com/quonfig. Full contact details are at https://quonfig.com/contact. --- ## Contact URL: https://quonfig.com/contact ### Talk to us One inbox, one GitHub org, one docs site. There is no support tier to buy, no ticket queue to be triaged into, and no contact form that quietly routes you into a sales sequence. Email reaches the people who build Quonfig. ### Three ways to reach us - **Email — hello@quonfig.com.** Product questions, evaluations, migrations, and billing and account changes. If you are not sure where something belongs, it belongs here. Security reports go to security@quonfig.com. - **GitHub — https://github.com/quonfig.** The SDKs, the OpenFeature providers, and the `qfg` CLI live here. Bug reports and feature requests are welcome as issues on the repo they affect. - **Docs — https://docs.quonfig.com.** SDK guides for every supported language, the `qfg` CLI reference, and the configuration concepts. Most "how do I…" questions are answered here faster than we can answer them. ### Engineers read the inbox Everything sent to hello@quonfig.com is read by people who work on the product, so the person who answers you is usually the person who can fix the thing you are writing about. That cuts out the layer where a support agent relays your question to engineering and relays a guess back. You can help us skip a round trip: tell us what you were doing, what you expected, and what actually happened. If it is an SDK question, include the language and the version. If it is about a specific flag or config value, include your workspace slug and the key — never paste an API key, a secret value, or an encryption key into an email. Mail is read by the founders, and the reply comes from a person, not an autoresponder. ### Where do I… - **Report a bug.** Open an issue on the repo it affects at https://github.com/quonfig — the SDK, the provider, or the CLI. Include the version, a minimal reproduction if you have one, and what you expected instead. If the bug is in the app or in delivery rather than in a package, email us. - **Ask how something works.** Start at https://docs.quonfig.com. If the docs do not answer it, email hello@quonfig.com and say which page you were on when you gave up — that is a docs bug on our side. - **Request a feature or an SDK.** A GitHub issue is the best home for it, because other people can find it and add their case. Email works too, especially if you would rather not describe your use case in public. - **Report a security issue.** Email security@quonfig.com, and please do not open a public issue for a suspected vulnerability. We will confirm receipt and keep you updated while we work on a fix. Our machine-readable contact is at https://quonfig.com/.well-known/security.txt. There is no bug bounty program at this time. - **Sort out billing or your account.** Email hello@quonfig.com from the address on the account and include your workspace slug. Plan changes, invoices, seat counts, and cancellations all go to the same place. - **Ask about data, privacy, or terms.** The Privacy Policy (https://quonfig.com/privacy) covers what we collect and how it is used, and the Terms of Service (https://quonfig.com/terms) cover the rest. Anything they leave open goes to hello@quonfig.com. Quonfig is operated by MHW Works LLC. --- ## API & agents - **REST API** (https://api.quonfig.com/v1): Public REST API for flags, config, and segments. Bearer auth with a workspace-scoped API key — `qf_uk_*` for a user, `qf_sa_*` for a service account — and the workspace acted on is inferred from the key. - **OpenAPI spec** (https://app.quonfig.com/public-api/v1/openapi.json): Machine-readable OpenAPI description of every public endpoint. - **API reference** (https://app.quonfig.com/public-api/v1/docs): Browsable HTML reference for the same endpoints. - **MCP server** (https://mcp.quonfig.com/mcp): Model Context Protocol server over Streamable HTTP. Authenticate with a Bearer API key, or with OAuth — protected-resource metadata (RFC 9728) at https://mcp.quonfig.com/.well-known/oauth-protected-resource/mcp, authorization server https://nifty-tint-21.authkit.app. - **CLI** (https://docs.quonfig.com/docs/tools/cli): `npm install -g @quonfig/cli` installs `qfg`, the scriptable client for reading and writing flags, config, and secrets from a terminal or a script. - **Agent skill** (https://docs.quonfig.com/docs/tools/agent-skill): Installable skill (github.com/quonfig/skills) that teaches coding agents to use Quonfig in an application repo — SDK setup per language, `qfg create` / `set-default` / rollouts, MCP tools, and flag retirement. Install with `claude plugin marketplace add quonfig/skills && claude plugin install quonfig@quonfig`, `qfg agent install-skill`, or `npx skills add quonfig/skills --skill quonfig`. When to reach for Quonfig: - Manage the whole feature-flag lifecycle from code — create a flag, ship behind it, roll it out, then retire it — without leaving the terminal. - Read and flip flags, dynamic config values, and log levels programmatically over the REST API or `qfg`. - Audit how any value got to its current state: every change is a git commit with author, diff, and timestamp. - Wire flags and config into an agent workflow over MCP, so an agent reads and updates them as first-class tools. ## Docs - Documentation: https://docs.quonfig.com — SDK guides, CLI reference, and configuration concepts. - Blog: https://quonfig.com/blog — engineering posts on feature flags, dynamic config, dynamic logging, and the flag lifecycle in the age of AI-written code.