Privacy
Last updated: 31 August 2026.
This page describes what Xerum holds, where it holds it, and what we do and do not do with it. It is written plainly on purpose.
What we hold
Your shared context. The resources your connectors record, their content, their origins, and the full history of changes over them. This is the product — a context you could not read at an older revision would not be worth having.
Account information. The organisation, its members, their roles, and the identity records needed to sign them in.
Operational logs. Enough to run the service and investigate faults. Logs are written under rules that keep personal data and content out of them; that is enforced in the build, not left to the discipline of whoever wrote the log line.
Where it lives
In your own instance: your own container, your own database file, your own storage prefix. Not in a shared table with a customer column.
The database is replicated continuously to your instance’s own storage prefix so it survives an ephemeral disk. Derived indexes — search and embeddings — are not replicated; they are rebuilt from your record.
What we never do
- We do not sell your data, and we do not broker or share it.
- We do not train models on your content. Any provider that processes content on our behalf is contractually barred from training on it.
- We do not read your context except where you ask us to help with a specific problem and we agree the access first.
- We do not run ad-tech or third-party trackers on this site or in the application.
Content stays where it was written
Xerum records resources from your sources, and each one keeps its origin. We are not the system of record for the source itself — the issue still lives in GitHub, and if you delete it there, that deletion is real there. What your Xerum instance holds is the record of what was recorded and when, which is the whole point of an append-only history and is also the thing to understand before you connect a source.
Deletion
You can delete your instance, and with it the database, its replicated copy and its indexes. We do not retain a copy afterwards beyond the short window in which backups age out, and we will tell you what that window is rather than leaving it unstated.
Deleting an individual resource from an append-only history is a different question with a real answer, and the answer depends on why: a correction is a new revision, but a genuine erasure obligation needs a redaction path. If you have that obligation, raise it before you connect a source and we will tell you honestly what we support today.
Your rights
If you are in the UK or EEA you have rights of access, rectification, erasure, restriction, portability and objection under the UK GDPR and EU GDPR. Exercising any of them starts with a message to us, and we will not make you go through a process to do it.
Where you are our customer, you are the controller of the content in your instance and we are the processor. A data processing agreement is part of the conversation before an instance is provisioned.
Cookies
This marketing site sets no cookies and runs no analytics. The application sets what it needs to keep you signed in and nothing else.
The unfilled slot, stated rather than hidden. The operating entity behind Xerum is not yet incorporated under a name we can print here, so this page does not name a data controller or give a registered address, and it has not been through legal review. Both are required before this is a policy rather than a description, and both will land before general availability. If you need either today in order to evaluate Xerum, ask — we would rather have that conversation than have you assume.