CodeMonster.ai · by Knomatic How your customers’ data is kept apart.
Row-level, explicit, and enforced at the platform — not by convention in the app.
Every object your app creates is a real table row that carries a tenant. The platform filters on that column for you, refuses to write without it, and never lets a client reach the control-plane tables directly. This page says exactly what that is — and what it is not.
Row-level tenancy
Objects are data entities backed by real Postgres tables. Every object table automatically carries a tenant column alongside its id and timestamps, and every read the platform issues injects a filter on that column. Object views — the SQL-backed views behind production grids — inject the same tenant filter, so a JOIN across objects returns one tenant’s rows rather than a mix.
Workflow work items carry the tenant too, so an approval or notification raised in one tenant is processed as that tenant’s work and no one else’s.
Explicit tenant context
An agent does not inherit a tenant by accident. Tenant context is explicit and per session: the agent calls list-tenants, then use-tenant, and only then can it write data. A data write without a tenant set fails fast with Tenant context required — the operation is refused, not defaulted.
whoami and ping let the agent — or a reviewer reading the log — confirm which identity and tenant a session is acting under before anything is written.
Many tenants, one account
One account can host many tenants for its own customers. An agency builds an app once and serves each client as a tenant of that app; an internal team keeps each business unit’s records apart under one license. Isolation is enforced at the data layer within your account.
That is the honest shape of it: multi-tenant per account, not a dedicated installation per customer. If your requirement is a separate database, cluster, or distribution per client, we do not meet it today. Tell us on the first call and we will say so there rather than in week six.
Control-plane tables: API access only
The tables that record apps, versions, deployments, edit sessions, and tool invocations — our control plane, not your app data — have Row-Level Security enabled and are reachable only through the API’s service role, after application-level role checks. There is no direct client access, so a leaked browser session cannot read those control-plane records through a database client.
Your object data sits behind the platform API, which authorizes every call and injects the tenant filter — a different mechanism, described above.
File storage
Files uploaded through platform apps — photos, signatures, documents — go to object storage and move through time-limited signed URLs for both upload and download. Custom-frontend build artifacts sit in buckets closed to the public and are readable only by the CDN through origin access control; a direct storage URL returns 403.
Data location and encryption
The two rows this page is accountable for, rendered from our compliance status file, last reviewed 2026-08-15. Where a row says to be confirmed, that is the answer today.
| Item | Status | What we can say today |
|---|---|---|
| Data residency | to be confirmed | Apps and data run on managed cloud infrastructure we operate, built primarily on AWS. A specific region commitment is to be confirmed and is not promised until it is. |
| Encryption at rest (object data) | to be confirmed | Encryption at rest for object tables and file storage is to be confirmed and is not claimed until it is; we make no encryption-at-rest claim for per-environment configuration bundles either. |
Encryption in transit, backups, retention windows, and deletion after termination are stated with a review date on the compliance status page — including the rows we have not confirmed.
Data you load into your objects is yours. Every object is a real table you can query and export through a documented API, and a data-processing agreement is available on request during procurement.
What isolation is, and is not
- Is: a tenant column on every object table, filtered on every read, required on every write, enforced by the platform.
- Is: control-plane tables with no direct client access, and file storage that only serves signed requests.
- Is not: dedicated infrastructure per customer — no separate databases, clusters, or distributions per client.
- Is not: a schema per app. Solutions in one account share a schema; object names carry a short solution prefix by convention.
- Is not: a region guarantee, or an encryption-at-rest attestation, until the compliance page says so.
- Is not: self-hostable. Data lives on managed cloud infrastructure we operate, built primarily on AWS.