The console
Accounts are created and managed in the administration console; there is nothing to install on the user's side. An account is one person's access to all four areas — a primary address on the organisation's domain, its aliases, and its membership in groups, which is what turns a group into a shared mailbox, a distribution list, a shared calendar or a shared drive.
Groups, mail forwarding per account (a forward the administrator sets asks for their passkey and delivers only clean mail, with no copy kept here), a footer on outgoing mail per mail domain, and the sharing policy — whether accounts may share at all, and whether guests may exist — are the administrator's levers. A guest account exists only in relation to what was shared with it: it sees the shared folder, calendar or address book and cannot re-share it.
Credentials belong to their owners and are stored in the platform's keychain — the administrator does not read them. The one exception is an app password created for an account in the console, meant for an account that will never hold a passkey (such as an agent's); creating it asks for your passkey, and the account's own log records it.
Where the settings live
Settings live in a small number of places, each with a different trust level and a different writer:
The node configuration (svc.json) | written by the setup wizard — storage coordinates, the instance's identity, the service settings |
| The platform keychain | credentials the services use, referenced by name — services never see a plaintext password in their configuration |
| Role-minted files on the box | the document server's JWT secret, the DNS-01 hook's coordinates — minted on the box, root-only |
| The environment the operator supplies | the deployment's secrets, in encrypted files |
The node configuration answers four questions: where bulk content goes (the object storage coordinates and the bucket), what folder this instance owns inside that bucket, what the instance is called (the hostname the web applications, mail and DAV serve on — because passkeys and OpenID clients bind to the origin, a name chosen for life), and how recovery is derived (the recovery passphrase is not stored — it derives the key that protects the backups; losing it means losing the ability to restore, so write it down offline).
Changing settings
Settings that describe identity or storage are load-bearing: changing the hostname after accounts exist breaks passkeys and clients; changing the bucket or namespace after content exists orphans it. Changes of that kind are migrations, not edits — plan them and back up first. Settings that describe policy — how much mail is kept, which folders are default, who may share — are safe to change at any time and take effect on the next service cycle.
The three recurrings
| Backup | daily | the instance's state to object storage, pruned to a retention window; file blobs live in object storage already — the backup covers what object storage cannot restore |
| Digest | daily | what the background machinery did, in one mail — silence means it ran |
| Reclamation | hourly | disk reclamation: logs, spools and caches pruned on policy |
A day without the digest mail is a day the machinery did not run — the digest's absence is itself an alert. A backup that has never been restored is a hope, not a backup: the restore path is exercised the same way the backup runs.
What to watch
The things worth watching are the things that fail quietly: the digest arriving (the canary for the background machinery), disk headroom (the trend matters more than the level), the certificate's renewal (a failed renewal is visible long before an expiry), and the mail queue — outbound mail piling up is the first sign of a delivery problem.
Next chapter
Moving in from another provider: