What the agent collects
The agent is a single Go binary that observes and summarizes only. It never runs remediation, never opens an inbound port, and never accepts a command from the server. (The one thing it fetches back — fleet decisions signed with your organization’s key, only if you enable them — it hands unread to the warden, which verifies and applies them; see Security & mTLS identity.)
What it collects
| Collector | What it reports |
|---|---|
| Host | Hostname, OS and version, kernel, architecture, CPU (model, vendor, family, vCPUs / cores), total RAM and swap, the virtualization platform, mounted filesystems with size, uptime, the running vs newest-installed kernel, a stable machine fingerprint |
| Metrics | System metrics such as CPU, memory and disk usage over time |
| Packages | Installed packages, pending updates, security updates, and whether a restart is required |
| Installed outside apt | From v0.28: Node.js installed from a tarball or a version manager (nvm, n, volta, fnm), npm’s global packages (Claude Code among them), Go toolchains and Go-built binaries in /usr/local and /opt with the modules they embed, and Composer phars; from v0.30, Python interpreters built from source or installed with pyenv, uv or conda, and the packages pip installed outside apt — in /usr/local, --user installs, virtualenvs (under /opt, /srv, /var/www, homes, pipx, and wherever a running process starts one) — each with its version, where it is, and whether a process runs it. Versions are read from files the tools ship (patchlevel.h, a package’s METADATA), never by running them. Demerzel checks them against the projects’ own security releases and end-of-life dates, and OSV for npm, Go, Packagist and PyPI. A home closed to other accounts stays unread |
| Services | Running and failed services (failed units are named), and for each failed unit why it stopped: systemd’s result category, the exit code or the signal that killed it, its restart count and since when it has been down. Metadata from systemd’s own accounting — never journal content |
| Domains | Domains served, read from local Apache / Nginx virtual hosts |
| Certificates | TLS certificates in use, with issuer, subject and expiry |
| Firewall & ports | Listening ports (and whether each is exposed to the world), the firewall backend and default policy, its rules where readable, and fail2ban jails |
| Web stack posture | MySQL/MariaDB max_connections and slow query log, PHP-FPM pools and their pm.max_children, whether the web server logs the visitor behind a proxy — the settings behind Demerzel’s hardening findings (from v0.19); from v0.21, how sshd lets one log in (password, root, ports) and whether security updates install themselves, for the security checklist |
| Kernel & service hardening | From v0.29: the sysctl values the hardening guides check, in force and as the sysctl.d files will set them at boot; the mount options of /tmp, /dev/shm, /var/tmp and /home; whether dccp, sctp, rds or tipc is loaded; more of sshd’s limits (MaxAuthTries, LoginGraceTime, forwarding, whether AllowUsers restricts logins — never the names); the algorithms sshd really offers, read from its key exchange over a connection to 127.0.0.1 every 6 hours; and systemd-analyze security’s exposure score of each service, hourly |
| Hardening audits | From v0.29, opt-in: the latest report of the audit tool you run — Lynis’s report.dat, OpenSCAP’s XCCDF results or ARF — read from /var/lib/demerzel/audits/<tool>/, which service.sh grant-audit fills. Its score, counts by status and each finding’s identifier, status, severity and title; sent when the report changes, and daily. The agent runs neither tool |
| Web traffic (opt-in) | Per client address: request and status counts, vhosts touched, first/last seen, a few sample paths (query strings removed) and the user agent — summarized from the web server’s access logs. From v0.16 it also runs built-in detection rules over them (secret-file probes, CMS probes, request rate, spread across vhosts, error ratio) in shadow mode and reports what they would have done. From v0.18, demerzel-agent replay runs the same rules over past logs on request (see Replay past logs), sent the same way and kept apart from live data. Only once you allow it to read them with grant-web-logs; until then it reports that the logs are unreadable |
| fail2ban bans (opt-in) | Each ban and unban fail2ban’s jails logged: jail, address, action, time. Only once you allow it with grant-fail2ban-logs (from v0.24) |
| SSH logins (opt-in) | Per client address, SSH connections that failed to log in, from sshd’s journal messages; fires ssh-bruteforce at 10 failed connections within 10 minutes, and runs in replay too. Only once you allow it with grant-ssh-logs (from v0.22) |
| Warden (opt-in) | Only where you installed the warden: its status and journal — what it blocked, refused or lifted, and why. From v0.20, while a warden is there, the agent also reads new access-log lines every half second, so a rule firing reaches the warden within about a second |
| Package history | Past apt runs — when, which command, and which packages changed. Read from the host’s own apt log, so it covers changes made before Demerzel was installed. Never who ran them. |
Most of this comes from world-readable files and /proc. Web access logs are the deliberate exception: they are root:adm, so the agent reads them only after you grant it, and it remembers how far it has read in each (in its own config directory) so every line is summarized once. The other gap is a firewall’s own rule list, which is usually root-only — the agent still detects the firewall and its ports, and you can optionally export the rules for it to read.
How often
Collection runs on the interval you set with --interval (default one minute). Metrics benefit from a short cadence; inventory-style facts change rarely and are only re-sent when they actually change. Package history is bounded to the last 12 months and 500 transactions, so an old machine’s log can’t turn into an enormous first upload. Everything is summarized on the host before transmission — Demerzel receives compact facts, not raw log streams.
Idempotent by design
Each observation carries a unique, time-ordered id, so retries and overlapping runs never create duplicates. If the network blips, the agent simply sends again — the server records each fact exactly once.