Skip to main content

What the agent sends, and what it never sends

Everything the agent transmits goes over one outbound TLS connection to the Wakora endpoint (eu.gw.wakora.io, port 8443), authenticated with the host's own key and pinned to our public key. Nothing listens for inbound connections. This page is the inventory of what travels over that connection, in both directions, and what is designed never to.

What leaves the host​

Host metrics. CPU, memory, swap, disks per mount, load, network throughput, uptime, and the top processes by CPU, memory and I/O (process names only, never their arguments).

Inventory facts. Process names with their command lines, listening ports with the owning process, installed packages with versions, service units and their state, the init system, cron entries (schedule, user and command), OS identity, IP addresses and the kernel capabilities the agent detected. Command lines are redacted before they leave: passwords in connection strings, key-like flags and card-shaped numbers are replaced with ***.

Service facts and metrics. Whatever the matched definitions collect: versions, config and log paths, and the svc.* metrics listed in the metrics reference. For a website that means its hostname, port, certificate dates, DNS verdict and the PHP version of its pool. For a database it means counters, never query results.

Check results. Pass or fail per probe, with the probe's own short message (for example "access denied" or "certificate expired").

Events. Discovery changes, anomalies the on-host detector found, integrity changes on watched files (a hash changed, not the content), Proxmox tasks, and the "action required" messages of staged changes with the exact command they propose.

Traces and profiles once you enable APM: spans with their attributes (capped in count and length, and the exact SQL text of a query when the runtime's instrumentation records it) and CPU profiles as folded stacks of function names, file paths and plugin names. Sampling happens on the host, and no request body or response body is ever part of a span. URL-shaped span attributes are cleaned before they leave: the value of every query parameter is masked (?key=***&page=***), the fragment is dropped and user:password@ credentials are masked, so an API key a client put in a URL never reaches the platform through a trace. The visitor's address that some instrumentations put on a server span is removed as well, so a trace describes the request, not the person. The same masking is applied again on arrival, as a second net.

Log lines for the services you monitor, at notice level and above by default. Every line passes a redaction pass on the host first: bearer tokens, API keys, password= pairs, cloud access keys, card-like numbers, credentials embedded in URLs and the values of query parameters in URLs become ***. Info and debug lines are read only for services you switch to full depth. A hard cap of 2000 lines a minute per host is enforced on the host, dropping the least severe lines first. Identical consecutive lines are folded on the host into one line with a repeat count, so a loop writing the same error a thousand times costs one line.

RUM beacons for sites you opted in: page path, Web Vitals, browser and device class, JavaScript error messages with their stack, and the visitor's address for one purpose: it is resolved to a country on arrival and then discarded. The address is never stored.

Device data from the SNMP collector role: the values the device answers, its traps and syslog lines, and, if you enable configuration backup, the device configuration with passwords and keys masked on the collector before it is sent.

What never leaves the host​

  • Credential values. Database passwords, SNMP communities, API tokens and SSH keys are stored encrypted on the host and referenced by name. Definitions arrive with names only, and no message type exists that could carry a value out.
  • Your team key. It is used for one registration exchange in memory and never written to disk; the host gets its own rotating key instead.
  • File contents. Integrity monitoring sends a hash of /etc/passwd, /etc/shadow, /etc/sudoers and sshd_config, never the file. Configuration scans (nginx -T, the PHP-FPM pool files) are parsed on the host and only the derived facts travel.
  • Request and response bodies. Neither the local site probes nor APM nor RUM ever capture them.
  • Access logs of your web servers, unless you switch that service to full log depth, and even then only after redaction.
  • Visitor IP addresses beyond the country lookup on arrival.
  • Process environments. The agent reads a process environment locally to detect an applied change; it does not transmit it.

What comes down to the host​

Signed service definitions and the rule catalog, per-host configuration (capability grants you switch in the console, location overrides, a version pin), and a handful of commands: "collect now" when the platform has heard nothing for a while, "rotate key", "check for an update", and a removal order that carries the publisher's signature and names this host's identity, so no one else's removal can ever reach it. The agent verifies a signature before it acts on any of them.

Where the data goes​

The endpoint baked into the published builds is in the EU; data is stored and processed there. How long each kind of data is kept depends on your plan, see the pricing page. The full data-flow document, the threat model and the reproducible-build attestation are in the trust pack; the agent source is public at github.com/wakora-io/agent, so every statement on this page can be checked against the code that runs on your host.