Telemetry & Data Collection
What Swarmfile measures, what leaves your machines, and what it deliberately does not collect. This page is for security reviews and procurement questionnaires; the network-level view of every connection is in Network Requirements.
Short version#
- No third-party analytics or crash-reporting SDKs ship in the desktop app or engine. There is no telemetry sent to an analytics service, ad network, or crash collector from the client. The website is separate: Google Analytics is scoped to the public marketing/docs pages and is not loaded on public project pages, Explore, the signed-in dashboard, or any app route - so no project slug, file path, or dashboard URL is reported to it. (Navigating from a marketing page into any of those becomes a full page load, whose document has no analytics at all.) The Google Fonts stylesheet, by contrast, loads site-wide (the dashboard uses the same type stack); its requests necessarily carry the page URL but nothing else.
- OpenTelemetry only exists in operator builds, and only if you point it somewhere. Shipped desktop installs don't compile the
otelfeature. In a build that does, an unset endpoint still defaults to a local OTLP collector athttp://localhost:4318; set it explicitly (or leave the feature out) if you want no export attempts at all. - File contents never leave unencrypted on a managed or end-to-end project - the storage layer and peer transfers see ciphertext, with the documented exceptions on Security Architecture.
- Usage metering counts bytes and seats, not contents. Billing dimensions are computed from byte counters and org membership.
Client-side diagnostics (opt-in)#
| Mechanism | Default | What it sends | Where it goes |
|---|---|---|---|
SWARMFILE_OTEL_ENDPOINT | http://localhost:4318 when the otel feature is compiled (operator builds); unset on shipped builds, where the feature is absent | Traces/spans for engine operations: operation names, timings, counts, error kinds, and internal identifiers (entry ids, content hashes). No file bytes. Operator builds only: the otel feature is deliberately not compiled into shipped desktop installs. | The OTLP collector you configure |
SWARMFILE_OTEL_SERVICE_NAME | swarmfile-engine | Service name on those spans | Same collector |
SWARMFILE_UPLOAD_TRACE | Off | Promotes upload-attempt logging (including the hub's refusal body) to warn in the local log | Local log file only |
swarmfile-doctor / swarmfile doctor | Runs when you ask | Probe results, hostnames, versions, and error text, written to a local JSON report | Stays local until you attach it to a support request |
RUST_LOG | Off (info) | More detailed local logging | Local log file only |
Normally the client also sends small operational reports to the hub - a P2P bandwidth delta roughly every 60 seconds, a branch-switch report when a machine changes branch, and the metadata calls that make up ordinary work. These carry counters, byte totals, and ids; never file content.
What the service collects#
Usage metering (billing and limits)#
The hub meters usage per org:
| Dimension | Measured | Billed |
|---|---|---|
| Storage | Bytes stored per project (from committed manifests and object sizes) | Overage, then hard ceiling |
| Egress | Bytes served, counted per direction (cloud egress and P2P in/out are tracked separately) | Not billed - unlimited on every plan; a separate org-level abuse backstop can refuse reads after extreme volume |
| Collaborators | External collaborators above the per-seat allowance | Overage, then hard ceiling |
| Seats | Members counted per org and reconciled to the subscription | Per seat |
| Headless API keys | Keys minted, by org and project | Hard cap; key packs raise it |
Metering is counters and sizes - it never inspects file contents. Details, allowances, and ceilings are in Billing & Plans.
Activity and audit events#
The org Activity feed (and its CSV export) records user-visible metadata per event: occurredAt (the CSV column is occurred_at_iso), kind, actor (user id, display name, email), project (id, name), entry (id, name), a summary, and a detail field. Examples are commits, merges, permission changes, quarantine decisions, and plan/policy changes. It does not record file contents, and it never records a file's bytes.
Retention applies to these rows - see Audit-event retention. The personal notification inbox and its email copies contain the same class of metadata (who, what, when), not content.
Notifications by email#
Email delivery uses Postmark as the transport provider. The message contains the same event metadata as the in-app notification (project and entry names, actor names, a link), never file contents. Providers and hosts are listed in Network Requirements.
Third parties that can see what#
| Provider | What it handles | What it can see |
|---|---|---|
| Cloudflare (Workers, R2, Pages) | Hub, identity, storage hosts | Encrypted blocks for private projects; plaintext for Free-plan/public projects (by design); request metadata |
| Postmark | Notification and account email transport | Recipient address and the email's metadata content |
| Stripe | Billing | Org/account details and payment method, never file content |
| iroh/N0 relay network | NAT traversal for P2P when direct connections fail | Connection metadata (endpoints, timings); relayed traffic is encrypted end-to-end between peers |
| Google (swarmfile.com website) | Google Analytics on the marketing/docs pages; Google Fonts site-wide | Page views and the referring URL; nothing from the app or your projects |
What is not collected#
- No browsing history in the dashboard, no cursor tracking, no session recording.
- No content indexing of your files by the service beyond what a preview/search feature needs (managed tier), and none at all on end-to-end projects.
- No telemetry from the Desktop App UI itself.
- No automatic upload of logs or doctor reports - support only gets what you attach.
Verifying this on a machine#
- Confirm no OTLP traffic leaves the host: a shipped build doesn't compile the
otelfeature (swarmfile-engine --build-infodoes not list it), so ports 4317/4318 stay silent even if the endpoint variable is set. - Run
swarmfile-doctor --json --report /tmp/report.jsonand inspect the file: it contains hostnames, versions, probe verdicts, and error strings. - Inspect the cache directory's logs for what
RUST_LOG/SWARMFILE_UPLOAD_TRACEwould add. - For an end-to-end project, confirm the mount's blocks are ciphertext by reconstructing one as described in Storage Format.
Where to go next#
- Security Architecture - encryption tiers and threat model.
- Operations - the audit log and its CSV export.
- Trust & Compliance - DPAs, subprocessors, and incident response.