Data and tenancy
This page exists to be read before a security review, not during one. It says plainly where your data lives and how it is kept separate from other customers'.
Two models
| Standard (Launch, Team, Division) | Dedicated (Enterprise) | |
|---|---|---|
| Compute | Its own VPC and container cluster | Its own AWS account |
| Database | Its own instance, in your VPC | Its own instance, in your own AWS account |
| Region | Chosen at signup | Any region |
| Credentials | Encrypted with your instance's key | Encrypted with your instance's key |
What isolation actually means
Every instance is provisioned into its own virtual private cloud, with its own database instance, its own container cluster and its own load balancer. Nothing in the data path is shared between customers. Terraform state is held separately per tenant, so one customer's infrastructure cannot be altered by a change to another's.
Inside that database, row-level security is enforced by the database itself rather than by application code. Every row carries an owner and the database refuses to return rows belonging to anyone else, regardless of what a query asks for. This is a second layer beneath the infrastructure boundary, not a substitute for it — a defence-in-depth measure that also protects against a bug in our own code.
A query arriving without tenant scope raises an error rather than returning an empty result. The distinction matters: silent emptiness looks like "no data" and reaches production, while an error gets fixed before it ships.
Standard tiers are isolated at the VPC and database level within infrastructure we operate. Enterprise places your instance in a separate AWS account, which changes the blast radius of an error on our side and lets you choose any region. If account-level separation is a procurement requirement, that is the tier to ask about.
Dedicated
On Enterprise your instance runs in an AWS account created for your organisation, with its own database. No infrastructure is shared with any other customer, and you choose the region.
Credentials
Integration credentials are encrypted at rest with AES-256-GCM using a key generated for your instance during provisioning. The key is held by the instance and is not stored in the database, so reading the database alone does not yield usable credentials.
Export and deletion
- Export — available at any time from the console.
- Deletion — on request. We record that it happened and when.
- Suspension — does not delete anything. Your data is retained and comes back when the account is reinstated.
Who at Thalamus can see your data
Nobody, by default. Support access requires a grant that records who, why and for how long; it expires automatically within 24 hours, and every use is logged. You can review the whole history and revoke a grant at any time. See team and roles.