Privacy: your data stays yours

SpatiumDDI collects no telemetry, no usage analytics, no crash reports, and no account or registration data. There is no phone-home, no license server, no sign-up, and no project-controlled endpoint the software talks to. Everything you put in it — zones, records, leases, subnets, credentials, query logs, audit history — lives in your PostgreSQL on your infrastructure, and the maintainers have no way to see it and do not want it. The documentation site and the web UI use no analytics or tracking scripts.

The software makes no outbound connection you did not configure, with one exception: a daily anonymous check of GitHub for a newer release (an unauthenticated GET; GitHub sees your IP address and nothing about your install). Turn it off under Settings → Application → Updates → Check for GitHub Releases, or run fully air-gapped — every feature works with no internet access at all. Optional features that do reach third parties (Fingerbank device profiling, the Operator Copilot’s LLM provider, Let’s Encrypt, blocklist feeds, cloud DNS / integration mirrors, the whois and RBL tools) are off until you configure them, and the table below lists exactly what each one sends and to whom.

There is no telemetry endpoint to opt out of, because there is no telemetry endpoint. That is a design constraint, not a current state: CLAUDE.md non-negotiable #17 forbids adding one, and a CI test (backend/tests/test_outbound_hosts_documented.py) fails the build when a hostname appears in the backend that is not documented on this page.

1. What is never collected

2. The one connection that is on by default

Daily GitHub release check — GET https://api.github.com/repos/spatiumddi/spatiumddi/releases/latest

Fired once a day by Celery Beat (backend/app/tasks/update_check.py), so the UI can tell you a newer release exists. It is:

• unauthenticated — no token, no identifier, no cookie;
• empty in the outbound direction — the request carries no version string, no install id, no counts, no hostnames. Nothing about your deployment is in it;
• anonymous to us and visible only to GitHub — GitHub sees the source IP address and an HTTP client User-Agent, exactly as it would if you loaded the releases page in a browser. SpatiumDDI’s maintainers operate no server in this path and receive nothing.

It is on by default because it is genuinely empty and because an operator who does not know a security fix shipped is worse off than one whose firewall logged a daily GET to GitHub. If you would rather it did not happen, one toggle stops it:

Settings → Application → Updates → Check for GitHub Releases (or PlatformSettings.github_release_check_enabled = false). With it off, the task returns immediately and opens no socket. Nothing else in the product degrades — you simply do not get the “update available” pill.

3. Every outbound connection, in full

This table is normative. A hostname that appears in backend/app and not here fails CI (see §8).

3.1 Enabled by default

That is the whole list.

3.2 On demand — only when an operator clicks

Everything in this section is a per-click action with a visible result; nothing here runs on a schedule.

3.3 Off until you configure them

3.4 Appliance host (OS-level, not the application)

The OS appliance is a Debian host, and a Debian host talks to the network the way Debian hosts do:

None of this is SpatiumDDI-specific traffic and none of it carries your DDI data.

4. Air-gapped operation

Every feature works with all of the above blocked. That is not a claim about the happy path — it is non-negotiable #5 in the project’s own build rules: DNS and DHCP service containers cache their last-known-good config locally and keep serving when the control plane is unreachable, and by the same logic nothing in the control plane requires an internet round-trip to function.

Concretely, on an air-gapped install:

• the appliance ISO ships every container image in its rootfs, so install and first boot need no registry;
• upgrades are an uploaded .raw.xz slot image, verified against its SHA-256 sidecar;
• the release check fails, logs a warning, and stamps latest_check_error — it does not retry in a loop or block anything. Turning it off removes even that;
• blocklists, OUI data and device profiling are simply features you do not enable.

5. The support bundle

POST /system/support-bundle (#875) produces the diagnostics archive you would attach to a bug report. It is generated locally and uploaded nowhere — the response is a download; SpatiumDDI has no endpoint to send it to.

Because a bug report on a public repository is public, the bundle is scrubbed in two tiers:

• Secrets are hard-excluded in every mode, including the unscrubbed one — Fernet-encrypted values, bcrypt/argon2 hashes, PEM blocks, JWTs, pre-shared keys and TSIG secrets, matched by field name and by value shape.
• Identifiers are pseudonymised, not deleted: IP addresses, hostnames, MAC addresses and usernames are replaced with stable synthetic values derived by HMAC from your install’s SECRET_KEY. Topology survives (the same /24 maps to the same synthetic /24, with the host octet preserved) so the archive is still diagnosable, and the mapping is unguessable outside your install. Synthetic IPv4 lands in 240.0.0.0/6; the IPv6 interface identifier is discarded rather than mapped, because SLAAC embeds the MAC address.

The decode map — the only thing that can reverse the pseudonymisation — is a separate endpoint and is never included in the archive. It does not leave your install unless you deliberately send it to someone.

6. The mobile app

The SpatiumDDI mobile app lives in its own repository and carries the same promise: it speaks only to your control plane’s REST API, at the address you enrol it against. It has no backend of its own, no analytics SDK, and no account. Enrolment is a QR code minted inside your authenticated session (#906), carrying your control plane’s address, an API token you created, and the TLS certificate fingerprint the client pins.

7. Who can see what, inside your install

Privacy from the outside world is one half; the other half is that SpatiumDDI is built to be delegated without handing over everything:

• group-based RBAC with per-resource grants — a department admin can hold one subnet or one zone (docs/PERMISSIONS.md);
• every mutation is written to an append-only, hash-chained audit log before the response returns (non-negotiable #4), so administrative access is recorded rather than assumed;
• credentials at rest (provider secrets, agent keys, cloud tokens) are Fernet-encrypted with your CREDENTIAL_ENCRYPTION_KEY (or a key derived from SECRET_KEY when you have not set one) and never returned by the API — endpoints report *_set: true, not the value.

8. Keeping this page true

A privacy statement rots the first time somebody adds a convenience fetch. Two guards keep this one honest:

• backend/tests/test_outbound_hosts_documented.py walks backend/app for hostname literals and asserts every one of them appears on this page. A new outbound host fails CI until it is documented here, with its default and its payload. Editing this file runs that suite (it is a declared carve-out in .github/scripts/ci-backend-must-run.txt).
• CLAUDE.md non-negotiable #17 — No telemetry. Never add an outbound connection that is not operator-configured and documented here; anything default-on needs an issue and a decision, not a PR.

The guard covers Python source under backend/app. Two things it cannot see, and which therefore need a human: hostname literals in the appliance’s shell scripts under appliance/mkosi.extra/usr/local/bin/ — the guard reads Python only, so §3.4.1’s rows were written by hand and the next curl added to the installer will pass CI with nothing to catch it; hosts assembled at runtime from operator input (which is the point — those are your endpoints); and the feed catalogues in backend/app/data/, whose entries are all opt-in downloads covered by the blocklist row above.

If you find a connection this page does not describe, that is a bug — please open an issue.

Appendix — hostnames in the source that are not connections

The guard in §8 matches text, so these appear in backend/app and are listed here to keep the check honest. None of them is contacted.

Documentation and homepage links (shown in the UI or written in a comment, never fetched): www.spatiumddi.com (the ACME client’s User-Agent string, as RFC 8555 asks for), fingerbank.org, aistudio.google.com (the “get an API key” link in an error message), bacnet.org, kea.readthedocs.io, schema.org (a JSON-LD @context identifier in a Teams-format webhook payload — a namespace URI, not a URL that is dereferenced), www.opengis.net (the GML namespace in the E911 PIDF-LO renderer — likewise an XML namespace identifier, written into the document we emit and never fetched; the accompanying urn:ogc:def:crs:EPSG::4326 CRS reference is a URN precisely because it names a coordinate system rather than locating a resource), and the DNSBL catalogue’s homepage fields: www.spamhaus.org, www.spamcop.net, www.barracudacentral.org, www.uceprotect.net, www.sorbs.net, psbl.org.

Placeholders in examples, defaults and error messages — these are where you type your own address: app.example.com, ddi.example.com, dns.example.com, ipam.example.com, netbox.example.com, nc.example.com, nextcloud.example, nexus.example (the example receiver URL on the https_put backup destination’s form — an address you replace with your own Artifactory, Nexus or internal receiver), my-resource.openai.azure.com, pdns.internal, tdns.internal, api.meraki.cn (named in a docstring as the regional shard a China-based operator would enter).

In-cluster addresses, which never leave the node: spatium-control-spatiumddi-api.spatium.svc.cluster.local — the Kubernetes service name an appliance supervisor uses to reach the control plane it is already part of.

Questions about anything on this page are welcome as a GitHub issue or discussion. If a future release adds an outbound connection, it will be in the table above and in the CHANGELOG before it is in your install.