Storage and retention
Applies to: SimpleTwo 0.9.x · Checked: 20.09.2026
1. Where the bytes are
| What | By default | What replaces it |
|---|---|---|
| Message attachments | the messaging host's disk | the s3 role, or external S3-compatible storage |
| Avatars | the same place | — |
| Meeting recordings | object storage | its own bucket and prefix: Settings → Recording |
| Mail: message bodies and attachments | object storage, the simpletwo-mail bucket; without storage the mail role does not start | the bucket name is set with the external store |
| Files (drive) | object storage, the simpletwo-drive bucket; an object's key is the file's path | with an external store the bucket name does not change (files) |
| Messaging and calendar databases | the postgres role | an external Postgres cluster |
| The bus | the redis role | external Redis |
| Control-plane database, certificates, client builds | the coordinator's data volume | — |
The messaging host's disk is fine to start with and stops being fine in three cases: the
attachments no longer fit on one disk, you need several replicas of the messaging service (a
file written by one is invisible to the others), or you need meeting recordings.
External Postgres and Redis are connected in Settings → External stores, as ready connection strings. Not as one administrative account we would create databases with: creating a database and a role needs privileges the owner of somebody else's cluster will not hand out, and we do not want to half-create things on a cluster that is not ours.
The Redis bus's status, tuning, password rotation and TLS for an external Redis are on Coordination bus (Redis).
redis and s3 hosts are closed by a firewall, not by trustNeither has authentication strong enough to stand open even on a private network. Installing the
s3 role on a host without a firewall is refused.
2. Encryption at rest
It is enabled by the tenant, in three steps whose order is not accidental:
- The master key is created in the console and written to a file outside the data directory.
- A recovery sheet is printed before anything has been sealed with the key.
- Two groups from that sheet are typed back — only then does encryption switch on.
That closes the one state the system must never be in: a key that seals rows with no copy anybody can read.
| Encrypted | Not encrypted |
|---|---|
| message bodies | attachment names |
| meeting transcripts | metadata: who, when, in which conversation |
Search keeps working: it runs on tokens derived with a separate key rather than on the text. The index key and the cipher key are deliberately different — an index leaks by design (equal words produce equal tokens), and that leak must not also be a leak of the cipher.
Three properties people ask about:
- Existing rows stay as they are. Enabling encryption does not rewrite the database; the store lives mixed, and the read path understands both forms.
- Secret chats are unrelated. They are encrypted by the client and the server never read them.
- The key lives outside the data directory — otherwise a backup of the data carries the key to it. See upgrade and backup.
3. Retention
| Policy | Default | Where |
|---|---|---|
| Message retention | unlimited | MSG_RETENTION_DAYS |
| Conversation log revisions | 10 000 | MSG_CONVLOG_KEEP |
| Meeting recordings | not deleted automatically | your storage's lifecycle policy |
Bounding the revision log and deleting messages are different decisions. The first saves space, the second satisfies a retention requirement. An organisation that needs messages deleted says so explicitly: by default nothing is.
4. Avatars
Photos come from the directory (synchronised from AD) or are uploaded by people themselves — that is an organisation policy: Settings → avatar policy. A mixed mode is the usual case: the directory supplies a default and the person may replace it if that is allowed.
5. How much space
≈ 0.8 GB per person per year by the load profile (8 files per working day, 400 KB on average). Meeting recordings are on top of that and follow their own rules — the table by organisation size is in Sizing.
6. What is stored on devices
The client keeps its own copy: the message database, the search index and a media cache. Two levers, and both are yours:
- Offline depth — how many conversations, and how many messages in each, the client pre-loads. Set by the organisation (console → sync depth) and delivered with the rest of the client policy. Three states: a number, an explicit zero (pre-load nothing) and silence, in which case the client uses its own default. Zero and silence differ on purpose: an administrator who never opened that screen must not look like one who switched pre-loading off.
- The cache ceiling on the device is set by the person; they also see what is used and can clear media without touching the messages.
A support desk with three hundred rooms a day and a team of six want different depths, which is why this is an organisation setting rather than a product constant.