Last updated: 2026-08-14.
This covers the telemetry ping Bindery sends to api.getbindery.dev. It is the only data Bindery sends anywhere that you did not configure yourself.
Everything else Bindery talks to — indexers, download clients, metadata providers, notification targets — you configure, and the data goes to services you chose. Bindery ships with none of them and adds no intermediary.
Bindery is maintained by a single individual (GitHub: @vavallee), who operates api.getbindery.dev and is the data controller for the telemetry described here. Contact: open an issue at github.com/vavallee/bindery/issues, or for anything you would rather not post publicly, the process in SECURITY.md.
Once per day, and once more each time it starts, a release build sends:
| Field | Content |
|---|---|
install_id |
A random UUID generated on first run. Not derived from anything about you, your machine, or your library. |
version, os, arch, deploy |
Binary version, operating system, CPU architecture, and deploy method (kubernetes / docker / binary). |
features |
Counts and booleans for which subsystems are configured — number of indexers, download clients, notifications, users; whether Calibre, Audiobookshelf, Grimmory, OIDC, multi-user, or a Hardcover token are in use. Never names, URLs, credentials, or values. |
features (setup timing) |
Five whole-day counts: how many days after install the first indexer, first download client, first author, first grab and first import happened. Integers only, never timestamps, and a field is absent when the milestone has not happened. |
errors |
The number of ERROR/WARN log entries in the last 24 hours, plus the five most frequent error messages. These are the fixed, developer-written message strings only, truncated to 120 characters. Log attributes — titles, paths, URLs, usernames — are stripped and never sent. |
Not sent: hostnames, IP addresses in the payload, library contents, author or book names, file paths, indexer or download client names or URLs, credentials, or anything identifying you or your machine.
The response contains the latest published version, which powers the in-app update badge.
Receiving an HTTP request necessarily reveals the sender's IP address, and under GDPR Article 4 an IP address is personal data. Bindery's telemetry server:
- uses the IP only to enforce a per-IP rate limit on the ping endpoint;
- never stores it — no database table has an IP column;
- never logs it.
It exists in memory for the duration of the request and in the rate limiter's short-lived state. It is not associated with the install_id or with anything else.
The processing relies on legitimate interest (Article 6(1)(f)): counting active installations, understanding which platforms and versions are in use, and spotting widespread breakage in a project maintained by one person. The data is pseudonymous by construction — a random UUID with no path back to an individual — and the balancing test favours processing because the impact on any individual is negligible and the alternative is maintaining the project blind.
If you would rather not participate, opting out is unconditional and takes one setting (below).
| Data | Retention |
|---|---|
Install rows (install_id, version, os, arch, deploy, last seen) |
60 days after the last ping, then deleted |
| Daily activity ledger | 400 days |
| Daily aggregates (totals per day, per version, per feature) | Kept indefinitely — these contain no per-install rows, only counts |
| IP addresses | Not retained |
An install that stops pinging disappears from the install table within 60 days. What remains is counts.
Either of these disables the entire ping:
- Settings → Logs → turn off telemetry (
telemetry.enabled: false), or - set
BINDERY_TELEMETRY_DISABLED=truein the environment — this works before first run, so nothing is ever sent.
Both switches disable everything, including the error counters and the update badge. A disabled ping means the app has no way to learn that a newer version exists.
Non-release builds do not send telemetry. Only a version that looks like a release tag pings, unless you deliberately set BINDERY_TELEMETRY_FORCE to test the ping path yourself.
Under GDPR you may request access to, correction of, or erasure of personal data about you, and may object to processing based on legitimate interest.
Practically: the data is pseudonymous, and the maintainer has no way to connect an install_id to a person. If you want your install's row removed, opt out and it is deleted within 60 days automatically. There is no way to read your install ID from the app today, so a targeted deletion request is not something the maintainer can act on.
Telemetry is not shared with anyone, sold, or used for advertising. There are no analytics SDKs, no trackers, and no third-party services in the telemetry path. The aggregate dashboard at /stats is public and contains only counts.
Every claim here is checkable in the source:
- client —
internal/telemetry/client.go - server —
cmd/telemetry-server/main.go
The retention windows are the retentionWindow and ledgerRetentionWindow constants; the IP handling is realIP and limiter.allow in the ping handler.
If a future release changes any of this, the change lands here before it ships.