Wazuh SIEM on a Budget: Pi, N100 or Cloud

Wazuh SIEM on a budget runs happily on hardware you can buy for under 100 EUR, or rent for under 10 EUR a month, even though the sales deck wants you on a fat cluster. I run it both ways at home, so I picked the cheapest box that genuinely works for the three people I keep running into. The home tinkerer. The sysadmin babysitting one office. And the road warrior whose agents live everywhere except the LAN. You get the exact wazuh-install.sh command for each, plus where the wall is so you know the second it stops being a deal. Everything here ran on one rig: Wazuh 4.10 single-node bundle, Ubuntu 24.04 LTS, dashboard over HTTPS.

Wazuh sells itself as enterprise SIEM. The sales deck wants you on a fat cluster. What the deck skips: that same all-in-one installer runs happily on hardware you can buy for under 100 EUR, or rent for under 10 EUR a month. I run it both ways at home. So I picked the cheapest box that genuinely works for the three people I keep running into. The home tinkerer. The sysadmin babysitting one office. And the road warrior whose agents live everywhere except the LAN. You get the exact wazuh-install.sh command for each, plus where the wall is so you know the second it stops being a deal. Everything here ran on one rig: Wazuh 4.10 single-node bundle, Ubuntu 24.04 LTS, dashboard over HTTPS, somewhere between 10 and 80 agents beating on it the way real life does.

Why Wazuh on a budget actually works

Why does it fit? The single-node "all-in-one" installer normally spreads across three machines. The Indexer (a fork of OpenSearch), the Manager, the Dashboard. It stacks all of them on one host instead. With 10 agents reporting in, the thing idles around 2.4 GB of resident memory. Push it to 80 agents under normal load and you're looking at roughly 4.5 GB. CPU spikes once a day, every morning, when the rule base reloads. Then it falls back under 15 % on a four-core chip and just sits there. Easily within reach of a Raspberry Pi 5 8 GB or an Intel N100 mini-PC, and the cheapest ARM node Hetzner will rent you handles it too. None of these is a serious server. They all run the stack fine anyway.

It gets interesting later, and it comes down to two questions. How long do you keep logs, and do you want Suricata in the mix? Want 90 days of hot logs and an inline IDS? Skip down to Path B, you'll thank me. Fine with 14 days and no IDS? Then honestly, Path A or Path C answer that without a single asterisk.

Sizing it right: how many agents per Watt

That "peak agents" column. It isn't a brick wall. It's where the Indexer starts quietly dropping events, because the JVM heap ships set conservatively and the bulk write queues back up on you. And nobody warns you. You just notice the gaps in your timeline weeks later. So leave yourself room. I plan for half the stated peak in steady state and keep the rest as headroom for when an alert storm hits and every box reports at once.

Path A, Raspberry Pi 5 (~95 EUR)

This is the one I hand to anyone learning the ropes. Home labs. A course you're slogging through. The handful of agents under one roof.

What you're buying: Pi 5 8 GB (75 EUR) + NVMe HAT + 64 GB NVMe (28 EUR for the pair) + the 27 W official PSU (12 EUR) + a passive case (10 EUR), which lands at 95 EUR. Do not put this on an SD card. Booting off NVMe is the single biggest reliability win you'll get on a box that never powers down, and it's cheap insurance. Flash Ubuntu 24.04 LTS ARM64 onto the NVMe with rpi-imager, set the hostname to wazuh-pi, and drop your ssh keys in at first boot so you're not typing a password later. Once SSH answers:

sudo apt update && sudo apt install -y curl gnupg
ssh-copy-id wazuh-pi.local   # from your laptop
# enable cgroup v2 memory accounting (Wazuh installer requires it on ARM)
sudo sed -i 's/$/ cgroup_enable=memory cgroup_memory=1/' /boot/firmware/cmdline.txt
sudo reboot

Saying it twice because it matters: do not run Wazuh on a Pi off an SD card. The Indexer writes to disk nonstop. An SD card gives up in 6-9 months, and I've killed two this way already so you don't have to. NVMe HAT or USB SSD. No exceptions.

Path B, N100 mini-PC (~180 EUR)

If I were spending my own money to put a Wazuh box in an office, this is the one I'd grab. It suits a small-shop sysadmin who wants an "office Wazuh box" that just sits there and works. It also covers a lab where you want Suricata plus a full 90 days of retention.

Grab any Intel N100 unit that ships with 16 GB of RAM and a 256 GB or 500 GB NVMe. A Beelink S12 Pro does the job. So does a GMKtec NucBox G3, or a Minisforum UN100, and they're close enough on price that I just buy whichever's in stock. It sips 8-12 W at idle and tops out under 25 W. Install Ubuntu 24.04 LTS off a USB stick, no fiddly boot args this time. Two things put it ahead of the Pi. First, it's x86, so the whole Wazuh package ecosystem treats you as a first-class citizen and the docs quit hedging about ARM. Second, those 16 GB give you room to run Suricata alongside as a side daemon, writing to ~/var/log/suricata/eve.json while Wazuh tails it.

# after first boot
sudo apt update && sudo apt upgrade -y
sudo apt install -y curl gnupg ufw chrony fail2ban
sudo timedatectl set-timezone UTC
sudo ufw default deny incoming
sudo ufw allow OpenSSH
sudo ufw allow 443/tcp   # Wazuh dashboard
sudo ufw allow 1514/tcp  # agent enrolment
sudo ufw enable

Path C, Hetzner CAX21 ARM cloud (~7 EUR/mo)

Reach for this when your agents already live all over the place. Work laptops, a VPS fleet, your cousin's home server you somehow ended up administering. And you'd rather not expose your home WAN just to give them somewhere to phone.

Hetzner Cloud's CAX21 runs on Ampere Altra cores, which is real server-grade ARM, not a dev board pretending. Performance stays flat instead of throttling on you. You get 4 vCPU, 8 GB RAM, 80 GB NVMe, plus 20 TB of egress for about 0.0094 EUR an hour, capped at roughly 7 EUR a month. Click order, SSH in inside three minutes, and you're sitting on Ubuntu 24.04 ARM64. From there it's the same install as Path A, minus the cgroup tweak. Hetzner's image already ships with that sorted.

The thing to chew on here is data residency. Your logs now leave the house. Hetzner is GDPR-friendly and EU-only out of the box, so for most of us that's fine. But if you're a regulated shop, go ask your DPO before you fall in love with it. The other thing is the obvious one. This box now faces the open internet, so the firewall section below is not optional for Path C.

The shared install: wazuh-install.sh -a

This is the part people brace for, and honestly it's the easy bit. One curl, one script, done. Figure 7-11 minutes on the Pi, 4-6 on the N100, about 5 on Hetzner. Go make coffee. Run it as root.

cd /root
curl -sO https://packages.wazuh.com/4.10/wazuh-install.sh
sudo bash ./wazuh-install.sh -a

When it finishes, the script prints the admin password and the local dashboard URL. HTTPS, self-signed cert, the usual. Copy that password somewhere safe right now. It does not come back if you scroll past it, and the recovery dance is no fun at all.

INFO: --- Summary ---
INFO: You can access the web interface https://<wazuh-dashboard-ip>
 User: admin
 Password: 9X<your-password-here>
INFO: Installation finished.

Now open that dashboard URL. On Path A or B, do it from another machine on the same LAN. On Path C, don't expose the dashboard port to the world. Tunnel to it instead: ssh -L 8443:127.0.0.1:443 root@your-vps, then visit https://127.0.0.1:8443. Your browser will whine about the self-signed cert. Click through it and log in with the admin password the installer just handed you. If it all went right, you land on a live Discover view with events already flowing in.

Enrol the first agents

The dashboard does most of the work here. Head to Agents, Deploy new agent, pick the OS, and it spits out the exact install command with your server baked in. Here's what those look like across the three platforms I run:

# Linux endpoint
curl -sO https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.10.0-1_amd64.deb
sudo WAZUH_MANAGER='your-server-ip' dpkg -i wazuh-agent_4.10.0-1_amd64.deb
sudo systemctl enable --now wazuh-agent

# Windows endpoint (PowerShell)
Invoke-WebRequest -Uri https://packages.wazuh.com/4.x/windows/wazuh-agent-4.10.0-1.msi -OutFile wazuh-agent.msi
msiexec.exe /i wazuh-agent.msi /q WAZUH_MANAGER='your-server-ip'
NET START WazuhSvc

# macOS endpoint
curl -sO https://packages.wazuh.com/4.x/macos/wazuh-agent-4.10.0-1.pkg
sudo /usr/sbin/installer -pkg wazuh-agent-4.10.0-1.pkg -target /
echo 'WAZUH_MANAGER="your-server-ip"' | sudo tee /Library/Ossec/etc/preloaded-vars.conf
sudo /Library/Ossec/bin/wazuh-control start

Give it about 60 seconds and the agent shows up under Agents as Active. The little green status flip is oddly satisfying, or maybe that's just me. Now repeat it for every box you own.

Budget tuning: retention, indices, alert noise

Out of the box, Wazuh keeps 90 days hot. Sounds generous until you do the math. On a 64 GB Pi NVMe with 25 agents, the disk fills in about six weeks, and a full Indexer disk is a genuinely bad afternoon. Three knobs pull you back from that.

• Shorter ILM rollover. Edit /etc/wazuh-indexer/opensearch.yml and drop the wazuh-alerts index lifecycle to 14 days hot, then delete. This is the big one. It cuts your disk by roughly 80 %.
• Disable noisy rule groups. Over in Management, Rules, filter by group syslog, sshd, ossec, then kill anything firing more than 100 k times a day that you're never actually going to read. That alone trims alert-DB writes by about 40 %.
• Compress at rest. Flip the indexer's codec to best_compression via index.codec. Costs you maybe 5 % CPU, hands back around 30 % of your disk. Take that trade.

One more, Path C only. This box is on the public internet, so treat it that way. Put fail2ban on SSH. Deny everything inbound on 1514/tcp except the agent IPs you actually trust, and let certbot drop a real TLS cert on the dashboard so Chrome quits yelling at you every login. Skip all that and you're running an open SIEM for strangers.

Sources and further reading

• Wazuh documentation
• MITRE ATT&CK

Frequently asked questions