What "Zero Outbound Telemetry" Actually Means for Self-Hosted Monitoring

“Self-hosted” and “privacy-respecting” get claimed by a lot of software that still phones home in ways nobody disclosed clearly. Usage analytics baked into the binary. A license check that quietly reports back more than a validity flag. A “check for updates” feature that also sends a device fingerprint nobody asked about. None of that is necessarily malicious — it’s often just how software gets built by default — but “self-hosted” alone doesn’t guarantee any of it isn’t happening.

We think a claim like “zero outbound telemetry” is only worth making if it’s specific enough to be checked, not just a vibe. So here’s exactly what that means for SPP Command Deck, split into the three categories of network activity that actually matter.

1. Telemetry and license phone-home — never, full stop

Nothing about your estate — server names, counts, health status, usage patterns — and nothing about your license or install (key, fingerprint, activation status) is ever sent anywhere by the application. Licensing is verified entirely offline: a signed license file, checked locally against a public key baked into the binary, on every start. There is no license server the app calls to check in. This isn’t a policy promise sitting on top of code that could still phone home — there is no code path that does it.

2. App-initiated reference pulls — allowed, but disclosed and individually toggleable

This is the category that’s easy to gloss over in most “we don’t collect telemetry” claims, so we’re naming it directly instead. A couple of features in the app do reach out to public, non-identifying sources — not about your estate, just fetching reference data:

• A background check that pulls current SQL Server Cumulative Update version info and scrapes postgresql.org for version baselines, so patch-currency checks have something current to compare against.
• The Deployment page’s third-party script fetches — pulling sp_WhoIsActive, Brent Ozar’s First Responder Kit, and Ola Hallengren’s maintenance solution straight from their upstream sources, only when you ask for them.

Nothing about you goes out in either case — no server names, no license key, no usage data, nothing identifying — but network activity is still network activity, and we don’t think “nothing sensitive leaves” is a good enough reason to make it silent. Settings → Telemetry lists every one of these outbound calls individually, with its own on/off switch. Turning one off just stops that one feature from reaching out; nothing else about the app changes. If you run in a fully air-gapped environment, this page is where you go to confirm — and enforce — that nothing tries to leave.

3. Your monitoring connections — always fine, this is the product

The app connects outbound to whatever database servers you point it at — on-prem, AWS, Azure, GCP, Oracle Cloud, wherever your estate actually lives. That’s not a caveat to the privacy claim, that’s the product working as intended. Monitoring your servers requires connecting to your servers.

The one deliberate exception, and why it’s built the way it is

An optional update check exists: a pure anonymous “is there a newer version” pull, with no license key, no fingerprint, and no usage data attached. No auto-download — it just tells you a newer version exists and links to it. This is the single exception to “the app never calls out on its own,” and it’s opt-in and disclosed the same way as everything in category 2, on the same Settings page.

How to actually verify this yourself

Don’t take a vendor’s word for a networking claim when you can check it. A few ways, in increasing order of effort:

1. Read the Settings → Telemetry page — every outbound endpoint the app can reach is listed there, by name, with its own toggle. If something isn’t on that list, it shouldn’t be calling out.
2. Run it fully offline and confirm core monitoring still works — Estate Overview, Server Detail, and Custom Dashboards don’t require any internet access at all, only a route to the database servers you’re monitoring.
3. Watch the wire. Point the container at an egress-restricted network (or just run tcpdump/a firewall log against the box) and confirm nothing unexpected shows up beyond your own monitored servers and whatever reference pulls you’ve deliberately left enabled.

A specific, checkable claim is worth more than an unspecific reassuring one. That’s the standard we’re trying to hold this to.