Wazuh single-node vs multi-node deployment

The indexer is the component that grows with your estate, so the storage estimate decides whether a single host or a multi-node cluster is realistic. The Wazuh indexer installation guide estimates 90 days of alerts at about 3.7 GB per server, 1.5 GB per workstation and 7.4 GB per network device. Multiply each figure by the number of devices in that class and add the results to size the indexer's disk.

Illustrative example: 80 workstations, 10 servers and 10 network devices produce about 231 GB of indexed alerts over 90 days using the documented per-device figures. That total is roughly 120 GB for workstations, 37 GB for servers and 74 GB for network devices, so the mix matters more than the headcount. Note that this is a planning estimate from the guide, not a measured result, and it will not match your disk once index replicas, snapshots, overhead and free-space headroom are added. Also compare it with the sizing in the quickstart, which allots 50 GB for 1 to 25 agents and 200 GB for 51 to 100 agents, so a 100-agent estate with many network devices can exceed the quickstart figure.

Four inputs change the number. Retention moves it directly, so a 180-day requirement roughly doubles the 90-day total if the same ingest continues. Alert volume varies widely with rule tuning, file integrity monitoring scope and noisy log sources, and the per-device figures assume a typical load you must check. Endpoint mix shifts the total because network devices carry the largest per-device estimate. Finally, the cluster design adds replica copies that consume extra space. Ask Wazuh to confirm the assumptions behind each figure and whether replica settings are included. Then measure alerts per agent per day during a two-week pilot on your own endpoints and extrapolate to your retention target before buying disks or hosts.

High availability justifies a distributed Wazuh deployment when losing the single host would stop detection for your estate and you have the staff to keep a cluster healthy. The Wazuh server cluster documentation describes horizontal scalability and high availability, but those properties come from adding hosts, and each host adds patching, certificates, monitoring and backups. Before committing, count what the extra hosts cost: at least a master and one worker on the server side, plus indexer nodes. The Wazuh indexer installation guide lists 4 GB RAM and 2 CPU cores as the minimum per indexer node and 16 GB RAM and 8 CPU cores as recommended, so a cluster sized to the recommendation costs far more hardware than the 8 GiB all-in-one host in the quickstart. Ask your infrastructure team for a quote on that node count and confirm the sizing with Wazuh before procurement.

The trade-off has a manual step that many teams underestimate. The server cluster documentation states that changes to ossec.conf on the master are not synchronized to workers and must be replicated by hand. Shared configuration groups, custom rules, decoders, SCA policies and CDB lists are managed on the master, so a missed change on a worker can leave agents processing events differently from one node to another. Build a written runbook for that replication, assign an owner, and test failover in a non-production copy. A network load balancer can spread agent connections across server nodes, but it does not remove this drift risk, so confirm how your change process will verify every node after each edit.

Clustering favors you when the estate is large enough that one host is a real bottleneck, when agent downtime during a host failure is unacceptable to your SOC, and when you already run clustered services and have people who can operate them. It does not favor you for a few dozen endpoints where the quickstart fits, for a team that cannot staff routine cluster maintenance, or for a pilot. In those cases, a well-backed-up single host with a tested restore procedure often gives better protection per hour of effort. Also note that the pre-built OVA does not provide high availability out of the box, so an OVA deployment should not be treated as a resilient platform.

In a single host deployment, the recurring work is patching one machine that runs the indexer, server and dashboard together, so a planned window covers every component at once. In a distributed deployment, the same patch cycle repeats for each indexer node, each server node and the dashboard, and the order matters. The master node handles agent registration and deletion and shared configuration, so it should be upgraded and verified before the workers. Expect ossec.conf changes on the master to be copied to workers by hand, since the Wazuh server cluster documentation says they are not synchronized automatically. Keep a written checklist of every node and every file that must match, and verify it after each change.

Indexer health becomes an ongoing duty once the cluster has several nodes. Someone should watch cluster status, shard allocation and disk headroom on each indexer node, because the indexer installation guide sizes a single deployment at about 231 GB for 80 workstations, 10 servers and 10 network devices, and that figure grows with retention. Backup planning also changes shape. Snapshots of the indexer, the server configuration and the custom rules, decoders and CDB lists must be tested with a restore, not just taken. Confirm with Wazuh which snapshot method and restore path apply to your version before you commit to a schedule.

The release cadence is a reason to plan upgrade windows early. Wazuh shipped 4.14 patch releases on 17 March, 23 April, 1 July, 29 July, 23 September and 14 October 2026, and a Wazuh 5.0.0 release candidate was published on October 5, 2026. A major version change can alter the upgrade path, so treat 5.0.0 as a planning item rather than a routine patch. Before you commit to either model, ask Wazuh to confirm the supported upgrade path from your current 4.14 release, the order of node upgrades in a cluster, and whether a rollback is supported. Record those answers in the runbook.