Security teams are running out of patience for per-gigabyte SIEM pricing. Splunk, Microsoft Sentinel, and IBM QRadar all bill on how much log data you feed them, and that volume keeps climbing as agentic AI tools multiply the number of processes, API calls, and service accounts running inside a typical network. Gartner’s 2026 cybersecurity trend analysis puts a fine point on it: organizations now need a unique identity for every AI agent they deploy, a defined human owner for each one, and continuous discovery to catch shadow AI instances that pop up outside approved channels, according to Gartner’s analysis published via Cybersecurity Tribe. None of that is cheap to log at commercial SIEM rates.
Wazuh offers a different starting point. It is a free, open source SIEM and XDR platform released under the GPLv2 license, and as of July 2026 it sits at version 4.14.6 with 16,100 stars and 2,400 forks on its main GitHub repository. This tutorial walks through a complete Docker-based deployment: from a bare Linux host to a working dashboard, an enrolled agent, live alerting, and compliance-ready reporting, in 14 steps and roughly 60 minutes. Everything here uses the official Wazuh container images and configuration files, so what you build will match a real single-node deployment rather than a stripped-down demo.
By the end you will have a manager, indexer, and dashboard running in Docker, at least one Linux or Windows agent actively reporting back to it, file integrity monitoring watching directories you choose, vulnerability detection running against installed packages, and a Slack channel receiving alerts tagged with MITRE ATT&CK technique IDs. That is enough to run as a real, if modest, security operations setup, not just a proof of concept you tear down afterward.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Is Wazuh? Inside the Open Source SIEM and XDR Platform
Wazuh started as a fork of OSSEC, the host-based intrusion detection project Daniel Cid began in the mid-2000s. Wazuh Inc., founded in 2015, took that codebase and built a full security information and event management (SIEM) and extended detection and response (XDR) platform around it. The core project remains open source under GPLv2, which means the software itself carries no license fee whether you run it in a home lab or across a few hundred production servers.
The platform breaks down into four components that work together:
- Wazuh manager: the central server that receives data from agents, runs it through the detection rule engine, and triggers alerts and active responses.
- Wazuh indexer: a fork of OpenSearch that stores and indexes all the alert and event data so you can search it later.
- Wazuh dashboard: the web interface you use to visualize alerts, run searches, and manage agents and rules.
- Wazuh agent: a lightweight process installed on each endpoint (Linux, Windows, or macOS) that collects logs, monitors file integrity, and reports back to the manager.
In practice, three types of teams reach for Wazuh most often: managed security service providers who need to monitor many client environments without a per-endpoint license fee stacking up, compliance-driven small and mid-sized businesses that need PCI DSS or HIPAA evidence but cannot justify a six-figure Splunk contract, and individual engineers building a home lab or studying for a security certification who want hands-on experience with a real detection stack rather than a sandboxed trial account. All three get the same software, the same rule engine, and the same dashboard.
Out of the box, Wazuh handles log analysis, file integrity monitoring (FIM), configuration and policy monitoring, rootkit detection, real-time alerting, active response, and vulnerability detection. It also ships with built-in integrations for Suricata, osquery, YARA, VirusTotal, MISP, Slack, and PagerDuty, so you are not starting from a blank rule set. The most recent stable releases have kept a steady cadence: version 4.14.0 shipped on October 23, 2025 with Microsoft Graph API dashboard support and hot-reload for agent configuration, 4.14.5 followed on The claim that a Microsoft Graph API dashboard with hot-reload for agent configuration was announced for April 23, 2026 is false; no such feature has been announced, as hot-reload belongs to Dev Proxy v2.1 (not a Graph API dashboard), and Agent 365-based Graph APIs only entered Public Preview on May 1, 2026 [1][2][4].14.6 landed in the first days of July 2026. Wazuh Inc. has also previewed a Wazuh 5.0 release, though as of this writing the company has not published a firm general-availability date, so treat any specific 5.0 launch date you see elsewhere as unconfirmed.
Wazuh vs Splunk vs Elastic Security vs Microsoft Sentinel
Before you commit an afternoon to a deployment, it helps to know where Wazuh actually sits next to the SIEM platforms most security teams already know. The short version: Wazuh trades a managed, all-in-one commercial experience for zero licensing cost and full control over where your data lives.
| Aspect | Wazuh | Splunk | Elastic Security | Microsoft Sentinel |
|---|---|---|---|---|
| License | Open source (GPLv2) | Proprietary | Free basic tier, paid tiers for advanced features | Proprietary, Azure-billed |
| Deployment | Self-hosted (Docker, bare metal, any cloud VM) | Self-hosted or Splunk Cloud | Self-hosted or Elastic Cloud | Azure-native SaaS only |
| Pricing model | Free software; you pay only for your own infrastructure | Priced by daily data ingest volume | Free tier plus paid feature tiers | Pay-as-you-go on ingested data volume |
| Underlying data store | Wazuh indexer (OpenSearch fork) | Proprietary Splunk index | Elasticsearch | Azure Log Analytics workspace |
| File integrity monitoring | Built in | Requires an add-on | Requires a paid tier | Requires Defender for Cloud |
| Vulnerability detection | Built in | Requires Enterprise Security add-on | Paid tier feature | Requires Defender for Cloud |
| Compliance report templates | PCI DSS, HIPAA, GDPR, NIST 800-53, ISO 27001 built in | Available via apps and add-ons | Available via paid tier | Available via Sentinel workbooks |
None of this makes Wazuh a strict upgrade. Commercial platforms still win on managed hosting, enterprise support SLAs, and polish for very large multi-tenant deployments. But for a team that wants full visibility into its own environment without a consumption-based invoice, the open source SIEM setup below gets you most of the way to a functioning security operations workflow for the cost of a server.
The practical difference shows up at renewal time more than at signup. A consumption-priced SIEM’s bill moves with your log volume, so turning on a new, chatty data source, like full DNS query logging or verbose cloud audit trails, means a bigger invoice next month. A self-hosted Wazuh deployment’s cost is mostly fixed: you provision the compute and storage once, and ingesting more log sources costs you disk space rather than a renegotiated contract. That tradeoff cuts the other way too. If your indexer runs out of disk or memory, the failure mode is a red cluster health status you have to fix yourself, not a vendor’s autoscaling infrastructure quietly absorbing the spike. Budget predictability and operational ownership come as a package deal.
Prerequisites: Hardware, Software, and Network Ports You’ll Need
Wazuh’s official quickstart documentation publishes sizing guidance based on how many agents you plan to monitor. For a single-node Docker deployment, these are the numbers to plan around:
| Deployment size | Agents | CPU | RAM | Storage (90-day retention) |
|---|---|---|---|---|
| Home lab / small team | 1–25 | 4 vCPU | 8 GB | 50 GB |
| Medium | 25–50 | 8 vCPU | 8 GB | 100 GB |
| Large single node | 50–100 | 8 vCPU | 8 GB | 200 GB |
| Agent-only container | n/a | 2 vCPU | 1 GB | 10 GB |
On the software side, you need Docker Engine (a recent stable release), Docker Compose v2, and Git, running on a 64-bit Linux host. Wazuh’s central components officially support Amazon Linux 2 and 2023, CentOS Stream 10, Red Hat Enterprise Linux 7 through 10, and Ubuntu 16.04 through 24.04. This tutorial was tested against Ubuntu 24.04 LTS, but any of the above will work the same way. You will also want at least one separate machine, physical or virtual, Linux or Windows, to act as the monitored endpoint once the manager is running.
Finally, make sure the following ports are open between your future manager, indexer, dashboard, and agents. Misconfigured firewalls here are the single most common reason a Wazuh deployment looks broken when it is actually just unreachable.
| Port | Protocol | Component | Purpose |
|---|---|---|---|
| 1514 | TCP (UDP optional) | Manager | Receives agent event data |
| 1515 | TCP | Manager | Agent enrollment service |
| 1516 | TCP | Manager | Cluster daemon for multi-node setups |
| 514 | UDP/TCP (optional) | Manager | Syslog collector for network devices |
| 55000 | TCP | Manager | Wazuh REST API |
| 9200 | TCP | Indexer | Indexer REST API |
| 9300–9400 | TCP | Indexer | Indexer cluster communication |
| 443 | TCP | Dashboard | Web UI over HTTPS |
Step 1–3: Prepare Your Docker Host
Step 1: Check System Requirements and OS Support
Confirm your host meets the single-node minimums from the table above (4 cores, 8 GB RAM, 50 GB free disk for a small deployment) and that you are on a supported 64-bit Linux distribution. Check your kernel and available memory before going further:
uname -a
free -h
df -h /Step 2: Install Docker Engine and Docker Compose
If Docker is not already installed, use the official convenience script and confirm the Compose plugin is available:
curl -fsSL https://get.docker.com | sh
sudo systemctl enable --now docker
docker --version
docker compose versionStep 3: Set vm.max_map_count and Clone the Wazuh Docker Repository
The Wazuh indexer is built on OpenSearch, which needs a higher virtual memory map count than most Linux distributions ship with by default. Skip this step and the indexer container will exit almost immediately after startup. Set it, then clone the official wazuh-docker repository at the tag matching the current stable release:
sudo sysctl -w vm.max_map_count=262144
echo "vm.max_map_count=262144" | sudo tee -a /etc/sysctl.conf
git clone https://github.com/wazuh/wazuh-docker.git -b v4.14.6
cd wazuh-docker/single-node/Writing the setting to /etc/sysctl.conf makes it survive a reboot, which matters if this host restarts for a kernel update six months from now and you have forgotten you ever touched this value.
Step 4–6: Generate Certificates and Lock Down Defaults
Step 4: Generate SSL/TLS Certificates for the Indexer
Wazuh’s components talk to each other over TLS, and the single-node Compose file ships a dedicated job for generating self-signed certificates. Run it once before the main stack starts:
docker compose -f generate-indexer-certs.yml run --rm generatorThis drops certificates into a local directory that the rest of the stack mounts automatically. Self-signed certificates are fine for a lab or an internal deployment behind your own network perimeter. If you are exposing the dashboard to the public internet, replace these with certificates from a trusted CA before you go further.
Step 5: Review the Docker Compose Configuration and Environment Variables
Open docker-compose.yml in the single-node directory and skim the service definitions for wazuh.manager, wazuh.indexer, and wazuh.dashboard. You do not need to change much for a first deployment, but confirm the memory limits match your host and note the volume mounts, since that is where your alert data and configuration will persist between container restarts. The manager service definition is the one worth reading closely, since it is where agent ports and persistent volumes are declared:
services:
wazuh.manager:
image: wazuh/wazuh-manager:4.14.6
hostname: wazuh.manager
restart: always
ports:
- "1514:1514"
- "1515:1515"
- "55000:55000"
environment:
- INDEXER_URL=https://wazuh.indexer:9200
- INDEXER_USERNAME=admin
- INDEXER_PASSWORD=SecretPassword
volumes:
- wazuh_api_configuration:/var/ossec/api/configuration
- wazuh_etc:/var/ossec/etc
- wazuh_logs:/var/ossec/logsTwo things to flag here before you launch anything. First, INDEXER_PASSWORD=SecretPassword is the same default credential mentioned in Step 6, hardcoded into the environment block, which is exactly why it needs to change before this file ever runs on a host with a public IP. Second, the wazuh_etc volume is what carries your ossec.conf edits from Steps 13 and 14 across container restarts and upgrades, so back it up before you run any future docker compose pull against a newer image tag.
Step 6: Change the Default Admin Passwords Before You Launch
The single-node stack ships with a default dashboard login of admin / SecretPassword. That default is documented publicly, which means it is also the first thing an opportunistic scanner will try if your dashboard port ever ends up reachable from the open internet. Before starting the stack, edit the internal users file the Compose setup references (typically under the indexer’s security configuration) and set a unique password, or plan to rotate it immediately after your first login in Step 9.
Step 7–9: Launch the Wazuh Stack and Log In
Step 7: Start the Single-Node Wazuh Stack
With certificates generated and passwords reviewed, bring the stack up in the background:
docker compose up -dThe manager, indexer, and dashboard containers download and start together. On an 8 GB host this typically takes several minutes for images to pull the first time. Do not run the multi-node Compose file on the same host at the same time. The two stacks compete for the same default ports and will fail in confusing ways.
Step 8: Verify Container Health
Confirm all three containers are actually healthy before assuming something is broken:
docker compose ps
docker compose logs wazuh.indexer --tail=50
docker compose logs wazuh.manager --tail=50Look for the indexer reporting a green or yellow cluster status and the manager logging that it has started its API service on port 55000. A healthy docker compose ps output on a freshly launched single-node stack looks like this:
NAME IMAGE STATUS
single-node-wazuh.manager-1 wazuh/wazuh-manager:4.14.6 Up 2 minutes (healthy)
single-node-wazuh.indexer-1 wazuh/wazuh-indexer:4.14.6 Up 2 minutes (healthy)
single-node-wazuh.dashboard-1 wazuh/wazuh-dashboard:4.14.6 Up 2 minutesIf any of the three shows Restarting instead of Up ... (healthy), stop here and check that container’s logs before moving to Step 9. Chasing a login problem on a dashboard whose backend indexer is still crash-looping is a common way to lose twenty minutes for nothing.
Step 9: Log In to the Wazuh Dashboard
Point a browser at https://<DOCKER_HOST_IP>. Accept the self-signed certificate warning if you have not replaced it, and log in with the admin credentials you set in Step 6 (or the default, if you have not changed it yet, followed immediately by a password change). You should land on the main Wazuh dashboard overview with an empty agents list, which is exactly where you should be at this point.
Step 10–12: Enroll Your First Agents
Step 10: Install the Wazuh Agent on Linux
On the endpoint you want to monitor (Ubuntu or Debian in this example), add the Wazuh package repository and install the agent, pointing it at your manager’s IP address via the WAZUH_MANAGER variable, per the official Linux agent installation guide:
apt-get install gnupg apt-transport-https
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import && chmod 644 /usr/share/keyrings/wazuh.gpg
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" | tee -a /etc/apt/sources.list.d/wazuh.list
apt-get update
WAZUH_MANAGER="10.0.0.2" apt-get install wazuh-agent
systemctl daemon-reload
systemctl enable wazuh-agent
systemctl start wazuh-agentReplace 10.0.0.2 with the actual IP address or hostname of your Wazuh manager.
Step 11: Install the Wazuh Agent on Windows
On a Windows endpoint, download the Wazuh agent MSI package for your version from the Wazuh package repository and run a silent install from an elevated PowerShell prompt, again pointing at your manager:
msiexec.exe /i wazuh-agent.msi /q WAZUH_MANAGER="10.0.0.2" WAZUH_AGENT_GROUP="default"
NET START WazuhSvcThe Windows agent registers itself with the same manager your Linux agents use, so you can mix operating systems under one Wazuh deployment without running separate infrastructure for each.
Step 12: Confirm Agent Connectivity From the Dashboard
Back in the dashboard, open the Agents view. A newly enrolled agent should transition from “pending” to “active” within a minute or two of the service starting. If it sits at “never connected,” jump to the troubleshooting table further down, since that almost always traces back to a blocked port or a typo in the manager address. From the command line, you can check the same status on the manager without opening a browser:
$ /var/ossec/bin/agent_control -l
ID: 001, Name: web-01, IP: 10.0.0.15, Active
ID: 002, Name: DESKTOP-A1B2C3, IP: 10.0.0.22, ActiveBoth agents showing Active confirms the manager is receiving heartbeats from each endpoint. This is the checkpoint to hit before moving on to rules and integrations. There is no point tuning alert thresholds for an agent that is not actually connected yet.
Step 13–14: Turn On Detection Rules and Alert Integrations
Step 13: Turn on File Integrity Monitoring and Vulnerability Detection
Both FIM and vulnerability detection exist in Wazuh’s default rule set but need to be pointed at the directories and update cadence you actually care about. On the agent, edit /var/ossec/etc/ossec.conf to add the directories you want watched for unauthorized changes:
<syscheck>
<directories realtime="yes" report_changes="yes">/etc,/usr/bin,/usr/sbin</directories>
<directories realtime="yes">/var/www/html</directories>
</syscheck>Restart the agent after any configuration change (systemctl restart wazuh-agent). Vulnerability detection runs on the manager side against a feed of known CVEs matched to installed package versions, so no additional agent configuration is required beyond keeping the agent’s inventory module enabled, which is on by default.
Step 14: Wire Up Slack Alerts, VirusTotal, and MITRE ATT&CK Mapping
On the manager, add an integration block to /var/ossec/etc/ossec.conf to forward high-severity alerts to Slack:
<integration>
<name>slack</name>
<hook_url>https://hooks.slack.com/services/YOUR/WEBHOOK/URL</hook_url>
<alert_format>json</alert_format>
<level>10</level>
</integration>Restart the manager (systemctl restart wazuh-manager, or the equivalent container restart if you moved the manager itself into its own container) and trigger a test alert to confirm delivery. Wazuh’s default rule set already tags many alerts with MITRE ATT&CK technique IDs, which show up directly in the dashboard’s alert detail view, so once the Slack hook is live you get both the notification and the attacker-technique context in the same place. A VirusTotal integration follows the same pattern with an API key in place of a webhook URL, and is worth adding if you want automatic reputation checks on any file that trips a FIM alert.
Real-World Example: Catching an SSH Brute-Force Attempt
It helps to see the whole pipeline fire once before trusting it with real infrastructure. Wazuh’s default ruleset already watches sshd logs for repeated authentication failures, so once your Linux agent is active, you can generate a realistic test case just by attempting a handful of failed SSH logins against the monitored host from another machine (five or six wrong-password attempts in quick succession is enough to trip the correlation rule).
On the agent side, the raw log line the kernel and sshd generate looks like any other failed login you have seen in /var/log/auth.log:
sshd[19822]: Failed password for invalid user admin from 203.0.113.44 port 51422 ssh2On its own, one failed login is not interesting. But the manager’s correlation engine tracks the count within a time window, and once it crosses the threshold it escalates into a higher-severity alert that lands in the dashboard and, if you completed Step 14, in your Slack channel at the same time. The alert record behind that notification looks roughly like this:
{
"timestamp": "2026-07-14T09:42:11.000+0000",
"rule": {
"level": 10,
"description": "sshd: brute force trying to get access to the system.",
"groups": ["authentication_failures", "pci_dss", "gdpr"],
"mitre": {
"technique": ["Brute Force"],
"id": ["T1110"]
}
},
"agent": { "name": "web-01", "ip": "10.0.0.15" },
"full_log": "sshd[19822]: Failed password for invalid user admin from 203.0.113.44 port 51422 ssh2"
}Three details in that record matter more than the alert itself. The groups field already ties the event to pci_dss and gdpr, which is what feeds the compliance reports covered next. The mitre block tags the event with technique T1110, Brute Force, so an analyst reviewing the dashboard sees attacker methodology, not just a raw log line. And the whole chain, from failed password to Slack message, happened without writing a single custom rule. It came from the default ruleset you got the moment you finished Step 7.
Mapping Wazuh to PCI DSS, HIPAA, GDPR, NIST, and ISO 27001
One reason Wazuh shows up so often in regulated environments is that its dashboard ships with report modules already mapped to the control families auditors ask about. That does not make your organization compliant by itself. It does mean the evidence-gathering work, which normally eats weeks of an audit cycle, is largely automated.
| Framework | What Wazuh covers |
|---|---|
| PCI DSS | File integrity monitoring, log retention, and access-control monitoring for cardholder data environments |
| HIPAA | Audit logging and real-time alerting for systems handling protected health information |
| GDPR | Monitoring and reporting that support data-protection and breach-notification obligations |
| NIST 800-53 | Rule sets mapped to specific control families for federal systems and contractors |
| ISO 27001 | Continuous monitoring evidence for an information security management system |
If your organization is working toward one of these frameworks, generate the relevant report from the dashboard’s Compliance section after your agents have been reporting for at least a few days. A report built from ten minutes of test data will not impress an auditor, but a report built from a real baseline period usually will.
What actually changes an audit conversation is having the underlying alert data to back the report up. An auditor who asks how you would know if someone modified a configuration file on a payment-processing server can be shown the exact FIM alert Step 13 configures, timestamped, tied to a specific agent, and mapped to a specific control family, rather than a policy document promising that monitoring exists somewhere. That gap between “we have a policy” and “here is the alert from last Tuesday” is usually what separates a smooth audit from a long one.
Common Pitfalls When Deploying Wazuh
Most Wazuh support threads trace back to a small handful of avoidable mistakes. Here are the ones worth checking before you assume something is fundamentally wrong with your setup.
- Skipping the vm.max_map_count kernel setting. This is by far the most common first-run failure, and it shows up as the indexer container exiting within seconds of startup.
- Leaving the default admin/SecretPassword credentials in place. Documented defaults get scanned for constantly; rotate them before the dashboard is reachable from anywhere but your own workstation.
- Undersizing RAM to save on cloud costs. The indexer is the most memory-hungry component in the stack, and 4 GB instances routinely hit out-of-memory kills that look like random crashes.
- Running single-node and multi-node Compose files on the same host at once. The official documentation explicitly warns against this, and the resulting port conflicts are genuinely confusing to debug.
- Exposing port 9200 directly to the internet. The indexer’s REST API should sit behind the manager and dashboard, not be reachable on its own from outside your network.
- Forgetting to reissue certificates after changing a hostname or IP. Certificates generated in Step 4 are tied to the values present at generation time; cloning a VM or changing a hostname afterward breaks TLS handshakes.
- Not planning log retention before onboarding hundreds of agents. The 50 GB to 200 GB storage guidance assumes 90-day retention at the stated agent counts, and skipping this math is how teams wake up to a red cluster health status.
Troubleshooting Wazuh: Common Issues and Fixes
| Symptom | Likely cause | Fix |
|---|---|---|
| Indexer container exits immediately after startup | vm.max_map_count not raised on the host | Run sudo sysctl -w vm.max_map_count=262144, then restart the stack |
| Agent shows “Never connected” in the dashboard | Port 1514 or 1515 blocked by a firewall or cloud security group | Open both ports between agent and manager, confirm the WAZUH_MANAGER value |
| Dashboard shows “Wazuh API not reachable” | Manager container unhealthy, or port 55000 not exposed | Run docker compose ps and check docker compose logs wazuh.manager |
| Browser shows a certificate warning | Self-signed certificate from generate-indexer-certs.yml | Expected for internal labs; replace with a trusted CA cert for public-facing use |
| Indexer cluster health shows yellow or red | Disk approaching capacity under the default retention policy | Adjust the index state management policy or add storage |
| Agent connects but no alerts ever appear | Default rule set has not matched any real test traffic yet | Generate genuine test events, or temporarily lower the alert level threshold |
| Login fails even with the correct password | Dashboard container is still initializing | Wait one to two minutes after the first docker compose up -d, then retry |
| Duplicate or conflicting agent ID errors | A cloned VM image reused the same client.keys file | Remove the stale registration and re-enroll each clone individually |
| Agents repeatedly flap between connected and disconnected | Clock drift between agent and manager hosts | Install and enable chrony or ntpd on every host in the deployment |
| Slack or PagerDuty alerts never arrive | Malformed <integration> block in ossec.conf | Check ossec.log for integratord errors and validate the hook URL |
Advanced Tips: Clustering, Cloud Workloads, and Kubernetes
Once the single-node setup is stable, a few extensions are worth exploring depending on how far you plan to take this deployment.
Multi-node clustering. Wazuh supports a multi-node indexer and clustered manager configuration for high availability, using the same wazuh-docker repository’s multi-node directory instead of single-node. Plan on at least three hosts for a resilient indexer cluster and remember the 16 GB RAM and 100 GB storage minimums that apply to multi-node deployments.
Cloud workload monitoring. Wazuh ships modules for AWS, Azure, and GCP that pull in service-level logs (CloudTrail, Azure Activity Log, and equivalents) alongside your endpoint agent data, which is useful if your infrastructure is not purely on-premises servers.
Kubernetes and container workloads. Beyond running Wazuh’s own control plane in Docker, Wazuh can also monitor container workloads directly, and community Kubernetes manifests exist for teams that would rather run the entire stack under an existing cluster than manage standalone Docker Compose files.
Network intrusion detection with Suricata. Pairing Wazuh with Suricata gives you network-layer detection (packet inspection, signature-based alerts) feeding into the same dashboard as your host-based agent alerts, which closes a real gap, since agents alone cannot see traffic that never touches a monitored endpoint directly.
Writing custom detection rules. The default ruleset covers common cases like SSH brute forcing well, but it will not know about an internal application’s own log format. Wazuh lets you add rules in /var/ossec/etc/rules/local_rules.xml that match on any field your agents send, without touching the vendor-maintained ruleset that ships with each release. Start narrow, matching one specific log line from an application you already know throws errors, then widen the rule once you have confirmed it fires correctly instead of writing a broad rule first and fighting false positives later.
Performance tuning as agent count grows. The indexer is almost always the first component to feel pressure as agent count climbs, since every event has to be written and indexed. If dashboard searches start to lag before you are anywhere near the 100-agent single-node ceiling, check index shard counts and retention settings before assuming you need to move to a multi-node cluster. A lot of single-node performance complaints trace back to retention policies that were never adjusted away from the defaults.
Complete Working Project: A Home-Lab SOC in One Docker Compose Setup
Putting the full tutorial together, here is what a finished home-lab deployment looks like end to end, starting from an empty Ubuntu 24.04 server:
# 1. Host prep
sudo sysctl -w vm.max_map_count=262144
echo "vm.max_map_count=262144" | sudo tee -a /etc/sysctl.conf
curl -fsSL https://get.docker.com | sh
# 2. Get the stack
git clone https://github.com/wazuh/wazuh-docker.git -b v4.14.6
cd wazuh-docker/single-node/
# 3. Certificates and launch
docker compose -f generate-indexer-certs.yml run --rm generator
docker compose up -d
# 4. Confirm health
docker compose ps
# 5. Log in at https:// (admin / your new password)
# 6. Enroll an agent from each endpoint you want monitored
# 7. Enable FIM directories, vulnerability detection, and a Slack hook in ossec.conf At the end of that sequence you have a working single-node Wazuh SIEM setup: a dashboard reachable over HTTPS, at least one active agent reporting file integrity and log data, alerts tagged with MITRE ATT&CK technique IDs, and a Slack channel receiving anything rated severity 10 or higher. That is a genuinely useful home-lab or small-business security operations setup, not a toy demo, and it scales into the multi-node and cloud-integrated options covered above without starting over from scratch.
Frequently Asked Questions
Is Wazuh really free to use in production?
Yes. The core platform is GPLv2 open source and carries no license fee at any scale. Wazuh Inc. sells optional cloud hosting and paid support contracts, but running the software yourself, in production, costs nothing beyond your own infrastructure.
Can Wazuh fully replace Splunk or Microsoft Sentinel?
For log-based threat detection, file integrity monitoring, and compliance reporting, Wazuh covers most of what small and mid-sized teams need. Very large enterprises running multi-petabyte pipelines with heavy SOAR automation sometimes keep a commercial platform in place alongside it, but plenty of organizations run Wazuh as their only SIEM.
How many agents can one Wazuh manager handle?
Official sizing guidance scales from 25 agents on a 4 vCPU, 8 GB single node up to 100 agents on an 8 vCPU, 8 GB single node. Beyond that, Wazuh’s documentation points teams toward multi-node clustering rather than continuing to scale a single host vertically.
Does Wazuh support Windows endpoints?
Yes. Native agent installers exist for Windows alongside Linux and macOS, and all three report back to the same manager, so a mixed-OS environment does not require separate infrastructure per platform.
What’s different in the upcoming Wazuh 5.0?
Wazuh Inc. has previewed a 5.0 release, but at the time of writing the company had not published a confirmed general-availability date. Anything you read elsewhere about a specific 5.0 launch date should be treated as unconfirmed until Wazuh’s own release notes say otherwise.
Do I need a separate Elasticsearch license to run Wazuh?
No. Current Wazuh versions ship their own Wazuh indexer, which is a fork of OpenSearch, so there is no separate Elastic license or dependency to manage.
Can I run Wazuh on Kubernetes instead of Docker Compose?
Yes. Teams that already operate a Kubernetes cluster often prefer community-maintained manifests over standalone Docker Compose, since it lets Wazuh fit into existing deployment and monitoring pipelines rather than running as a separate island.
Is Wazuh itself certified for PCI DSS or ISO 27001?
No. Certification applies to your organization’s overall security program, not to the software vendor. Wazuh provides the monitoring, logging, and reporting evidence your auditors will ask to see, but the compliance certification itself belongs to your organization.
How do I upgrade Wazuh without losing agent data or alert history?
Back up the named volumes your Compose file declares, particularly wazuh_etc, wazuh_logs, and the indexer’s data volume, before pulling a newer image tag. Update the version in your git clone or docker compose pull command to the new release, bring the stack down, then back up with the new images against the existing volumes. Because configuration and indexed alert data live in persistent volumes rather than inside the containers themselves, a version bump does not wipe out history the way discarding the whole stack would.
Related Coverage
- Graylog SIEM Setup: 13 Steps, 45 Min [2026]
- CrowdSec: Block Malicious IPs in 12 Steps, 40 Min [2026]
- FortiBleed Cracks 86,644 Fortinet Firewalls [2026]
- New CitrixBleed Flaw: NetScaler Hit in 24 Hours [2026]
- Cisco SD-WAN: 7 Zero-Days, 2 at CVSS 10 [2026]
For more coverage of open source security tooling and the vulnerabilities it is built to catch, browse the full cybersecurity section on Tech Insider.
