Wazuh: an open source SIEM and XDR stack you assemble yourself

What Wazuh actually replaces

Wazuh is a threat prevention, detection and response platform aimed at teams that need host-level and cloud-level visibility without handing their telemetry to a vendor. The README frames it as protecting workloads across on-premises, virtualised, containerised and cloud environments, and the capability list reads like a consolidation of several separate purchases: intrusion detection, log analysis, file integrity monitoring, vulnerability detection, configuration assessment, incident response and regulatory compliance reporting.

The intended user is not a solo developer. It is a security or infrastructure team that already runs servers, has opinions about where logs live, and is willing to operate a manager and an indexer. The compliance angle is explicit in the README, which notes Wazuh is widely used by payment processing companies and financial institutions to meet PCI DSS requirements, with dashboards for PCI DSS, GPG13 and GDPR. That framing tells you the audience: regulated environments where an auditor will ask who changed a file and when.

If you only want a log shipper, Wazuh is heavier than you need. The value comes from the ruleset and the correlation, not from moving bytes.

Agent, manager, indexer: the three moving parts

The architecture is stated plainly in the README: an endpoint security agent deployed to monitored systems, and a management server that collects and analyses data gathered by the agents. Alongside those, Wazuh integrates with the Wazuh Indexer, which provides search and visualisation so users can move through their alerts.

Data flow follows that shape. Agents read operating system and application logs and forward them to the central manager, which performs rule-based analysis and storage. Where no agent can be installed, the server accepts syslog from network devices or applications, which is the escape hatch for switches, routers and appliances you cannot instrument.

Two mechanisms sit inside the agent worth separating. The first is scanning: agents look for malware, rootkits and suspicious anomalies, including hidden files, cloaked processes, unregistered network listeners and inconsistencies in system call responses. The second is inventory: agents pull software inventory data and send it to the server, where it is correlated against continuously updated CVE databases. That distinction matters operationally because inventory is periodic and cheap, while scanning is the part that costs CPU on the endpoint.

The manager side is signature-based. The README describes a regular expression engine that analyses collected log data for indicators of compromise. This is the part you will spend real time on, because a regex ruleset is only as good as the person writing the rules, and the repository carries a ruleset directory precisely because that work is ongoing.

Installing Wazuh and getting one agent reporting

The repository does not present a single install command. Its top level contains install.sh, upgrade.sh, an INSTALL file, and separate directories for packages and the framework, which is the honest signal that Wazuh is deployed as several components rather than one binary. The README points to documentation at documentation.wazuh.com for deployment detail.

The installer script is the entry point the repository itself provides:

./install.sh

Running it from a checkout assumes you have already satisfied the build and dependency requirements described in the INSTALL file, which is where platform-specific prerequisites live. If you would rather not build, the packages directory and the project's documented deployment guides are the alternative route.

Once a manager is reachable, the agent is what you install on the machines you care about. The README describes the agent as lightweight and multi-platform, deployed to monitored systems, and it is the component that reads logs and forwards them. After an agent registers with the manager, the first thing to confirm is that events appear in the Wazuh Indexer through the dashboard, because an agent that connects but ships nothing is a configuration problem, not a network one.

For rule work, the documentation covers wazuh-logtest as the tool for testing whether a log line matches a rule before you push that rule into production. That workflow, write a rule, test it against a sample line, then deploy, is the one habit that keeps a Wazuh deployment from filling with false positives.

Where the design costs you

The clearest limitation is operational weight. Agent, manager and indexer are separate concerns with separate failure modes, and the repository ships upgrade.sh alongside install.sh because upgrades are a procedure, not a package manager invocation. A team without someone who owns that procedure will drift versions across the fleet.

The ruleset is the second cost. Signature-based detection using regular expressions over log data is fast and transparent, but it is brittle in the way all regex rules are: a vendor changes a log format and your rule silently stops matching. Nothing in the README suggests the ruleset is self-maintaining, and the presence of a dedicated ruleset directory in the repository indicates where that maintenance happens.

Third, the agent-based model has a hard boundary. You get deep host visibility where you can install an agent. Elsewhere you fall back to syslog, which gives you the log line and little else. If your estate is dominated by appliances and managed services you cannot instrument, the agent capabilities that make Wazuh distinctive, file integrity monitoring with user and application attribution, software inventory, active response, are largely unavailable to you.

Finally, the licence. The repository's licence field is NOASSERTION, meaning GitHub could not classify it automatically. The LICENSE file in the repository is the authority, and if you plan to redistribute Wazuh inside a product or offer it as a managed service, read that file and the project's own licensing statements rather than assuming an OSI-approved permissive licence.

Wazuh against a hosted SIEM and against a plain log pipeline

The obvious alternative for many teams is a hosted SIEM, where ingestion, storage, correlation rules and dashboards arrive as a subscription and someone else handles upgrades. The difference in approach is not the feature list, it is who owns the indexer. With Wazuh you run the manager and the indexer, which means you control retention, you control where data rests, and your cost curve is hardware and staff time rather than per-gigabyte ingestion. The trade is that capacity planning, index lifecycle and upgrade sequencing become your problem, and the README offers no sizing guidance.

The other alternative is not a SIEM at all: a log pipeline built from a shipper and a search store, with alerting written by hand. That approach can be cheaper and simpler if your question is narrow, for example "tell me when this service returns 500". It stops being adequate the moment you need file integrity monitoring with attribution of which user or application modified a file, or software inventory correlated against CVE data, because those require an agent that understands the host rather than a process that forwards text.

Wazuh's own integration story also points outward. The README describes integration modules that pull security data from Amazon AWS, Azure and Google Cloud at the API level, plus rules to assess cloud configuration. That is a different posture from a cloud-native security tool that only sees its own provider: Wazuh is trying to be the place where several sources meet.

Maintenance, upgrades and what the repository tells you

The last push to the default branch was on 2026-09-21, and the repository is not archived, so the codebase is being worked on. The release list shows a pattern worth understanding before you pick a version: v4.10.5 was published on 2026-09-15, while v4.14.8-rc1 and v4.14.8-rc2 appeared on 2026-09-11 and 2026-09-18. Two release lines are receiving updates, and the 4.14 line is still at release-candidate stage. If you need stability, the maintenance release on the older line is the safer bet; if you need a feature that only exists in 4.14, you are accepting release-candidate risk.

The upgrade path is scripted rather than automatic. upgrade.sh sits at the top level next to install.sh, which means upgrades are something you run deliberately against components you have already inventoried. Plan for the agent fleet separately from the manager, because agents that lag the manager version are a common source of confusing behaviour.

On licensing, treat the NOASSERTION classification as a prompt to read the LICENSE file yourself. The README markets Wazuh as free and open source, and the repository carries a LICENSE file, but GitHub's classifier declining to name a licence means the terms are not a standard template it recognises. That is a question for your legal team if you intend to embed or resell it, and it is not a question this article can answer.

Editorial conclusion

Adopt Wazuh if you need on-premises log analysis, file integrity monitoring and vulnerability detection under your own control, and you have someone who can read rules and tune them. Do not adopt it expecting a single container to give you a finished security operations centre; the README describes an agent, a manager and an indexer as separate pieces, and the repository ships install.sh and upgrade.sh rather than a one-command deployment. Before committing, verify three things in your own environment: which agent platforms your fleet actually runs, how the manager handles your peak log volume, and whether the ruleset covers the applications you care about, since the ruleset directory is a maintained artefact you will be editing rather than a complete catalogue.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. wazuh/wazuh on GitHub