Should self-hosted telemetry be opt-in and config-file auditable?

I run several self-hosted services, and I increasingly think telemetry should be disabled by default and controlled through an explicit, auditable configuration file—not a vague toggle buried in a web dashboard. Self-hosting should mean the operator can inspect, limit, and revoke every outbound connection.

Take Nextcloud’s update checker: it is enabled by default and sends version, PHP version, installation timing, and release-channel information to an updater server. That may be reasonable diagnostics, but it is still an automatic data flow. Local logs and metrics feel fundamentally different from remote reporting.

What counts as “essential” diagnostics? Should crash reports require consent separately for every instance? Maintainers genuinely need compatibility and failure data, but projects could also use sponsorships, enterprise support, contracts, or paid services rather than quietly exporting usage data. Am I being too strict? Share tools, counterexamples, or a better default.

The important distinction is not telemetry versus no telemetry; it is declared egress versus mystery egress. I want destination, payload, trigger, retention, and a hard off switch documented in the config. Crash dumps deserve separate consent because they can contain application data, even when the project did not intend that.

Opt-in is attractive, but defaults also shape support costs. If nobody enables diagnostics, maintainers may end up guessing which environments are failing. I would accept an opt-out default for low-sensitivity version checks, provided the first-run notice is clear and the config is authoritative rather than merely mirroring a dashboard toggle.

I would avoid calling every update check telemetry. The relevant policy question is whether an outbound flow is documented, necessary, and controlled. The Nextcloud example supports the configurability point; it does not establish that the data is harmful or that an industry-wide opt-in rule already exists.

Per-instance consent makes sense for crash reporting because instances have different users, jurisdictions, and threat models. A global project preference cannot know whether this particular operator permits remote error data. Local retention plus an operator-triggered upload is a much cleaner boundary.

As a maintainer, I would rather receive ten useful reports than a thousand silent installations. A small, inspectable config block could include disabled, local-only, and remote-with-consent modes. The implementation cost is real, but so is the cost of making admins reverse-engineer network traffic.

Funding is the incentive underneath this argument. If telemetry becomes the easiest source of product intelligence, someone will eventually call it essential. Sponsorships and paid support are not magic, but they at least make the exchange legible: money for maintenance, not invisible data for continued use.

A dashboard checkbox is not an audit trail. Put the setting in version-controlled configuration, log changes, and make outbound requests fail closed when remote reporting is disabled. Also document exactly what “crash report” serializes. “Anonymous” is not a payload specification.

I disagree with disabling everything by default. A service that checks its release channel or reports a fatal compatibility failure can be safer to operate when the operator has an obvious choice at install time. The better default may be minimal, aggregate, documented diagnostics—not zero data under every circumstance.

The strongest principle here is reversibility. Enable local diagnostics freely, require explicit configuration for remote destinations, and make revocation immediate and testable. If an admin cannot answer “where did this process connect, and why?” from the documentation and logs, the self-hosting story is incomplete.