Wazuh 5.0 system requirements split three ways: an operating system list that is much shorter than it was, a CPU and RAM floor per component, and a disk number you have to calculate yourself. The central components run on Amazon Linux 2023, Ubuntu 24.04 or 26.04, and Red Hat Enterprise Linux 9 or 10, on 64-bit Intel, AMD or ARM. The manager wants 8 GB and 4 cores as a minimum, the indexer the same, the dashboard 4 GB and 2 cores. Disk is the number that goes wrong, so most of this lesson is about disk.

What you need

Which operating systems are supported

For the central components, the list is short and enforced by the installation assistant:

  • Amazon Linux 2023
  • Ubuntu 24.04, 26.04
  • Red Hat Enterprise Linux 9, 10

Architecture must be 64-bit: x86_64/AMD64 or AARCH64/ARM64. ARM is a first-class option here, which matters if you are sizing on cloud instances where ARM is cheaper per core.

The agent list is far broader and includes Debian 10 to 13, CentOS 7 and CentOS Stream 8 to 10, Fedora 41 to 43, openSUSE Leap 15 and 16, Windows and macOS. Check the packages list for the exact set before you promise coverage for an old estate.

CPU and RAM per component

These are the documented figures, per node.

Component Minimum RAM Minimum cores Recommended RAM Recommended cores
Wazuh manager 8 GB 4 16 GB 8
Wazuh indexer 8 GB 4 32 GB 8
Wazuh dashboard 4 GB 2 8 GB 4

The indexer’s recommended figure is the one to take seriously. It is OpenSearch, it wants heap, and heap wants RAM. The manager is CPU-bound during normalisation and the dashboard is mostly idle until an analyst opens a heavy visualisation.

For an all-in-one install, the quickstart gives a combined table instead:

Agents CPU RAM Storage (90 days)
1-25 4 vCPU 8 GiB 50 GB
26-50 8 vCPU 16 GiB 100 GB
51-100 8 vCPU 16 GiB 200 GB

An all-in-one deployment is documented as usually enough for up to 100 endpoints with 90 days of queryable data. Above that, move to a distributed deployment.

How much disk does the manager need?

Less than you would expect from 4.x, and for an interesting reason: the manager no longer stores alerts. It stores the content and databases its own modules need.

The documented floor is at least 20 GB, driven by the vulnerability scanner feed, which on its own requires at least 15 GB. If you disable vulnerability detection you can go lower, but 20 GB is cheap insurance and the feed is one of the better reasons to run Wazuh at all.

How much disk does the indexer need?

Here is the official per-agent estimate for 90 days of events:

Monitored endpoint type Events per second Indexer storage, GB per 90 days
Servers 0.25 3.7
Workstations 0.1 1.5
Network devices 0.5 7.4

The documentation’s own worked example: 80 workstations, 10 servers and 10 network devices needs 231 GB for 90 days. Check the arithmetic, because being able to reproduce it is what lets you adapt it.

workstations : 80 x 1.5 GB =  120 GB
servers      : 10 x 3.7 GB =   37 GB
network      : 10 x 7.4 GB =   74 GB
                             ------
                              231 GB

Deriving the per-event size

Those per-agent numbers are just events per second turned into bytes. Unpick one of them:

0.25 events/sec x 86,400 sec/day          =  21,600 events/day
21,600 events/day x 90 days               = 1,944,000 events
3.7 GB / 1,944,000 events                 ≈ 1.9 kB per stored event

Do the same for workstations and network devices and you get the same answer, about 1.9 kB of indexer storage per event after compression. That constant is the useful part, because it turns any volume estimate into a disk number:

disk_GB = EPS x 86,400 x retention_days x 1.9 kB

For 500 EPS kept for 30 days, that is 500 × 86,400 × 30 × 1.9 kB, which is roughly 2.5 TB before replicas. Add a replica and double it. Add 20% headroom for merge and translog space and you are at about 6 TB of provisioned storage. Numbers like that are why sizing conversations should happen before hardware is ordered, not after.

The retention default that changes everything

The per-agent table above assumes you are keeping events for 90 days. Out of the box, Wazuh 5.0 does not.

The Setup plugin creates Index State Management policies with these default retention periods. These were read back from a 5.0.0-beta5 stack, so the numbers are confirmed rather than quoted:

ISM policy Data stream Default retention
stream-raw-events-policy wazuh-events-raw-v5 10 minutes
stream-events-policy wazuh-events-v5-* 1 hour
stream-findings-policy wazuh-findings-v5-* 90 days
stream-active-responses-policy wazuh-active-responses 3 days
stream-metrics-policy wazuh-metrics-* 30 days
ai-assistant-sessions-policy wazuh-ai-assistant-sessions 1 day, then 7 days

Every one of those policies also carries a rollover condition of 200 million documents, alongside the primary shard size condition the documentation describes.

So there are two very different deployments hiding behind one product. In the default configuration, every event is indexed but almost immediately deleted, the events streams stay small, and your 90-day footprint is findings plus the state indices. If you extend event retention to satisfy a log retention requirement, the per-agent table applies and your disk requirement jumps by an order of magnitude.

Decide which of those you are building before you size it, and write the decision down. The retention and backup lesson covers changing the policies, and the underlying mechanism is documented in the OpenSearch Index State Management guide.

Measure your own event volume

Every estimate above is a placeholder for a measurement. Once you have the stack running with a representative sample of agents, measure for a week and re-size.

Total size on disk per data stream, from Dev Tools on the dashboard or over the indexer API:

curl -k -u admin "https://<WAZUH_INDEXER_IP>:9200/_cat/indices/.ds-wazuh-*?v&bytes=mb&s=store.size:desc"

That lists the backing indices behind each data stream with their document counts and store size. Note that a data stream is a set of backing indices whose names begin with .ds-, so a plain wazuh-* pattern will not show them.

Document counts over a fixed window give you events per second. Take the count once, wait a known interval, take it again:

curl -k -u admin "https://<WAZUH_INDEXER_IP>:9200/_cat/count/wazuh-events-v5-*?v"

Divide the difference by the elapsed seconds. Do it at the busiest hour of the working day, not at 03:00, and do it again after you onboard a noisy source such as Windows event channels or a cloud audit trail. Those two sources routinely double a deployment’s volume on their own.

A sizing worksheet

Work through these in order. Each answer feeds the next.

  1. Count endpoints by type. Servers, workstations, network devices, cloud accounts. Cloud log sources are not endpoints and need estimating separately from their own volume.
  2. Estimate EPS. Use 0.25, 0.1 and 0.5 per endpoint type as a first pass, then replace with measurements.
  3. Decide event retention and findings retention separately. They are different policies and usually different requirements.
  4. Apply the formula. EPS × 86,400 × days × 1.9 kB.
  5. Multiply for replicas. One replica doubles it. A single-node indexer has none, which is also a resilience decision.
  6. Add 20 to 30% headroom. Merges, translogs, and the fact that your estimate is wrong.
  7. Size RAM for the indexer against the recommended figure, not the minimum, if the deployment will hold more than a few weeks of data.
  8. Re-measure after a month. Every one of these numbers moves.

If the answer comes out larger than one host can carry, the next decision is where to split. Separating the indexer from the manager buys the most, because they contend for different resources. The performance tuning lesson covers heap, shards and where the pipeline actually bottlenecks.

Common errors

Cause: the installation assistant checks CPU count and available RAM before an all-in-one install and found less than 4 cores or roughly 8 GB. Fix: resize the host. This is a warning, not a failure, so the install proceeds and the symptoms appear later as indexer instability or a dashboard that times out.

The current system does not match with the list of supported systems. The installation may not work properly.

Cause: the operating system is not one of Amazon Linux 2023, Ubuntu 24.04 or 26.04, or RHEL 9 or 10. The assistant also prints the supported list. Fix: use a supported release. Installing anyway is possible and unsupportable.

Uncompatible system architecture: <ARCH>. Supported any 64-bit system

Cause: a 32-bit host. The message is spelled exactly that way in the assistant, misspelling included, which is useful to know when you are searching logs. Fix: 64-bit only, x86_64 or AARCH64.

The indexer stops accepting writes and the dashboard shows no recent data

Cause: the disk hit the cluster’s flood-stage watermark and OpenSearch applied a read-only block to the affected indices. Symptom is that ingest stops while search still works, which is why it often goes unnoticed for hours. Fix: free space or extend the volume, then clear the block. Prevent it by alerting on indexer disk usage, which nobody does until the first time it happens.

Disk fills far faster than the estimate

Cause: usually one of three things. Event retention was extended without re-sizing; a very verbose source was onboarded; or unclassified event indexing was turned on for a space, which stores events that could not be categorised into wazuh-events-v5-unclassified. Check the per-index sizes with the _cat/indices call above before you blame the model.

Where to read the primary source

Per-component hardware figures come from the installation guide pages for the Wazuh indexer, the Wazuh manager and the dashboard. The all-in-one table is on the quickstart page, and the retention defaults are in the Wazuh indices reference. All of it is beta documentation as of September 2026, and sizing guidance is one of the things most likely to be revised at general availability.

Next: Install Wazuh on Ubuntu step by step.

Frequently asked questions

What are the minimum requirements for Wazuh?

For an all-in-one lab covering up to 25 agents, the quickstart asks for 4 vCPU, 8 GiB of RAM and 50 GB of storage for 90 days of data. Per component, the documented minimums are 8 GB and 4 cores for the manager, 8 GB and 4 cores for the indexer, and 4 GB and 2 cores for the dashboard.

Which operating systems does Wazuh 5.0 support?

For the central components, Amazon Linux 2023, Ubuntu 24.04 and 26.04, and Red Hat Enterprise Linux 9 and 10, on 64-bit Intel, AMD or ARM processors. The agent supports a much wider list, including older Debian, CentOS, Fedora, SUSE, Windows and macOS releases.

How much disk space does Wazuh need per agent?

The official estimate for 90 days of events is 3.7 GB per server, 1.5 GB per workstation and 7.4 GB per network device, based on 0.25, 0.1 and 0.5 events per second respectively. That works out to roughly 1.9 kB of indexer storage per stored event.

Does Wazuh 5.0 need more disk than 4.x?

It indexes every event rather than only alerts, so the write volume is much higher. Whether the stored volume is higher depends on retention. The shipped lifecycle policies keep raw events for 10 minutes and normalised events for one hour, while findings are kept for 90 days, so out of the box the long-term footprint is findings plus state indices.

Can I run the Wazuh manager and indexer on the same server?

Yes, and that is what the quickstart does. It is documented as suitable for up to 100 endpoints with 90 days of queryable data. Past that, separate the components before you cluster them, because the indexer and the manager compete for very different resources.