osFoundry / Platform
Per-app KV store
Redis-compatible KV with TTLs. Sessions, caches, counters — sized to your app.
What it is
Per-app KV store gives every app you build inside osFoundry its own Redis-compatible key-value backend. If you already know Redis, you already know this: set a key, read it back, increment a counter, attach a time-to-live so the entry expires on its own. Each app gets its own isolated namespace, so one app's session keys never collide with another's cache entries. There is no separate Redis server to provision, secure, or keep alive — the store is part of the app runtime, sized to the app that uses it.
The TTL is the point of a KV store, and it works the way you expect. Write a session token with a 30-minute expiry and it disappears when the window closes; cache an expensive API response for five minutes and let it refresh itself; hold a short-lived lock or a rate-limit window that clears automatically. Because keys expire without a cleanup job, you store ephemeral state without accumulating garbage. Counters are first-class too — atomic increment and decrement give you view counts, quota tracking, and simple sequence numbers without read-modify-write races.
This fits osFoundry's shape as a bring-your-own-key desktop workspace where chat, agents, apps, code, knowledge, and data live in one place. The KV store is the fast, ephemeral tier that sits alongside your app's other data: use it for anything that is hot, small, and short-lived, and keep durable records elsewhere. Being Redis-compatible means the mental model and command vocabulary carry over from anything you have built before, so you are not learning a new API to get sessions and caches working.
Key capabilities
- Redis-compatible key-value API — GET, SET, INCR, EXPIRE and the commands you already know, no new client to learn
- Per-key TTLs so sessions, cache entries, and locks expire on their own with no cleanup job to run
- Isolated per-app namespace — each app's keys are scoped to that app and never collide with another's
- Atomic counters via increment/decrement for view counts, quotas, and rate-limit windows without race conditions
- Runs as part of the app inside osFoundry — nothing to provision, and the store is sized to the app that uses it
Use cases
- App developer: store login sessions with a sliding TTL so users stay signed in and stale tokens clear themselves
- Backend builder: cache slow third-party API responses for a few minutes to cut latency and repeated calls
- Agent tooling author: keep a per-minute rate-limit counter that resets automatically via an expiring key
Frequently asked questions
Is it actually Redis, or just Redis-like?
It is Redis-compatible, meaning it speaks the same key-value commands and semantics you already use — SET with an expiry, GET, INCR, DEL — so existing habits and code patterns transfer. The value is that it is built into the osFoundry app runtime, so you do not stand up or secure a separate Redis server to get it.
What should I keep in the KV store versus a real database?
Use KV for hot, small, short-lived state: sessions, caches, counters, rate-limit windows, and locks — anything you are happy to have expire. Keep durable records that must survive and be queried in a proper database. The KV store is the fast ephemeral tier, not your system of record.
Do TTLs expire keys automatically?
Yes. When you set a time-to-live on a key, it is removed once that window passes, with no cleanup job on your side. That is what makes it a good fit for sessions and caches — the data that should be temporary clears itself instead of piling up.