The headline this week is short: every Quonfig SDK is 1.0.0.
The whole family — backend, browser, mobile, and every OpenFeature provider — stamped 1.0.0 on the same day. From here on we follow semver: pin a Quonfig SDK today and it keeps working the way it works today.
We've been building toward this for months, and the last few weeks were deliberately boring on purpose: fit-and-finish, a clean version matrix, no new headline features. That's the rhythm I wanted before cutting 1.0s. Now they're cut.
What "1.0.0 everywhere" actually covers
This is the part I'm proud of — the breadth. You can adopt Quonfig in basically any stack you already run:
Backend SDKs (1.0.0): Node, Go, Python, Ruby, Java, and .NET. Same evaluation semantics, same targeting rules, same wire contract across all six.
Frontend & mobile SDKs (1.0.0): a browser/JavaScript SDK, React bindings (provider + hooks), and a React Native wrapper.
OpenFeature providers (1.0.0): official providers for Node, Web, Go, Ruby, Python, .NET, and Java. If you've already standardized on OpenFeature, Quonfig slots in behind the interface you already wrote against — no rip-and-replace.
Nine SDKs and seven providers, all at the same version, all published to their native registries (npm, PyPI, RubyGems, NuGet, Maven Central, Go modules) the same day. Every consumer app and service we run was re-pinned to 1.0.0 and is running on it.
Why this is ready for production
A version number is just a promise. Here's what's behind it.
It's serving real production traffic, in multiple regions. Our delivery layer runs split read and streaming paths across iad, nrt, and lhr. The SDKs hold their config in memory and keep evaluating from that cache if the network blips — your app doesn't stall waiting on us.
Real-time updates that don't hammer your infra. Backend SDKs hold an SSE connection and get config changes pushed within moments of a save. Browser SDKs poll with conditional requests — an ETag fast-path means an unchanged config comes back as a tiny 304, not a full re-download. Flip a flag in the dashboard and live clients pick it up without a redeploy and without a thundering herd.
Type-safe access, generated from your own config. qfg generate reads your workspace and emits typed accessors, so a flag or config key is a method call your compiler checks — not a stringly-typed lookup that fails at runtime. Rename a key and your build tells you what broke.
Date and time targeting that works end-to-end. You can write rules against the current time — schedule a flag to flip on at a date, run a window, target by timezone — and author all of it in the dashboard's rules editor with a real date/time picker.
Your config is just JSON in git. This is still the thing that makes Quonfig different. Every config change is a commit you can read, diff, review, and roll back with tools you already have. Nothing disappears into a database you can't reach. Your AI agents can read it. Your auditors can read it. You own it.
Copy and paste targeting values like a spreadsheet
Smaller than 1.0, but it's the dashboard change I use most. Rules that target a list of values — "user.email ends with one of …", "account.id is one of …" — used to be fiddly to edit by hand. Two changes fixed that:
- Every value is a copyable pill. Hover a value in a rule and a copy icon appears — click it to grab that exact value. Multi-value lists get a copy-all so you can lift the whole set at once.
- Paste forms pills automatically. Drop a comma-separated or newline list — straight from a spreadsheet, a SQL result, or another rule — into the value field and it splits into separate, deduplicated pills instead of one mangled blob.

It round-trips, too: copy-all out of one rule, tweak the list, paste it into another. Copying a batch of account IDs from a query into an "is one of" rule is now a two-second job instead of a careful comma-by-comma paste.
A local-first dev loop with no account required
One of the things I most wanted for 1.0 was for Quonfig to feel great before you sign up for anything.
Every backend SDK now supports datadir mode with auto-reload: point the SDK at a directory of JSON config, and an opt-in file watcher reloads in place when you edit it. It's debounced and parse-then-swap, so a half-saved file never blanks out your config. Edit a flag, hit save, your running app sees the new value. No network, no account, no key.
The browser, React, and React Native SDKs are network clients by design, so they got qfg serve — it boots a local SDK in datadir mode and serves the exact same response shape our production delivery service returns. Your frontend gets the same edit-save-reload loop locally, against a contract that matches prod.
There's now a docs page and a Next.js tutorial that take you from create-next-app to a server component reading a flag without ever creating an account. Try it that way first.
Where that leaves us
The version matrix is the cleanest it's ever been — every SDK and provider tagged at 1.0.0, every consumer re-pinned, CI green. The SDKs are stable, semver-committed, and running in production across three regions.
If you've been waiting for Quonfig to feel ready for real workloads: it's ready. Pull down whichever SDK matches your stack — they're all 1.0.0 now.
-- Jeff
Want to try it?
Quonfig stores your config in git. Feature flags, dynamic config, log levels, and secrets — all as files you own.