How to Install Wazuh on Ubuntu Server: Self-Hosted Setup

If you’re running more than a couple of machines in your homelab, you probably have logs scattered everywhere and no real visibility into what’s actually happening on your network. That’s where installing Wazuh on Ubuntu comes in. It’s a free, open-source security platform that pulls logs from your servers, VMs, and containers into one place, then uses some mild ML to flag weird traffic and system behavior. I’m skeptical of most “AI threat detection” claims, but Wazuh’s anomaly detection actually catches things. Not magic, but useful.

Why Wazuh Instead of Scattered Logging

Most homelab setups evolve organically. You add a Proxmox node, spin up some containers, grab a NAS. Logs end up in syslog on one machine, application logs buried in another, firewall logs nowhere. By the time something goes sideways, you have no trail.

Wazuh centralizes that. Every agent reports back to the manager. You get a dashboard. You get search. You get alerts. It’s not enterprise-grade—it will bog down if you throw 10,000 events per second at it—but for a homelab with reasonable traffic, it’s solid. The open-source version is actually usable, not a limited demo.

There are alternatives: Elastic Stack works, but it’s heavier and requires more tuning. Splunk is commercial and expensive. Graylog is decent but less polished. Wazuh splits the difference: lightweight agent footprint, clean UI, good defaults out of the box.

Prerequisites and Hardware

You’ll need an Ubuntu 20.04 or 22.04 LTS server to run the Wazuh manager. This is the central component. Your agents run on everything else.

For the manager itself:

• CPU: 2 cores minimum, 4+ if you’re monitoring more than 10-15 agents
• RAM: 4GB minimum, 8GB recommended. The elasticsearch backend will complain if you give it less than 3GB.
• Storage: 30-50GB for the database, depending on retention and event volume. I run mine with 100GB to be safe.
• Network: Static IP. Don’t run this on DHCP.

For agents: Barely anything. 100MB of disk, minimal CPU overhead. The agent is lean.

You’ll also need Docker and Docker Compose installed. If you don’t have those yet, grab them from the official Docker repo—the Ubuntu default packages are usually out of date.

Step 1: Prepare Your Ubuntu Server

SSH into your Ubuntu machine and update everything:

sudo apt update
sudo apt upgrade -y

Install Docker. I’ll use the official method:

curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
sudo usermod -aG docker $USER
newgrp docker

Install Docker Compose:

sudo curl -L "https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose

Verify both are working:

docker --version
docker-compose --version

Create a directory for Wazuh and move there:

mkdir -p ~/wazuh-deployment
cd ~/wazuh-deployment

Step 2: Deploy Wazuh with Docker Compose

Wazuh’s official Docker setup is available on GitHub. Grab the compose file and supporting config:

git clone https://github.com/wazuh/wazuh-docker.git
cd wazuh-docker/single-node

Before you start the containers, check the .env file and adjust a few things. The default admin password is there and it’s weak. Change it:

cat .env

Look for lines like INDEXER_USERNAME and INDEXER_PASSWORD. Edit the file and set a real password. While you’re there, note the WAZUH_API_USERNAME and WAZUH_API_PASSWORD—you’ll need those for the dashboard login. I typically set them to something I can actually remember, like a passphrase with numbers. Save the file.

Now spin up the containers:

docker-compose up -d

This pulls about 2GB of images and takes a few minutes. While it’s running, watch the logs:

docker-compose logs -f

You’re looking for lines that say the services are “ready”. When you see the Wazuh API listening on 55000 and the indexer responding healthily, you’re good. Hit Ctrl+C to exit the log view.

The whole thing should be up in 3-5 minutes. If something times out, check that you have at least 4GB of free RAM on the host. I once tried this on a machine with 2GB and watched the OOM killer evict containers in real time. Not recommended.

Step 3: First-Run Configuration and Dashboard Access

Open your browser and go to https://your-server-ip:443. You’ll get an SSL warning because the certificate is self-signed. Accept it. Log in with the username and password from your .env file.

You’ll see the Wazuh dashboard. It’s clean. The left sidebar has Security, Compliance, Threat Detection. Right now it’s mostly empty because you have no agents yet. That changes next.

Click Agents in the sidebar, then Add New Agent. You’ll get a dialog with copy-paste install commands for different operating systems. This is where the magic happens.

Let’s say you want to monitor a Proxmox host. SSH into it and run the agent install command. For Ubuntu/Debian, it looks like:

curl -s https://your-wazuh-manager-ip:9200/_security/api/v1/agent | bash

That’s not the exact command—Wazuh generates it per-agent with the right manager IP and authentication tokens baked in. Just copy what the dashboard gives you.

On the agent machine, the install lands the wazuh-agent binary in /var/ossec/bin/ and creates a service. Start it:

sudo systemctl start wazuh-agent
sudo systemctl enable wazuh-agent

Back on the dashboard, refresh. Within 30 seconds you should see the agent appear in the list with a green “Active” status. Once it’s active, logs start flowing in. Go to the Threat Detection section and you’ll see system events, file integrity changes, all the good stuff.

I typically add 2-3 agents before I start tuning rules. The default ruleset is okay but verbose. You’ll get alerts for normal SSH auth failures and service restarts that don’t matter. We’ll fix that next.

Common Gotchas and Fixes

Agent won’t connect: Nine times out of ten, the manager IP in the agent config is wrong. SSH into the agent and check /var/ossec/etc/ossec.conf. Look for the <manager> block. It should have the actual IP or hostname of your Wazuh manager, not a placeholder. Edit it, then restart the agent:

sudo systemctl restart wazuh-agent

Dashboard is slow: The Elasticsearch backend under the hood is memory-hungry. If you gave the manager VM less than 4GB RAM, it struggles. You can either add RAM or reduce the rolling retention window in the dashboard settings (Wazuh stores a lot of history by default). I bumped mine to 30 days instead of 90 and noticed a real improvement in query speed.

You’re getting flooded with alerts for things you don’t care about: This happened to me immediately. Every SSH failed password attempt triggered an alert. The answer is rule tuning. Go to Management → Rules and search for the rule causing noise (e.g., search for “ssh failed”). You can set it to lower severity or disable it outright. It takes some iteration to get it quiet without losing real signal. Plan for that.

Containers crash on startup: Ran into this once when the .env file had special characters in the password that broke the YAML parsing. Use simple alphanumeric passwords for the initial setup, then change them in the dashboard later once everything is running.

What to Do Next

Once you have a couple of agents running and the noise is tuned down, start exploring the compliance checks. Wazuh has built-in profiles for PCI-DSS, HIPAA, and CIS benchmarks. Flipping one on will immediately show you where your systems are misconfigured. It’s not a full remediation tool, but the visibility is valuable.

The other thing worth doing: set up integrations. Wazuh can forward alerts to Slack, PagerDuty, or just email. Go to Management → Configuration and look at the integrations section. Sending yourself a Slack message when something interesting happens beats checking a dashboard.

Performance-wise, I’d monitor your manager VM’s CPU and memory usage after a week or two of real data. If it’s above 60% consistently, you might want to bump the Docker container limits or scale to a bigger machine. The system will tell you when it’s unhappy.

One honest observation: the Wazuh ruleset is opinionated. What it considers a security event is often true, but sometimes it’s just noise. You’ll spend the first month tuning rules and whitelisting false positives. It’s not something you install and forget. But if you’re willing to spend a little time with it, the visibility you get is genuinely useful, and it doesn’t cost you anything.

FAQ

Can Wazuh run on a Raspberry Pi?

The manager needs at least 4GB of RAM and a multicore CPU, so no on a Pi. But the agent runs fine on ARM—I have one on a Pi 4 sending logs back to a manager on a real server. That works well.

How much storage does Wazuh need?

Depends on your event volume and retention window. A homelab with 5-10 agents and default settings (90-day retention) will need 50-100GB. If you have high-volume sources like a busy firewall, add more. Start with 100GB and monitor real usage after a week.

Do I need to open ports on my firewall for agents to connect?

Yes. The agent connects to the manager on port 1514 (TCP/UDP). If your agents are on a different subnet or VPN, make sure that traffic is allowed. The dashboard runs on 443 (HTTPS), so you probably want that accessible from wherever you need to check alerts from.

Can Wazuh run on Proxmox directly or does it need a separate VM?

It needs a separate VM or bare metal. You can’t run Docker containers directly on Proxmox without a container in between. Give it a dedicated LXC container or VM—either works, but a VM is simpler and avoids kernel issues.

Is the free version of Wazuh actually usable for a homelab?

Yes. The open-source version has everything you need: agents, log aggregation, rule engine, dashboards, integrations. The commercial version adds things like centralized configuration management and some advanced ML, but you don’t need those to get real security visibility.

Explore Wazuh in our AI Homelab Toolkit.