Data handling and opt-in

HD runs entirely inside your environment. Your records, schemas, queries and user identities stay there. The only data that can leave is operational telemetry and crash information, and only when an administrator opts in. This page sets out what that data is, how you control it, where it goes and who can see it.

The short version

• Off by default. A new deployment shares nothing with FermiHDI.
• One decision, held centrally. The opt-in is a single switch in the DMS WebUX, held by DMS-Core for the whole deployment. It is not a per-browser or per-node setting.
• Enforced at two points. Only two components can send anything to FermiHDI. The deployment's OpenTelemetry collector forwards operational telemetry, and the crash vault forwards crash stacks, both only while the switch is on. A full crash report goes only when an operator shares it.
• Crash memory never leaves on its own. A crash report's memory contents are sent only when an operator shares that one report.
• One destination. Shared data goes to FermiHDI's own service in DigitalOcean's Singapore region (SGP1). No other company or software-as-a-service provider receives it.
• A closed network. That service runs in a private network with no public access. It accepts only mutual TLS connections from registered, opted-in HD deployments, and FermiHDI staff reach it only through recorded Tailscale or Border0 sessions.

Three kinds of data

Permitted telemetry fields

Operational telemetry leaves with these attributes and no others. Everything else is removed by your collector before sending, and discarded again at FermiHDI's intake:

service.name, service.version, service.namespace, deployment.environment, fermihdi.build.commit, fermihdi.product, fermihdi.license_id, fermihdi.region, host.arch, os.type, fermihdi.opt_in, http.request.method, http.response.status_code, http.method, http.status_code, http.route, rpc.method, rpc.service, error.type, fermihdi.feature, fermihdi.node_role, log.level, event.category, event.action, gen_ai.operation.name, gen_ai.tool.name.

How opt-in works

1. Installation. The installer can disable sharing outright (fermihdi_dms_enable_analysis: false). A deployment installed that way cannot be switched on from the console.
2. The switch. An administrator turns on Cloud sharing on the WebUX Telemetry & Logs page. DMS-Core records the decision and it survives restarts.
3. Registration. DMS-Core registers the deployment with FermiHDI's opt-in service over mutual TLS, using a certificate chained to FermiHDI's root. The registration carries the licence ID, the region, a certificate request for the collector's identity, and the crash vault's relay identity and public key. None of these is a credential or customer data.
4. The collector. DMS-Core renders the collector's configuration. The FermiHDI export pipeline exists in that configuration only while sharing is on and the registration is valid. It removes every attribute not on the permitted list, then sends over mutual TLS.
5. Turning it off. Turning the switch off revokes the registration and removes the export pipeline. The collector stops forwarding immediately.

No engine node or service is told about the decision, and none of them changes what it reports. They always report to your own collector and crash vault, and those two decide what, if anything, goes further. For network controls, the collector reaches FermiHDI's telemetry endpoint and the crash vault its crash endpoint, both in the Singapore region.

Filters and destinations you control

• The opt-in switch decides whether the FermiHDI pipeline exists at all.
• The permitted-field filter in your collector is fixed. Nothing outside the list above can be added to what FermiHDI receives.
• Your own destinations. The WebUX OTEL Collector page sends the deployment's full telemetry to systems you choose (OTLP over HTTP or gRPC, syslog, Prometheus remote write, Kafka), independently of the opt-in. That data goes only where you point it.
• The console's own usage telemetry follows the same switch, or the FERMIHDI_OPT_IN environment variable on the WebUX container, which turns it on regardless of the switch. When on, the WebUX reports page loads and request timings to your own collector, with URLs reduced to their paths, and no addresses, user agents or identity headers. That variable does not make the collector forward anything to FermiHDI; only the switch does.

The crash vault

Every crash in the deployment is captured on your own infrastructure first. The engine roles report through Crashpad, DMS-Core and the Proxy through the Go runtime, and the WebUX through Node.js. Reports go to the crash vault, a service on the DMS host.

• Held locally. The vault keeps each report, symbolicated on the box against the symbol files shipped with the release, for 30 days or until the vault reaches 2 GB, whichever comes first.
• Stack only with the opt-in. With sharing on, the vault sends the stack of a new crash: symbolicated frames, release and tags, with no memory and no attachments. With sharing off, it sends nothing.
• Full reports per incident. Memory contents go only when an operator shares a specific report, optionally tagged with a support ticket, after a confirmation.
• Air-gapped support. Export to file writes a report to a tar file for support conversations on air-gapped deployments.
• Audited. Every share and export is recorded in the deployment's audit log with who did it and when.
• Access controlled. The vault's management interface serves only the WebUX, with a shared access token. Without the token configured it refuses every request.

Where shared data goes

Shared telemetry and crash data go to FermiHDI's opt-in service in DigitalOcean's Singapore region (SGP1), on infrastructure FermiHDI controls. DigitalOcean's data centres and platform, including SGP1, are covered by DigitalOcean's SOC 2 Type II report and ISO/IEC 27001 certification. DigitalOcean provides the infrastructure only and has no product-level access to the data.

Access to the opt-in service

The opt-in service runs in a private network (a DigitalOcean VPC) with no public access. The only connections it accepts from outside are these:

• Opted-in HD deployments, over mutual TLS. Registration uses a certificate chained to FermiHDI's root, as described in How opt-in works. Telemetry and crash data are accepted only from deployments that have opted in and registered, using the identity issued at registration. Any other connection is refused.
• FermiHDI staff. Staff reach the service only through Tailscale or Border0, and those sessions are recorded.

FermiHDI sends none of this data to any other external system: no third-party analytics, advertising, error-tracking or other software-as-a-service provider receives it.

If you never opt in

Nothing described above leaves your network. HD operates fully without the opt-in, and every capability, including crash capture, symbolication and export, works locally.