Use Case · Product

Session store on the Software Lifecycle Cloud

A session store on KERNSTACK is the unglamorous pattern done as declared data: session rows in a table keyed by session id, carrying the user, the device hint, and the expiry; functions read and write them at request time; and a periodic sweep removes the dead. No sticky load balancing, no server whose memory is a single point of truth, no separate cache cluster to babysit.

NoSQL TablesFunctions (WASM)Approval Workflows
Talk to us Read Technical Documentation → Software Lifecycle Cloud →

The engineering bottleneck with assembled stacks

API owners keep session state in process memory because it starts that way in the first demo. Then a second instance appears, logouts do not propagate, deploys log everyone out, and the fix — an external cache — arrives as another vendor with its own failure modes to explain a seven-line concept: who is this, and until when.

Architecture on the Software Lifecycle Cloud

Create-session writes a row with a random id, the user key, and an expiry timestamp. Each authenticated request does one keyed read; expiry is checked against the row, sliding if your policy slides. Revocation is a delete, effective everywhere instantly because there is exactly one copy of the truth. Worker and function handlers share the table, so websocket and HTTP faces of the app agree about who is connected.

Expiry as data beats expiry as configuration

Because expiry is a timestamp on the row, policy questions become data questions: how many sessions older than X exist, which devices hold this user’s sessions, what happens to remember-me tokens at password change. The sweep that deletes expired rows also produces the counts, and “log out everywhere” is a keyed delete over one user’s rows.

  • One keyed read per request; no cache cluster, no stickiness, no lost sessions on deploy
  • Revocation and logout-everywhere are deletes that take effect on the next request
  • Device hints on the row make “unknown device signed in” a query, not a forensic project

When not to build this

If your framework’s session handling already runs stateless tokens and your revocation story is honestly “wait for expiry”, keep it. A table-backed store earns its rows when instant revocation, device visibility, or cross-surface sessions (web, mobile, websocket) are requirements rather than decorations.

FAQ

Frequently asked questions

It is a single keyed table read — the fastest access pattern the platform has — performed inside the function handling the request. No extra service hop and no cache invalidation logic stand between the request and the answer.

Handlers reject expired rows on sight, and a scheduled sweep deletes them in batches so the table stays lean. Both behaviours are project code, reviewed and adjusted like everything else in the stack.

Yes. Sessions are rows with device hints, so listing a user’s active sessions and revoking any of them is ordinary table work surfaced by your own API — the feature support teams keep asking for, without a new system.

Connected in the Project Graph

Related capabilities, architectures, and comparisons

Category PillarThe Software Lifecycle CloudWhy people and agents build, deploy, and operate on a single vertically integrated stack.Service · DataTablesServerless key-value and document tablesService · ComputeFunctionsGo WebAssembly HTTP handlersService · OrchestrationWorkflowsDurable workflows with human pausesIndustry SolutionHealthTech Cloud SolutionsHealthTech products on KERNSTACK hold care-adjacent data — patient documents, encounter records, consent forms — in one declared project in a European zone on named infrastructure. The needs that dominate are unglamorous and absolute: know exactly where every document lives, who touched it, how consent was captured, and how a record can be frozen the day a legal hold arrives.Use Case · ProductExperiment assignmentAssignment is a pure function of the subject key and the experiment’s salt — stable across requests, no coordination needed. The function records the assignment row once and serves the variant; outcome handlers were already writing events, which now simply carry the experiment id the assignment returned. Analysis reads assignments and outcomes from neighbouring tables with the same keys.Use Case · AgenciesAgency client deliveryThe studio’s delivery shape is a template stack.json: gateway, functions or workers in the client’s stack languages, tables, buckets, and apps under one target per client, on European infrastructure the studio can name in the pitch. Previews run the same declaration; the client’s approval happens in the bound conversation with a live link. Every client’s meter is separate by construction — the studio sees delivery cost per client without allocation spreadsheets.Use Case · AgentsAgent operations consoleThe raw material already exists in the project: hosted git lists branches including agent/<id>, each agent branch maps to its environment, and every deploy begins as a plan a person approved. The console view arranges that material — branch, environment URL, plan summary, approval state — into the board engineering managers actually ask for, with conversations and board topics carrying the discussion around each run.

Ship your stack on the Software Lifecycle Cloud.

Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.

Talk to us See pricing & credits →