Multi-Tenancy & Filtering
Isolation is enforced in the database, not just the application.
The hierarchy#
- Tenant — your account, addressed by API keys (
mv_…, stored only as SHA-256 hashes). - Collections — coarse namespaces within a tenant.
- Container tags — fine-grained scoping inside a collection (your end-users).
Row-level security#
Every tenant-scoped table carries Postgres RLS policies in FORCE
mode: the application sets the tenant id per transaction, and the database refuses rows
that don't match — fail-closed, even against application bugs. The app's database role
is deliberately non-privileged, so the policies can't be bypassed.
Key types#
| Key | Can | Use for |
|---|---|---|
| Main | read + write | your backend |
| Read-only | search/get only — writes get 403 | dashboards, untrusted surfaces |
Keys can carry an optional expiry; rotation invalidates the old key immediately.
Data residency (BYO)#
For privacy-sensitive deployments, point RememberOS at your own infrastructure — credentials are encrypted at rest and validated with a live self-test before saving:
- BYO object storage — your S3-compatible bucket holds the file bytes.
- BYO database — your Postgres holds the memories.
- BYO extraction — your OpenAI/Azure key or a self-hosted model runs graph extraction, so conversation text never touches the platform's LLM key.