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 or the agents 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/spatiumnorth/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 or in an agent package under agent/ — or a public IP address in an agent package — 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. (The RDAP lookups behind a Domain or ASN do also run on a schedule, once you have created such a row. They are listed in §3.3 for that reason.)

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.

3.5 DNS and DHCP servers SpatiumDDI runs

The connections above are made by the control plane or the appliance host. The DNS and DHCP service containers otherwise reach the control plane and the addresses you configure on them (forwarders, failover peers, DDNS targets) — plus whatever answering your clients’ queries needs, since they are DNS servers: a recursive BIND9 group with no forwarders resolves from the root servers, as any recursive resolver does. SpatiumDDI picks no upstream for them.

PowerDNS ALIAS records resolve their targets at query time through the group’s own forwarders, over plain DNS (port 53): the list you set under the group’s server options, which a PowerDNS group otherwise does not use. With no forwarders, or with forwarders over TLS, HTTPS or QUIC (which PowerDNS’s resolver= cannot speak, and which SpatiumDDI will not downgrade to plaintext), ALIAS expansion is off and the API refuses a new ALIAS record. Builds before #1353 rendered resolver=1.1.1.1,8.8.8.8 into every PowerDNS server instead, sending ALIAS targets to Cloudflare and Google; an upgrade replaces it. A PowerDNS group that already serves ALIAS records and has no forwarders stops expanding them (A and AAAA queries for those names get no answer) until you set forwarders.

PowerDNS’s own security-status polling (a TXT query for auth-<version>.security-status.secpoll.powerdns.com, which names the version you run) is turned off: SpatiumDDI renders an empty security-poll-suffix. Builds before #1353 sent it from every PowerDNS server at startup and periodically; the setting takes effect the next time the PowerDNS container starts, which an upgrade does. The optional dnsdist front (Docker Compose only) has the same feature, also on by default, querying dnsdist-<version>.security-status.secpoll.powerdns.com through the container’s system resolver; its entrypoint now writes an empty setSecurityPollSuffix(""), which turns it off from the next restart.

4. Air-gapped operation

Every feature works with all of the above blocked. Builds before #1353 were the exception: a PowerDNS server group needed a route to 1.1.1.1 / 8.8.8.8 to start (§3.5). This 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. Three guards keep this one honest:

• backend/tests/test_outbound_hosts_documented.py walks backend/app and the four shipped agent packages (agent/{dns,dhcp,looking-glass,supervisor}/spatium_*) for hostname literals, and the agent packages for public IP addresses in string values, 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 or an agent package runs that suite (both are declared carve-outs in .github/scripts/ci-backend-must-run.txt).
• frontend/src/lib/outbound-hosts.test.ts does the same for the Web UI: every hostname in a string literal, template or JSX text under frontend/src, in frontend/index.html, and in the web tier’s frontend/default.conf.template (its Content-Security-Policy), must appear on this page. It matches every host rather than only src= / fetch( uses, because a URL built into a variable and handed to an <img> later is indistinguishable from a link by syntax. That is exactly how the MFA enrolment screen sent each user’s TOTP secret, inside the otpauth:// URI, to api.qrserver.com to draw its QR code, from the release that added MFA (2026.05.05-1) until #400’s Content-Security-Policy began blocking the request in 2026.06.13-1. The code is now drawn in the browser. If your account enrolled MFA on a release in that range, disable and re-enrol it to get a secret nobody else has seen. The test runs in the Frontend Lint job, which runs on every pull request, including one that only edits this page.
• 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 and the agent packages; the agents’ tests/ directories are not shipped and are not scanned. It looks for IP addresses in the agents only: in the backend they are almost all example addresses in tool descriptions, and the hardcoded PowerDNS resolvers in §3.5, which this page once missed, are IP addresses in agent code, which a hostname scan cannot see. Its hostname scan reads hosts out of http:// and https:// URLs, so a hostname written bare (a resolver name, a tls:// endpoint) is not seen either. The 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’s rows were written by hand and the next curl added to the installer will pass CI with nothing to catch it; the same for the agent images’ entrypoints and config files under agent/*/images/; connections a bundled daemon (BIND9, PowerDNS, dnsdist, Technitium, Kea, GoBGP) makes on its own built-in defaults, which appear in no SpatiumDDI source at all; hosts assembled at runtime from operator input (which is the point — those are your endpoints); public IP addresses in the backend; 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 or an agent package 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): github.com (issue links in agent docstrings — the installer’s SSH-key fetch in §3.4 is a separate use), 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, adaptivecards.io (the $schema identifier in a Teams-format webhook payload — a schema 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 the Web UI (frontend/src, checked by the second guard in §8), none of them loaded by the browser: links in help text (en.wikipedia.org, the timezone list; docs.docker.com; app.netbird.io and unifi.ui.com, where to find an API key); example values in placeholders (automation.example.com, boot.example, cloud.example.org, collector.example.com, example.com, idp.example.com, k8s.example.com, login.example.com, netbird.example.com, netbox.internal, proxy.internal, and the URL shapes of a public calendar feed and of chat webhooks: calendar.google.com, hooks.slack.com, discord.com); and two form presets the control plane contacts only once you save a provider with them, as your own endpoint: login.microsoftonline.com (the Entra ID OIDC discovery URL) and host.docker.internal (a local Ollama for the Copilot).

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.