Skip to main content

Configless by design

Configless means there is no config file you must write for the agent to do its job. The monitoring logic (what to watch, where the logs are, what thresholds apply) arrives from the server as signed definitions. The agent self-discovers the host and matches locally.

What is on the host is deliberately small, and split into config and state.

Config: /etc/wakora/​

Config directory, root:root, 0600. On Windows this folds into %ProgramData%\Wakora.

  • identity (machine-managed, not for humans): the host UUID (the server id) and the per-server key stored as machine-bound ciphertext. Created and updated by wakora --key.
  • wakora.conf (optional): non-secret location overrides only. See Location overrides.
  • secrets.conf: credentials for local services, encrypted. Managed with wakora secret. See Secrets.
  • .seed (root-only, 0600): a random value mixed into the encryption key so a leaked ciphertext plus a known machine id is not enough to decrypt.

State: /var/lib/wakora/​

State and data live separately, following the usual split where /etc is config and /var/lib is variable state. On Windows both fold into %ProgramData%\Wakora.

  • the offline spool (buffer.jsonl),
  • provisioned APM artifacts (downloaded binaries),
  • staged changes awaiting operator action.

A binary or a spool file does not belong in /etc, which is why state is a separate tree.

What comes from the server​

  • service definitions and match signatures,
  • collection intervals (a global default with per-probe overrides),
  • thresholds and enabled collectors,
  • optional non-secret per-host location overrides.

None of this is stored as editable config you maintain. It is delivered signed, verified, and applied at runtime.

The one rule about secrets​

Only non-secret location facts (paths, sockets, ports) may come from the server. Secret values never come from the server and never leave the host. This is a hard boundary, covered in Secrets.