Use Case · Product

Multi-tenant SaaS on the Software Lifecycle Cloud

Multi-tenant SaaS on KERNSTACK isolates customers inside one declared project: tenant id is part of the table keys, per-tenant API keys guard the gateway routes, quota counters live beside the tenant’s data, and a tenant’s entire slice can be listed, exported, or deleted as keyed operations. Isolation here is an engineering discipline the stack makes explicit — not a promise made by a vendor’s marketing page.

Functions (WASM)NoSQL TablesEdge Gatewaystack.json IaC
Talk to us Read Technical Documentation → Software Lifecycle Cloud →

The engineering bottleneck with assembled stacks

Platform owners discover multi-tenancy is not a feature but a hundred small decisions: whose key goes in which index, which counter enforces whose quota, how one noisy tenant is throttled without a war room, and how a departing tenant’s data is provably gone. Assembled stacks scatter those decisions across services until none of them can be reviewed together.

Architecture on the Software Lifecycle Cloud

Every tenant-owned table keys on tenant id, with the entity id as sort key. Gateway API keys are issued per route and mapped to tenants in a tenants table; functions resolve the tenant from the key, never from request input. Quotas are counters in the tenant’s own slice, incremented by the same writes they limit, so enforcement and evidence are one record.

Noisy neighbours and quota honesty

A tenant melting the shared project is a when, not an if. Counters beside the data make the response boring: the handler checks the tenant’s counter against the plan limit declared for them and sheds load for that tenant only. Because the counter and the data share a slice, the conversation with the tenant starts from records both sides can inspect.

  • Tenant export and erasure are keyed operations on a declared slice — provable, repeatable, logged
  • Per-tenant keys rotate from stack.json; a leaked key endangers one tenant, not the platform
  • One project to plan means a tenancy change is reviewed once, as a diff, by everyone it affects

The isolation ceiling, stated

Shared-project multi-tenancy isolates data and quota, not physics: all tenants share the zone’s infrastructure. Regulated tenants who contractually need separate infrastructure get a separate KERNSTACK project — the declaration copies over, which is exactly the portability the stack.json model buys. Choosing per-tenant projects is an operations decision, not a rewrite.

FAQ

Frequently asked questions

Deletion is a keyed sweep over the tenant’s slice in every table plus their bucket prefix, followed by the deletion record. Because tenancy was key design from day one, “everywhere their data lived” is enumerable rather than archaeological.

Yes. The same stack.json declares a dedicated project for a tenant whose contract demands infrastructure separation; their slice migrates as an export between identically-shaped systems. The application code barely notices.

In counters in the tenant’s slice, incremented alongside the work they meter. Handlers enforce limits from those counters, and billing reads the same rows — one record serves the limit, the invoice, and the dispute.

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 · ComputeFunctionsGo WebAssembly HTTP handlersService · DataTablesServerless key-value and document tablesService · EdgeGatewayHTTP, WebSocket, and prefix routesService · Manifeststack.jsonOne manifest for the whole projectIndustry SolutionE-commerce Cloud SolutionsE-commerce on KERNSTACK owns the parts of commerce that constitute the business: the catalogue and its search, carts and checkout state, the order lifecycle, raw payment events reconciled into provable order states, and fulfilment workflows with human steps for the exceptions. Cards stay with the payment provider; the data that makes the business worth buying moves onto infrastructure the merchant controls, in Europe.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.

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 →