Wazuh: A Self-Hosted SIEM for the Home Lab (Is It Worth the RAM?)

A SIEM — Security Information and Event Management — is the thing big companies pay six figures a year for so that a roomful of analysts can stare at dashboards and catch the moment something goes wrong. The pitch is simple: pull logs from everything you own into one place, correlate them, and raise an alert when the pattern smells like an attack. The reality, for most of those companies, is a very expensive log bucket nobody reads.

So why would a homelab want one? Because the same machinery that overwhelms an enterprise can, at small scale, actually give a single tinkerer something genuinely useful: a single pane that tells you when one of your boxes has been poked at, modified, or logged into by someone who shouldn’t be there. Wazuh is the open-source SIEM I keep coming back to, and the question that matters isn’t “is it good” — it is — but “is it worth the resources it demands?”

That framing matters because a homelab is a zero-sum machine. Every gigabyte Wazuh eats is a gigabyte not running something else, and unlike a company you are not buying more capacity with someone else’s budget. The honest question is always what you are giving up, not just what you are gaining — the same trade-off calculus I apply to any resource-hungry service, and the reason I am sceptical of the “just add more hardware” reflex I wrote about in the home-lab upgrade trap.

What Wazuh actually gives you

Wazuh started life as a fork of OSSEC and grew into a full platform. You run a manager (the brain), it ships with an indexer and a dashboard (a fork of OpenSearch and its dashboards), and you install lightweight agents on the machines you want to watch. The agents send events up; the manager runs them through rules and decoders; the dashboard shows you what came out. It is a classic hub-and-spoke design, and the agents are genuinely light — a well-behaved agent barely registers on the host it watches, sipping a few megabytes of memory and a sliver of CPU. That asymmetry is deliberate and worth understanding: you can instrument a dozen small boxes without slowing any of them down, because all the expensive correlation happens centrally. It is the central stack, not the agents, that costs you the RAM.

Out of the box, without you writing a single rule, it does a surprising amount:

• File Integrity Monitoring (FIM) — it watches sensitive paths and tells you the instant /etc/passwd, an SSH config, or a web root changes.
• Log analysis — it parses auth logs and flags brute-force attempts, sudo abuse, and suspicious logins.
• Vulnerability detection — it cross-references installed packages against CVE feeds and tells you which of your boxes is running something with a known hole.
• Security Configuration Assessment — it runs CIS-benchmark-style checks and scores how hardened each box is.

The FIM piece alone justified the install for me. Knowing within seconds that a config file changed on a server I wasn’t touching is the kind of signal you don’t appreciate until the one time it isn’t a false alarm. Everything else is a bonus.

Where it sits in a monitoring stack

It is worth being clear about what Wazuh is not. It is not an uptime checker and it is not a metrics dashboard. If your question is “is the service up and responding,” a lightweight tool like Uptime Kuma answers it for a fraction of the resources, and the two live happily side by side — Uptime Kuma tells you what broke, Wazuh helps you understand whether someone made it break. Confusing security monitoring with availability monitoring is a common mistake, and running Wazuh to check whether your website is up would be like using a submarine to cross a puddle.

Wazuh’s job is detection: unexpected file changes, authentication anomalies, configuration drift, known-vulnerable packages. That is a different question from “is it working,” and it needs different, heavier machinery to answer.

The RAM question, answered honestly

Here’s the part the glossy docs are coy about. Wazuh is not light. The indexer is a JVM-based search engine, and JVM-based search engines are hungry. The official guidance for an all-in-one deployment starts around 4GB of RAM, and that is a floor, not a comfortable cruising altitude. Give it 8GB and you’ll have a better time. Try to run it in 2GB and you’ll spend your evenings watching the indexer get OOM-killed and restart in a loop.

That’s a real cost in a homelab where RAM is the scarce resource and every other container is also “just a couple of gigs.” A docker-compose stack for the single-node setup looks innocent enough:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

services:
  wazuh.manager:
    image: wazuh/wazuh-manager:4.x
    ports: ["1514:1514", "1515:1515", "55000:55000"]
  wazuh.indexer:
    image: wazuh/wazuh-indexer:4.x
    environment:
      - "OPENSEARCH_JAVA_OPTS=-Xms2g -Xmx2g"   # this line is the RAM tax
  wazuh.dashboard:
    image: wazuh/wazuh-dashboard:4.x
    ports: ["443:5601"]

That -Xmx2g is doing exactly what it says: handing two whole gigabytes to the search engine’s heap, before you have indexed a single log line. Budget accordingly. On a Raspberry Pi, forget it — the architecture and the memory both fight you. On a NUC or a repurposed mini-PC with 16GB, it is a reasonable lodger that leaves room for other services.

Living with it day to day

Once it is up, the agent install is pleasantly boring — a package, a config pointing at the manager, and an enrollment key:

1
2

WAZUH_MANAGER="10.0.0.10" apt install wazuh-agent
systemctl enable --now wazuh-agent

The dashboard is dense. There is a lot of it, and the default alert noise is real — you will spend the first week tuning rules, suppressing the chatter from your own legitimate behaviour, and deciding which alert levels actually mean “wake me up.” This is the universal SIEM tax: the value is entirely in the tuning, and a SIEM you don’t tune is just a very heavy log viewer. The decoders and rules are XML, which is exactly as much fun as it sounds, but they are well documented and you rarely need to touch the internals for a homelab.

What tuning actually looks like

“Tune your rules” is easy advice to give and vague to follow, so here is what it means in practice. Wazuh assigns every alert a level from 0 to 15; out of the box it fires on a huge range of them, most of which are noise generated by your own perfectly legitimate activity. The work is deciding a threshold — say, “only alert me on level 10 and above” — and then adding targeted exceptions for the handful of lower-level events that genuinely matter to you and the higher-level ones that don’t.

A concrete example: Wazuh will happily alert every time you run sudo. On a box where you sudo fifty times an evening, that is fifty alerts a night, and within a week you have trained yourself to ignore the entire category — which is exactly the failure a SIEM is supposed to prevent. The fix is a local rule that suppresses sudo from your own admin account while still flagging it from any other account. That one exception turns a firehose into a signal. You repeat this pattern across every noisy source until what is left is only events you would actually want to be woken for.

Active response, and why to be careful with it

Wazuh can do more than watch — it can react. The active response feature lets the manager tell an agent to run a command when a rule fires: block an IP in the firewall after repeated failed logins, kill a process, disable an account. On paper this is brilliant automated defence. In practice, on a homelab, it is a foot-gun you should approach slowly.

The problem is false positives. An automated block that fires on a misfired rule can lock you out — of SSH, of the dashboard, of the very box you were trying to protect — usually at the least convenient moment. My advice is to run Wazuh in pure detection mode for a good while first, learn what your normal traffic looks like, and only enable active response on narrow, high-confidence rules once you trust the tuning. Automated defence is only as good as the rules behind it, and early on those rules do not yet know your environment.

Troubleshooting: the problems everyone hits

The indexer keeps getting OOM-killed. This is the RAM floor biting. Either give the host more memory or lower the -Xmx heap — but drop it too far and search grinds to a halt. There is no free lunch here; the indexer needs what it needs, and the honest fix is more RAM, not a smaller heap.

Agents show as “never connected.” Nine times out of ten this is the enrollment port (1515) or the event port (1514) being blocked between agent and manager. Confirm both are open, and remember these are exactly the kind of internal ports a segmented network will block by default — check your firewall before you blame Wazuh.

vm.max_map_count errors on startup. The OpenSearch-derived indexer needs the host kernel setting raised (sysctl -w vm.max_map_count=262144, made permanent in sysctl.conf). This trips up almost everyone on their first run, and the error message is not obvious about the cause.

The dashboard is drowning you in alerts. This is not a bug, it is the untuned default state. Work through the rule levels, suppress the noise from your own admin activity, and raise the threshold for what pages you. A SIEM screaming about everything is worse than no SIEM, because you learn to ignore it.

Vulnerability scan results look stale. The CVE feeds update on a schedule; if detection looks out of date, confirm the manager can actually reach the feed sources. On a locked-down network that outbound path may be blocked.

The verdict

Is it worth the RAM? It depends brutally on what you are protecting. If your “homelab” is a single Pi running Pi-hole, no — Wazuh will eat the machine and tell you things you could have learned from journalctl. If you run several boxes, expose anything to the internet, or simply want to learn how real detection engineering works on hardware you control, then yes, comfortably. The FIM and the SSH brute-force alerting earned their keep for me within a fortnight.

Who is this for? The homelabber who has outgrown “I’ll check the logs if something feels off” and wants to be told before it feels off — and who has 8GB of RAM to spare and an evening to tune the noise down. If you have neither the memory nor the patience, a lighter monitoring setup will serve you better and you should not feel bad about it. But if you do, it is a real SIEM, given away for free. The price isn’t money. It is memory, and your attention.