Wazuh quickstart works initially but dashboard loses events over time on small single-node setup (disk pressure?)

[Gabriele Ventura]

Hi everyone,

I’m looking for an engineering-level perspective on Wazuh stability in small, single-node environments, rather than general documentation pointers.

Over the past months I’ve been working extensively on hardening and securing a very small number of servers (currently a public Zimbra mail server and a web server). As part of this work, I evaluated Wazuh because on paper it looked like an excellent fit: mature agents, solid HIDS capabilities, FIM, audit, and a unified dashboard.

In practice, however, my experience has been consistently fragile, despite careful and repeated attempts.

What I tried

- Quite systematically, I tested:

- native all-in-one installations

- native installations with manager / indexer / dashboard separated

- Docker-based deployments

different versions (4.11, 4.12, and recently 4.14)

- minimal configurations and more “complete” ones

- clean hosts and full reinstallations

The only installation that worked correctly at first was the official quickstart (all-in-one installation script).

However, even in that case, after some real usage, the same issues would eventually appear:

- the dashboard suddenly showing no events (“No results match your search criteria”)

- filters becoming stuck or non-removable

intermittent authentication / 401 issues without an obvious cause

- OpenSearch entering inconsistent states (security index issues, read-only indices, flood-stage disk watermark, etc.)

In other words, the system appeared to be running correctly:

agents continued to generate alerts (clearly visible via CLI on the manager, e.g. alerts.json), but the dashboard became effectively blind or unusable.

My impression is that the quickstart provides an initially coherent setup, but one that is very fragile under disk pressure, especially on “honest” but non-enterprise hardware.

Observed outcomes with other installation methods

With non-quickstart deployments, the end result was usually one of the following, sooner or later:

- Wazuh manager or indexer failing to start

- OpenSearch entering flood-stage / blocked states

- the dashboard becoming empty or broken

- credential issues that are difficult to interpret

- APIs rejecting authentication even when all services appear to be running

Environment details

To be explicit, this is the actual environment, not a lab with heavy load:

- Deployment type: single-node, all-in-one

- OS: Ubuntu 24.04 LTS

- CPU: 4 vCPU

- RAM: 8 GB

- Disk: 38 GB (root filesystem)

- Number of agents: 2–3

      one Zimbra mail server

      one web server

- Traffic / EPS: very low

- Goal: HIDS-style monitoring, not a full SOC/SIEM

Main difficulty

The most frustrating part has not been troubleshooting itself (that’s expected), but rather that:

- the official documentation is very rich in features, but quite poor in practical operational guidance

- there is little explanation of what not to do in small environments

- I could not find a clear, officially supported path for running Wazuh purely as a lightweight HIDS, without effectively turning it into a fragile mini-SIEM

My overall impression is that Wazuh is a powerful platform, but one primarily designed for SOC environments with dedicated teams, rather than for a single system administrator monitoring a handful of servers in a sustainable way.

Actual question

At this point I’m trying to understand whether what I’m observing is:

- a known limitation / failure mode of the all-in-one deployment under disk pressure

- or a misconfiguration on my side, despite multiple clean installs

So my questions are:

- Do you run (or recommend running) Wazuh in small, single-node environments like this?

- Are there rules of thumb or internal best practices (e.g. modules to always disable, retention limits not to exceed, known warning signs)?

- Is there an officially supported way to run Wazuh primarily as a lightweight HIDS (log analysis + FIM + basic visibility) without the dashboard and indexer becoming unstable over time?

I’m not looking for marketing material or links to the general documentation (which I’ve read multiple times), but rather real-world field guidance — or, very honestly, even a confirmation that this is not the intended use case.

My goal is sensible, maintainable security, not “making Wazuh work at all costs”.

Thanks in advance for any insight you’re willing to share.

Best regards,

Gabriele

[Natalia Castillo]

Hi Gabriele,

Thanks for the detailed context and for raising this question so clearly. You’re touching on an important architectural and operational aspect of Wazuh, and I want to make sure the answer is accurate and properly reflects both the product design and real-world behaviour.

I’m reviewing this in more depth and will follow up shortly with a more comprehensive response that clarifies the supported methods for running Wazuh in a lightweight HIDS-focused setup, while maintaining stability for the indexer and dashboard over time.

I appreciate your patience, and thank you again for the thoughtful analysis.

Best regards,
Natalia

[Gabriele Ventura]

Hi Natalia,

I hope you’re doing well.

I just wanted to follow up on your message from January 6th, where you mentioned you were reviewing this topic in more depth and would come back with additional clarification.

I completely understand that this kind of analysis takes time, especially when it touches architectural and support considerations. I’m only checking in to see whether you had any further insights, or if there’s any additional information from my side that could be useful.

This question is still quite relevant for me, as I’m trying to decide whether to continue investing in a Wazuh-based setup for a small, HIDS-focused environment, or to reconsider the approach based on the officially supported use cases.

Thanks again for taking the time to look into this, and for your initial thoughtful response.

Best regards,

Gabriele

--
You received this message because you are subscribed to the Google Groups "Wazuh | Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/wazuh/8ce0ae00-fbb2-414d-9625-f0673bf30b69n%40googlegroups.com.

[Natalia Castillo]

Hi Gabriele,

Based on what you outlined, this behaviour is expected in small, single-node Wazuh deployments and is not the result of a simple misconfiguration.

In an all-in-one setup, the Wazuh Manager, OpenSearch, and Dashboard share the same disk and memory. When disk usage approaches OpenSearch watermarks, indices are automatically set to read-only and eventually blocked at flood stage. At that point, the manager continues to generate alerts (visible in alerts.json), but OpenSearch stops accepting new data. The dashboard then becomes empty or unstable, filters can break, and intermittent 401/authentication issues may appear. This behaviour is tied directly to OpenSearch disk-protection mechanisms.

The official requirements describe minimum installation values, but in practice, a stable all-in-one deployment requires significantly more disk and memory headroom than the documented minimums, due to OpenSearch disk watermarks and JVM memory behaviour.

For an all-in-one deployment, the documentation indicates 4 vCPU, 8 GB RAM (minimum), and disk space that “depends on data retention.” These are installation minimums, not stability guarantees. On a 38 GB root filesystem, 85% usable space is roughly 32 GB. After the OS, logs, and packages consume around 8–12 GB, the OpenSearch data path is left with ~20 GB or less. That margin is not sufficient for alert indices, security plugin indices, dashboard saved objects, segment merges, and translog growth. This is why, in practice, 50–100 GB is the real lower bound for stable operation, even at very low EPS.

Wazuh can run in small environments, but only with strict operational limits. Index growth must be controlled using Index State Management with short retention periods; without this, instability over time is unavoidable.
https://documentation.wazuh.com/current/user-manual/wazuh-indexer-cluster/index-lifecycle-management.html

Additionally, modules not required for the intended use case (for example, vulnerability detection, cloud integrations, or very broad FIM paths) should be disabled to reduce index churn and disk pressure.

Regarding your specific question about running Wazuh primarily as a lightweight HIDS while maintaining stability over time for the dashboard and indexer: the short answer is that this is supported, but it is achieved operationally rather than architecturally. It requires intentionally limiting enabled features, data volume, and retention so the indexer and dashboard remain within safe resource boundaries. I want to dig a bit deeper into this point to give you a more precise and complete answer that clearly distinguishes what is officially supported versus what is only possible in practice.

I’ll follow up shortly with a more detailed response focused specifically on that question.