Docs Security & access
Security & access
Privacy and telemetry
A self-hosted installation never reports usage or analytics. It contacts Kumo.io only to find its services and, once you connect it to a Kumo.io account, to check in with its version and health. Everything else goes only where you point it.
The short version
| Hosted (kumo.io) | Self-hosted | |
|---|---|---|
| Usage metering | Yes, to apply plan limits | Never |
| Product analytics | Yes, inside Kumo.io's hosted service | Never |
| Check-ins to Kumo.io | Not applicable | Only after you connect the installation to a Kumo.io account: version, schema version, platform and health |
| Your cloud data | Stored in Kumo.io's hosted service | Stays inside your installation |
Self-hosted: no usage reporting, by construction
On a self-hosted installation, usage metering and analytics don't run. This isn't a setting that defaults to off: whether they run is decided by the kind of build you install, and only Kumo.io's hosted build includes them. No configuration option can turn them on in a self-hosted image.
Self-hosted: what is sent to Kumo.io
When the installation starts
A self-hosted installation running as a single container fetches Kumo.io's signed service directory, a small document that tells it where Kumo.io's services live. The request carries no information about your estate. If Kumo.io can't be reached, for example on an air-gapped network, the installation keeps working; it never waits on this request.
If you start the container with kumo serve appliance --disable-local-control, it doesn't start the installation-connection services at all, so it doesn't make this request.
After you connect it to a Kumo.io account
Connecting an installation to your Kumo.io account is optional. Read Connect an installation. An installation that isn't connected, or has been deactivated, never checks in.
A connected installation checks in on a schedule, every 6 hours by default and never more often than every 5 minutes. A check-in contains exactly:
| Field | Example values |
|---|---|
| Product version | 1.4.2 |
| Data schema version | a whole number |
| Platform | operating system (linux, macos, windows), architecture (amd64, arm64) and distribution (for example docker, appliance, kubernetes) |
| Health | healthy, degraded or unhealthy |
| Service directory revision | a whole number |
A check-in never contains your cloud resources, names, file paths or activity.
The connected installation also refreshes its licence from Kumo.io, so a purchase or renewal reaches it without you copying files around.
An offline installation makes no licence calls at all: it is never claimed, so it never checks in. Read Licensing offline.
Self-hosted: error reporting
Error reporting is off unless you turn it on with your own key:
BUGSNAG_API_KEYsends server-side errors to your Bugsnag project. Even with a key, errors are sent only from aproductionorstagingrelease stage, or from a stage you name explicitly inKUMO_RELEASE_STAGE.KUMO_BUGSNAG_BROWSER_API_KEYsends errors from the web app in people's browsers to your Bugsnag project.
With neither set, no error reports leave the installation.
Kumo.io's own performance-monitoring agent is only included in the hosted build. Self-hosted images don't contain it.
Self-hosted: what goes where you point it
Everything else your installation sends goes to a destination you configured:
- Your cloud providers, read with the credentials you give each source.
- Your email transport, for verification, invitation, alert, notification and report emails. Read Email.
- Slack, webhooks and alert channels, if you connect them. Read Slack and Webhooks.
- Your identity provider, if you set up OpenID Connect or SAML.
- Your object store or backup bucket, if you configure one.
- Kumo.io support, only when you create a support bundle and send it yourself. Bundles are redacted. Read Support bundle.
If you set KUMO_METRICS_PORT, the installation exposes Prometheus metrics on that port for your own monitoring to collect. Nothing is pushed anywhere.
The web app
The Kumo.io web app has no analytics exporter. It doesn't send usage events to Kumo.io or to any third party, on hosted or self-hosted. Any event the app prepares is stripped of tokens, credentials, secrets and resource attributes first.
Hosted
On hosted Kumo.io, Kumo.io runs the service and stores your workspaces' data. Kumo.io measures usage, such as how many sources you have, to apply your plan's limits, and records aggregate facts such as how many resources and connections a workspace's graph has after each sync. Read Plans and limits and Where my data is stored.