Privacy notice for Rynhult usage statistics and bug reports
This collector, telemetry.rynhult.dev, receives optional usage statistics and bug reports from
Rynhult installations. Every installation sends nothing unless its owner turns sending on.
Who is responsible
The controller is Joshua Fulton, the Rynhult project maintainer. For any privacy request, write to privacy@rynhult.dev.
Only if an installation's owner opts in
- Both kinds of data are off by default, and are two separate choices. Only an owner of an installation can turn them on, in Settings → Usage and bug reports. Members of an installation can't.
- Consent is to a schema version. If a later version would send something new, sending switches off and the owner is asked again.
- Turning a choice off stops sending at once and discards anything waiting to be sent.
- An installation can send somewhere else, or nowhere: its operator can point it at their own collector or remove the feature entirely.
Legal basis: consent
Data is received and kept only because an installation's owner consented by turning sending on. Consent can be withdrawn at any time by turning the choice off. Sending stops at once and anything waiting is discarded. Data already sent is deleted too when the owner leaves Also ask the collector to delete what this installation sent ticked; otherwise it is kept for the periods below, and can still be deleted later (see Your rights). Withdrawing doesn't affect what was done with the data before.
Usage statistics
At most one small summary a day. Every value in it is a fixed choice, a yes/no, a range or a date; there is no free text. It contains:
| Item | What is sent |
|---|---|
| Schema | usage/1 |
| Installation key id | A pseudonymous id of the installation's current usage key (see below) |
| Day | The UTC date the summary covers; no time of day |
| Rynhult version | A published release number, or dev; never a build identifier |
| Operating systems | Which of linux, wsl, macos, windows, other are in use |
| Kind of installation | release, git-checkout, windows-installer or mac-installer |
| Sizes | Machines, people, projects, running sessions and stored keys, each only as a range: 0, 1, 2-3, 4-10, 11-50, 51+ |
| Agents enabled | Which of claude, codex, copilot, cursor, antigravity, opencode |
| Features enabled | Which of a fixed list: groups, organizations, containers, backups, backup_server, publishing, dns_provider, auto_updates, push, issue_sources, remote_access, schedules, orchestrator, preview, custom_guardrails |
| Features used that day | For a fixed list of 21 actions (such as session.launch, changes.view, pr.merge, backup.run), how often, only as a range: 1, 2-5, 6-20, 21-100, 101+ |
| Sessions by agent | Sessions started that day per agent, as the same ranges |
Bug reports
- Only about failures of Rynhult's own code and helpers, never about what an agent did.
- An owner sees each report and approves it before it is sent. Unapproved reports are discarded after seven days. At most ten reports a day are sent.
- A report holds structured error details (Rynhult's version, operating system family, which part failed, the type of error), the names and line numbers of Rynhult's own code involved, and the error message after scrubbing.
- Scrubbing removes the installation's known secrets and its known names (people, projects, repositories, machines, hosts), and anything shaped like a token, email address, network address, host name or file path. It runs before and after shortening. Scrubbing is best effort: a name or secret the installation doesn't know about, in an unusual form, could be missed. This collector scrubs again on arrival.
- A report about a crashed session contains details about the process only, never its contents.
Never collected
Prompts, transcripts, terminal output, model outputs, file names or contents, code, paths, repository or project names, branch names, host and machine names, IP addresses in the data, usernames, email addresses, display names, keys or their names, server and catalog names, guardrail patterns, model or endpoint names, time zone, locale, exact counts and exact times.
Installation keys
- Each installation signs what it sends with keys it creates itself. Usage and bug reports use separate keys, and each is replaced every 90 days by a new, unrelated one. Nothing links an old key to a new one or a usage key to a report key.
- A key shows that data comes from the same installation as before. It identifies no person, and it doesn't prove the data comes from a genuine installation.
- The installation keeps its old keys only to be able to ask for deletion, for at most 13 months.
Connections
This collector keeps no access logs. The address a connection comes from is used only to limit how often it may send, held in memory until the current hour or day ends, and is never stored with the data. No location lookup is done.
How long data is kept
| Data | Kept |
|---|---|
| Daily usage summaries | 90 days after receipt |
| Monthly totals (counts of installations per operating system, agent and feature, without any key id) | 13 calendar months |
| Bug reports | 180 days |
| Record of deletions (key and report ids only, so a restored backup can't bring data back) | 45 days |
| Encrypted backups | At most 30 days |
No statistics are published now. Any figure published later will count at least ten installations.
Your rights
Data here is linked only to installation keys, so a request names the installation's usage and report key ids, including retired ones. A host name or email address can't identify your data, so it can't be used instead. A report id alone needs a manual check that it is yours.
- Access. Email privacy@rynhult.dev with your key ids to get a copy of what is held for them.
- Deletion. In Rynhult, use Delete data already sent in Settings → Usage and bug reports, or leave Also ask the collector to delete what this installation sent ticked when turning a choice off. Rynhult signs the request with every key it kept, current and retired, and shows the receipt. Or email privacy@rynhult.dev with your key ids. Deletion is completed within 30 days, backups included. Monthly totals carry no key id, so they can't be traced back to an installation or removed for one.
- Objection. Turn the choice off in Rynhult, which stops sending at once, or email privacy@rynhult.dev with your key ids.
- Complaint. You can lodge a complaint with a data protection supervisory authority, for example the one where you live or work.
Hosting
The collector runs on a dedicated virtual machine at Akamai (Linode) in Frankfurt, Germany. Data and its backups are stored in the EU and aren't transferred outside it for storage. Akamai processes the data only as the hosting provider, under a data-processing agreement. No third-party analytics or error service receives this data.
More detail
The full design, including the exact schemas, is in Rynhult's source repository.