dbtrail Documentation

What dbtrail's official binaries report, what they never report, and how to turn it off in the CLI, an environment variable, or the web console.

Official dbtrail release binaries send metadata-only usage statistics (which command ran, whether it succeeded, a coarse error class, and the version and platform) so we can prioritize the roadmap and catch reliability regressions. It is on by default in official builds and takes one step to turn off.

Turn it off any time

Any one of these works, and the first that applies wins:

bintrail telemetry off      # this machine, permanently
DO_NOT_TRACK=1              # every tool that honours the convention
BINTRAIL_TELEMETRY=off      # this environment (e.g. a systemd unit)
bintrail --telemetry=off …  # a single command

Running the web console (bintrail-console watch)? Open Storage → Usage telemetry and click the toggle; it stops the running daemon immediately.

See exactly what would be sent

Telemetry is metadata you can inspect before trusting any of this text:

bintrail telemetry show     # prints a sample event, byte for byte; sends nothing
bintrail telemetry status   # shows whether it's on, and what decided that

What is collected

The wire payload is a closed, fixed list of fields. Nothing outside it is ever transmitted:

Field	Example	Why
Command	`query`, `recover`, `stream`	Which features are used (roadmap input)
Outcome + error class	`ok`, or `error` + `db_connection`	Surface reliability regressions
Duration bucket	`1s-10s`	Coarse; never a precise runtime
Version	`0.42` (major.minor only)	Version adoption
OS / architecture	`linux` / `arm64`	Platform priorities
Is CI / is interactive	`false` / `true`	Separate automation from people

Values are deliberately coarse (the version is truncated to major.minor and rare architectures collapse to a bucket) so no single field can identify an install.

The web console

If you run the web console (bintrail-console watch), a deliberate action (running a recovery, a time-travel reconstruction, a verify, or a baseline) records one usage event of the same shape, so we can see which console features get used. Passive browsing (listing events, paging, status refreshes) records nothing. The event names only which action you took (a fixed label like console-recover); it never carries what you were looking at: no schema, table, primary key, or row value. And unlike a CLI command, it is recorded without any identifier at all, so console usage can never be stitched into a per-install timeline. There is no JavaScript in the browser doing this and no third-party request; the console records the event on the server it already talks to. The read-only bintrail-console serve reports nothing.

What is never collected

Never on the wire

Your data, schema/table/column names, DSNs or connection strings, hostnames, IP addresses, file paths, query text, GTIDs, binlog names or positions, flag values, command arguments, verbatim error messages, row counts, and no persistent identifier of any kind. There is no account link, no device ID, no DAU/WAU/retention (structurally impossible without a stable ID, and there isn't one).

How your privacy is protected

No identifier. Nothing that survives the process or identifies the install is created or sent. Usage cannot be tied to you or your account.
The IP dies at the edge. The ingestion endpoint strips the source IP before anything is stored; it is never joined to a payload, never logged.
No third parties. Events go only to dbtrail's own metadata-only ingestion host, separate from the authenticated API. No analytics SaaS is in the path.
Never on the request path. Commands never touch the network to report; events are written to a local file and delivered by a later run, best-effort.
Not a sales channel. The data is architecturally incapable of identifying a lead; we use it to prioritize engineering, nothing else.

Builds that never report

A plain go build from source and the entire test suite send nothing: the endpoint is compiled in only for official releases (bintrail telemetry status shows not compiled in otherwise).
The demo image, and the MCP server, never report.
CI environments are auto-detected and suppressed, and a machine with no home directory reports nothing.

Verify the claims yourself

dbtrail is open source. The payload is a closed allowlist and the telemetry code is structurally isolated from the code that could read your data, both enforced by tests in the repository. The full, verifiable specification lives in TELEMETRY.md.

Telemetry