Wazuh is a security platform where agents on your hosts ship file integrity, log, vulnerability and compliance data to a central manager, an OpenSearch-derived indexer stores it, and a dashboard queries it. It replaces Splunk Enterprise Security, Elastic Security or a commercial endpoint detection console.
Our verdict on Wazuh#
Wazuh is genuinely free and genuinely enterprise-scale, and the second half is the problem in a homelab. The documented floor for the smallest deployment, 1 to 25 agents, is 4 vCPU and 8 GiB of RAM with 50 GB of disk for 90 days of retention. The Docker single-node stack asks for 8 GB on the host and will not start unless you set vm.max_map_count=262144 persistently. That is three containers, manager, indexer and dashboard, before you have monitored anything at all. What you get back is real: file integrity monitoring, log analysis against a large maintained ruleset, CVE detection against installed packages, and CIS benchmark scoring, all from one agent on each host. As of September 2026 the stable line is 4.14.x and 5.0 is still in beta pending a move to OpenSearch 3.x, so do not build on 5.0 yet. Budget an afternoon, and a retention policy on day one.
Who Wazuh is for#
Choose it if
- A small business that needs auditable file integrity monitoring and compliance evidence without a Splunk invoice.
- Anyone running more than about ten Linux or Windows hosts who wants one agent doing FIM, log collection and vulnerability detection.
- Homelabs with a spare 16 GB machine and real interest in security telemetry, not just an IP blocklist.
- Teams who need CIS, PCI DSS or GDPR reporting they can put in front of an auditor without building it themselves.
Look elsewhere if
- You have one server and want to stop SSH brute force. Use Fail2ban or CrowdSec; Wazuh is orders of magnitude more machine for that job.
- You have less than 8 GiB of RAM to dedicate. That is the documented minimum for the smallest supported deployment, not a comfortable target.
- You will not maintain index retention. Nobody is coming to trim the alert indices and the indexer will consume the disk.
What running it actually looks like#
Three containers in the single-node compose: wazuh.manager, wazuh.indexer and wazuh.dashboard. Before the first up you must run the certificate generation compose file, because all three speak mutual TLS and none will start without the generated PEM files mounted in. The host needs vm.max_map_count=262144 set persistently, or the indexer fails a bootstrap check and exits. The manager publishes 1514 for agent events, 1515 for enrollment, 1517, 514/udp for syslog and 55000 for its API; the indexer exposes 9200; the dashboard listens on 5601 and is usually mapped to 443. Agents enroll against 1515 and must then be kept within one minor version of the manager. Upgrades are ordered and not optional: indexer, then manager, then dashboard, then agents.
Resource profile#
- Memory
- 6144 MB idle, around 8192 MB in ordinary use. These are documented minimums, not observations. The quickstart asks for 4 vCPU and 8 GiB for 1 to 25 agents, and the Docker single-node stack asks for 8 GB on the host. The indexer JVM is most of it.
- CPU and acceleration
- 4 vCPU is the documented floor for the smallest deployment. The indexer dominates: ingestion, segment merges and any dashboard query spanning a wide time range. Vulnerability detection scans on the manager are periodic spikes on top of that.
- Storage growth
- The quickstart budgets 50 GB for 25 agents over 90 days and 200 GB for 100 agents. Alert indices are the growth, and without an index lifecycle policy the indexer will fill the disk and then refuse writes.
- Operational load
- 5 of 5, Project-grade. Three coupled services with their own TLS certificate authority that you generate before the first boot, a JVM heap to size, index lifecycle and retention to plan, agents that must track the manager version, and a 5.0 rewrite in beta while 4.14.x is what you actually run. This is a system you administer, not an app you install.
Figures describe a small single-household install and are the working assumptions behind our stack planner. Your numbers will differ with library size, user count and hardware. See methodology.
Data and backup surface#
Three separate things with three different methods. The manager's state is in the wazuh_etc, wazuh_queue, wazuh_api_configuration, wazuh_logs and wazuh_var_multigroups volumes; etc carries ossec.conf, your custom rules and decoders, and client.keys, which is the file you cannot lose without re-enrolling every agent. The indexer's wazuh-indexer-data volume holds the alert indices, which is where all the size is: use an OpenSearch snapshot repository rather than copying the directory, because a file copy of a running Lucene index restores as corruption. Keep the generated certificate directory from the compose tree too, since regenerating the CA means redistributing certificates to every component and agent.
Derived backup shape
Rebuildable index. Usually excluded and rebuilt after restore. Budget the reindex time in your recovery estimate.
Traps and surprises#
Certificates must exist before the first start
The Docker deployment ships a separate generate-indexer-certs.yml compose file that creates a root CA and per-component certificates. Run it first. If you go straight to docker compose up, all three services fail their TLS handshakes and log errors that look like network or credential problems. Keep the generated config/ directory with your backups: regenerating the CA later invalidates every deployed certificate at once.
vm.max_map_count on the host, not in the container
The indexer creates many memory-mapped areas and requires vm.max_map_count=262144. It is a kernel setting on the Docker host, so setting it inside the container does nothing, and setting it with sysctl -w alone means the indexer dies after the next reboot. Put it in /etc/sysctl.conf or a file under /etc/sysctl.d/. The failure mode is a container that exits during a bootstrap check.
client.keys is the agent trust store
Every enrolled agent has an entry in the manager's client.keys. Restore a manager without it and every agent is unknown: they stop reporting and each one has to be re-enrolled against port 1515, by hand or by script, on every host. It lives in the wazuh_etc volume. Treat it as a credential file, back it up separately from the bulk telemetry, and keep it out of anything you share.
Retention is not configured for you
Alerts index continuously and nothing ages them out by default. The quickstart's storage table assumes 90 days, but that is a budgeting figure, not an enforced policy: you have to create an index state management policy that rolls over and deletes old alert indices. Without one, the indexer fills the disk, flips indices to read-only, and stops accepting events while the dashboard keeps looking healthy.
5.0 is beta and agents must match the manager
In September 2026 the stable line is 4.14.x while 5.0.0 beta builds are published alongside it, headed for OpenSearch 3.x. Do not deploy a 5.0 beta as a production manager. Separately, agents and manager must stay within one minor version: upgrading the manager and leaving agents behind produces silent gaps in coverage rather than a clear error, so plan agent rollout as part of every upgrade window.
Specifications#
- Category
- Security and update hygiene
- Licence
- GPL-2.0 (Copyleft)
- Written in
- C / C++ / Python / Java
- First release
- 2015
- Maturity
- Mature
- Datastore
- Wazuh indexer, a fork of OpenSearch 2.x
- Default ports
443,514,1514,1515,1517,9200,55000- Ships as
- deb/rpm package (all-in-one installer), docker compose, kubernetes, OVA virtual appliance
- arm64 builds
- Yes
- Identity
- OIDC via plugin. SAML single sign-on to the dashboard through the indexer's security plugin, with documented setups for Entra ID, Okta, Keycloak and authentik; the docs cover SAML rather than OIDC.
- Replaces
- Splunk Enterprise Security, Elastic Security, Microsoft Defender for Endpoint, AlienVault OSSIM
- Project site
- wazuh.com
- Source
- github.com/wazuh/wazuh
- Documentation
- documentation.wazuh.com
Alternatives to Wazuh#
Everything else in security and update hygiene, closest in operational weight first.
| Tool | Ops load | Idle RAM | Licence |
|---|---|---|---|
| CrowdSec | 2, Light | 120 MB | MIT |
| Fail2ban | 2, Light | 40 MB | GPL-2.0-or-later |
| Watchtower | 2, Light | 15 MB | Apache-2.0 |
| Diun | 1, Set and forget | 25 MB | MIT |
Sources#
Facts on this page were checked against the project's own material. Where a number is our own estimate rather than a published figure, the text says so.
Published . Last reviewed . Found something out of date? Tell us and we will fix it and log the change.