Host-Based Detection Part 3: Agent, Manager, Indexer, Dashboard, and What 5.0 Changes

23 September 2026 LinuxSecurityWazuhArchitecture

Wazuh’s architecture, in the version actually running on both of this site’s own deployments, 4.14.x, per From Dropbox to Daily Driver Part 6 and Part 7, is four pieces, three of which can live on one box or be split across several.

The agent

Installed on the monitored host itself. Collects log files, runs the file integrity monitoring, rootcheck, and SCA modules covered in Part 6 of this series, and ships everything it finds back to a manager. It’s a genuinely small footprint, Part 7’s Pi build ran it comfortably on a Raspberry Pi 4, and, in the 4.x line, talks to its manager over TCP 1514 for log and event data and 1515 for the initial enrollment handshake.

The manager

Where analysisd actually applies decoders and rules to whatever the agent sent, decides whether anything matches, and dispatches an active response if one’s configured. In 4.x, this is a substantial set of separate daemons doing distinct jobs: remoted handling agent connections, analysisd doing rule matching, syscheckd running the manager’s own FIM, and others alongside them.

The indexer

Wazuh’s own fork of OpenSearch, storing and making every alert searchable. In the standard, non-all-in-one deployment profile, Filebeat sits between the manager and the indexer, shipping alerts.json records across. The all-in-one profile this site’s own build used (wazuh-install.sh -a) bundles all three components on a single host, which is why Part 6’s sizing, 4 vCPU, 8 GiB RAM, 50 GB disk minimum per Wazuh’s own documentation, comfortable up to 100 agents and 90 days of retention, covered manager and indexer together rather than as separate sizing exercises.

The dashboard

A fork of OpenSearch Dashboards: the web UI everything in Part 7’s SCA and login-alert screenshots actually came from.

What 5.0 changes, and why this series still documents 4.x

Wazuh 5.0 is in public beta as this gets written, beta5 per its own release notes, not the version either of this site’s deployments runs, and a direct comparison against 4.14.7 makes clear why one analysis of the beta calls it “a migration, not an upgrade” rather than a normal version bump.

The manager’s daemon count drops sharply. wazuh-agentlessd, wazuh-maild, wazuh-csyslogd, wazuh-integratord, wazuh-logcollector, wazuh-syscheckd, and wazuh-execd are all removed outright, alongside wazuh-logtest, manage_agents, agent_control, and wazuh-reportd, fourteen binaries gone from an original twenty-nine. Filebeat’s replacement isn’t a new daemon at all. It’s an in-process shared library, the indexer connector, linked directly into the normalization and detection services, which buffers events in memory and discards anything unflushed if the manager restarts, a real and meaningful change from 4.x’s disk-backed alerts.json persistence, worth knowing before relying on it for anything where losing a few seconds of in-flight alerts around a restart would matter.

Agent transport changes too. 5.0 agents talk to their manager over HTTPS on port 1517 using TLS 1.3 with a bearer token per agent, replacing the 1514/1515 pair entirely, and the manager itself stops occupying agent ID 000, so enrolled agents now start at 001. Detection logic is relocating too: rule matching is moving from the manager into scheduled detectors running inside the indexer, and events and findings are becoming separate document types routed by integration category rather than the flat rule-based alert stream Part 7 of this series describes. Filesystem paths move from /var/ossec to /var/wazuh-manager, and the configuration root tag changes from ossec_config to wazuh_config, small but real breaking changes for anyone with existing tooling or documentation, including, eventually, this site’s own, written against the 4.x paths.

None of that is live on either of this site’s real deployments, both still comfortably on the 4.14.x line, and this series documents that shipping architecture throughout rather than the beta. Worth revisiting once 5.0 reaches general availability and either of those two managers gets upgraded for real, at which point the migration-not-upgrade framing above stops being theoretical.

Sources: