Skip to main content

Wakora agent

The Wakora agent is a single static binary that runs on your servers and reports to Wakora over one outbound, TLS-pinned WebSocket. It is configless: you install it with a team key and nothing else. The agent discovers the host on its own and receives its monitoring logic (signed service definitions, collection intervals, thresholds) from the server after it connects.

Why it is built this way​

Traditional agents make you write config per host: which services to watch, where the logs live, what to scrape. That does not scale to a fleet, and it drifts. Wakora inverts this. The agent ships zero monitoring logic. It enumerates what is actually on the box, the server matches that against a signed catalog, and only matching probes activate. Add a new service to the catalog on the server and every host that runs it starts being monitored, with no agent update and no per-host editing.

Key properties​

  • One binary, every platform. Linux (all major distributions, both systemd and legacy init), Windows (as a service), macOS (launchd). Built for amd64 and arm64.
  • Outbound only. The agent dials out. The server never connects back, so it works behind NAT with no inbound ports opened on the host.
  • Secrets stay local. Credentials for your databases, SNMP devices and so on are stored encrypted on the host and are never sent to the server. Definitions reference them by name only.
  • Signed logic. Every service definition and every binary update is verified against a publisher key before it runs.
  • Never restarts your services. A change that needs a service reload (for example enabling an APM extension) is staged, and a human applies it. The agent only ever restarts its own service, and only for its own updates.

How it works in four steps​

  1. You install the agent with a team key. The key is used once for registration, then discarded. It is never written to disk.
  2. The agent registers and receives a per-server key and a UUID. That key auto-rotates every 7 days.
  3. The agent enumerates the host (processes, listening ports, packages, service units) and the server pushes the service definitions whose signatures match.
  4. The agent runs those probes locally and streams metrics, discovery facts, check results, events and traces up the same WebSocket.

What this documentation covers​

This is the operator guide for the agent: how to install it, register it, configure the few things that are configurable, and understand what it monitors. If a feature is on the roadmap but not shipped yet, it is called out explicitly.

Planned features

Where a capability is designed but not built yet, you will see a Planned note like this one. Everything without such a note is live today.

Start with How it works, or jump straight to Installation.