Telemetry: what we send

Every Bindery install sends one anonymous ping per day to api.getbindery.dev/api/ping. The full schema is below. Nothing else leaves your install via telemetry: no library contents, no book titles, no author names, no IPs, no hostnames, no usernames.

This page is the source of truth. If a future release adds a field, it appears here first.

Core fields (always sent)

install_id

Random UUID generated on first run and stored in your Bindery database. Lets us count distinct installs without tracking who you are. Resetting Bindery's DB resets the UUID; we have no other way to link two installs together.

version

The Bindery binary's release tag (e.g. 1.15.2). Lets us see which versions are actually deployed so we know when an old release can be deprecated. Non-release builds (dev / sha-XXXXX / commits past a tag) are dropped client-side and never sent.

os / arch

Output of Go's runtime.GOOS and runtime.GOARCH (e.g. linux / amd64). Lets us prioritise fixes for the OS/arch combos that are actually in use.

deploy

How Bindery is being run: kubernetes (inside a pod), docker (inside any other container), binary (bare metal), helm (Helm chart, when the chart sets BINDERY_DEPLOY_METHOD=helm). Detected from KUBERNETES_SERVICE_HOST and the presence of /.dockerenv. Helps us know which deployment paths are worth supporting.

Features (sent starting v1.15.3+, optional)

Counts and booleans summarising which subsystems are configured. No names, IDs, URLs, or values are ever sent — just numbers and on/off flags. Tells the maintainer which features users actually use so support time goes to the parts of Bindery people rely on.

features.indexers / features.download_clients / features.notifications / features.users

Integer count of enabled configuration rows. The user count tells us whether multi-user is in real use; the others tell us how many integrations a typical install has.

features.calibre_enabled / features.abs_enabled / features.grimmory_enabled

Boolean: whether the Calibre, Audiobookshelf, or Grimmory integration is turned on. No URLs, paths, or credentials.

features.hardcover_token

Boolean: whether a Hardcover API token is configured (presence, not the value).

features.oidc_enabled / features.multi_user

Booleans: whether OIDC sign-in is configured, and whether there is more than one user account in the local DB.

What we don't collect

Your IP address (the server rate-limits by IP but never stores it).
Your hostname, server name, domain, or any DNS-resolvable identifier.
Anything about your library: book titles, author names, ISBNs, ratings, file paths.
Anything about your network: indexer URLs, download client URLs, notification webhook URLs.
Anything about your users: usernames, email addresses, OIDC subject IDs.
API keys, tokens, passwords, session secrets.
Request logs, error traces, or stack traces.

How to opt out

Two ways to disable telemetry entirely. Either is sufficient; the env var wins if both are set.

Env var (recommended for fresh installs):
BINDERY_TELEMETRY_DISABLED=true

Settings DB (for running installs):
Set the telemetry.enabled setting to false. Survives restarts; takes effect on the next scheduled ping (within 24 hours).

How the data is stored

Pings land in a small SQLite database on a single VM in Hetzner Cloud (Falkenstein, Germany). Per-install rows whose last_seen is older than 60 days are deleted nightly. The dashboard's long-running charts (monthly new installs, version adoption over time) are computed from daily aggregate tables that hold only counts per day: how many new installs, how many were active, how many were on each version, how many had each subsystem enabled. The aggregate rows never contain individual install IDs, so they're kept indefinitely. The database itself is backed up daily to an off-site object store; backups follow the same 60-day retention on per-install rows.

The aggregated dashboard at /stats is rendered live from the database with no caching. The full source of both the bindery client and the telemetry server lives at github.com/vavallee/bindery — the client at internal/telemetry/client.go, the server at cmd/telemetry-server/main.go.