Feature flags without a deploy

Some values in your codebase have no business being in your codebase.

The homepage banner text. The percentage off in the summer promotion. The flag that hides a half-finished checkout from everyone except your team. Each of these is a one-line change that costs a pull request, a review, a CI run and a deploy — and the person who actually wants it changed usually cannot make the change themselves.

Config is a key-value store, and that is the point

Kookee's Config module stores any JSON-serializable value under a key, and hands it back over the same SDK as the rest of your content:

const flag = await kookee.config.getByKey('feature-new-checkout');

if (flag.value === true) {
  // new checkout
}

Values are not limited to booleans, which is where it gets genuinely useful. A whole UI configuration can live under one key:

const banner = await kookee.config.getByKey('homepage-banner');
// { text: 'Summer Sale!', enabled: true, color: '#ff6b00' }

Or a business rule your finance team wants to own:

const discount = await kookee.config.getByKey('pricing-discount');
// { percentage: 20, minOrderValue: 50 }

Fetch what you need, in one call

Fetching keys one at a time on every page load is the obvious mistake. list() takes a key filter:

const configs = await kookee.config.list({
  keys: ['homepage-banner', 'feature-new-checkout', 'pricing-discount'],
});

One request, three values. Pull them once per render on the server, or once at app boot on the client, and pass them down. Every config read is an API call against your monthly request allowance — on the Free plan that is 10,000 requests a month, so caching is not premature optimization here, it is the normal way to use it.

Version history is the safety net

Editable-in-production is only comfortable if mistakes are cheap. Every config change in Kookee creates a snapshot, and any version from the last 30 days can be restored with one click.

That changes the risk profile of handing a key to a non-engineer. The worst case for a mistyped discount is not an incident with a hotfix deploy — it is a rollback in the dashboard, done by the same person who made the change, in the ten seconds after they notice.

Descriptions matter more than they sound like they should, for the same reason. enable-v2 means nothing to the person who inherits it in six months. Write the description when you create the key.

Where Config stops

Config is deliberately simple: a key, a value, and history. It does not do percentage rollouts, per-user targeting, or A/B assignment. If you need to show a feature to 5% of users in Germany, you want a dedicated experimentation platform, and you should use one.

What Config covers is the much more common case — a global value your team needs to change without shipping code. That is most flags, most of the time. It also means the flag lives next to your blog posts, help articles and changelog, behind the same API key, instead of being a fourth vendor in your stack.

A reasonable pattern is to keep a default in code and let Config override it:

let showNewCheckout = false;

try {
  const flag = await kookee.config.getByKey('feature-new-checkout');
  showNewCheckout = flag.value === true;
} catch {
  // network hiccup — keep the safe default
}

Now the flag is remote, and an unreachable API degrades to your last known-good behavior instead of an exception on the checkout page.