The Coffer

What it is

The Coffer holds short key-and-value pairs — feature flags, settings, counters, session fragments — in memory so reads and writes come back in milliseconds. It answers over a REST API and is also bound into Edge Functions, which means your app and your edge code always read the same values with no extra plumbing. Feature flags are built in: turn a feature on for everyone, for a fixed share of visitors, or for one workspace, and change it without a deploy. Values are scoped to your workspace and namespace, so one tenant never reads another’s keys. This is a small, fast coordination store for flags and hot counters — not a replacement for The Cellar when you need queries, relations, or durable documents.

Cloudflare analogue: Workers KV. SLA 99.99% · p99 6ms. Operators write keys and flags. Namespaces and rollouts are scoped to the workspace.

• ▸REST API plus an Edge Functions binding
• ▸Feature flags with percentage rollouts
• ▸Millisecond reads from memory
• ▸Namespace and workspace scoped

How it works

Write a key over the REST API. Reads and writes come back in milliseconds from memory — this is a small, fast coordination store.

The same store binds into Edge Functions, so your app and your edge code always read the same values with no extra plumbing.

Feature flags are served from the same keyspace: enable one for everyone, for a percentage of visitors, or for a single workspace — then change it without a deploy.

Keys are scoped to a namespace and your workspace, so one tenant never reads another’s values. Values are AES-256-GCM at rest.

Use cases

Concrete ways teams use this service on day one.

Set it up in the dashboard

Dashboard → Database → The Coffer → Keys: browse by namespace, edit a value, set a TTL.

Flags: create a flag, set a rollout percentage, override by workspace.

Configure: default TTL, feature flags on/off, namespace isolation (always on), read locality.

API

Control-plane: GET|PUT|DELETE /api/v1/coffer/kv · GET|POST /api/v1/coffer/flags. Send Authorization: Bearer tz_live_YOUR_TOKEN.

Creates count against the plan quota. A 402 plan_limit means you are at the cap — upgrade or delete an unused resource.

curl -sS -X PUT https://tinyzipper.com/api/v1/coffer/kv \
  -H "Authorization: Bearer tz_live_YOUR_TOKEN" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{"namespace":"flags","key":"checkout-v2","value":"on"}'

curl -sS https://tinyzipper.com/api/v1/coffer/kv?namespace=flags&key=checkout-v2 \
  -H "Authorization: Bearer tz_live_YOUR_TOKEN"

curl -sS -X POST https://tinyzipper.com/api/v1/coffer/flags \
  -H "Authorization: Bearer tz_live_YOUR_TOKEN" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{"key":"checkout-v2","rolloutPercent":10}'

const res = await fetch("https://tinyzipper.com/api/v1/coffer/kv", {
  method: "GET",
  headers: {
    Authorization: `Bearer ${process.env.ZIPPER_TOKEN}`,
    "Content-Type": "application/json"
  }
});
const json = await res.json();
if (!res.ok) throw new Error(json.error ?? res.statusText);
console.log(json);

Tips

Treat values as small: settings, flags, counters — not documents or query results.

Set a TTL on anything ephemeral so the store never fills with dead keys.

Percentage rollouts are per key and take effect on the next read.

Need queries, relations, or durable rows? That is The Cellar — the Coffer is for hot, tiny, shared state.

• ▸SOC 2
• ▸AES-256-GCM
• ▸Workspace-scoped keys

Runbook

Reads and writes go over REST or the Edge Functions binding — both hit the same store. Flags take effect on the next read; roll a flag out by percentage before going to everyone. Namespaces keep tenants apart.